From: John Roth <newsgroups@...>
Date: 2004-01-21T07:05:01+09:00
Subject: Re: New to Python: my impression v. Perl/Ruby


"Ville Vainio"
<ville.spamstermeister.vainio@thisisspamprotectiontut.finland> wrote in
message news:du71xpue3rm.fsf@mozart.cc.tut.fi...
> >>>>> "Phil" == Phil Tomson <ptkwt@aracnet.com> writes:
>
>     Phil> Different strokes for different folks, I guess.  I remember
>     Phil> that one of the first things I saw about Ruby was that even
>     Phil> interger literals were objects that can receive messages and
>     Phil> thinking how wonderful that was.  As you say, you're not
>
> Ints are objects in python too:
>
> >>> a=1
> >>> a.__lshift__(1)
> 2
>
> Though "sending messages" to int literals is a syntax error.
>
>     Phil> 10.times do something end
>
>     Phil> is somehow so clear.  It's almost zenlike.
>
> It's cute and fun to write, but less cute for people who have to read
> lots of such code in short time. I have a soft spot for such style
> also; I kinda like Python's "\n".join(["foo","bar"]), even if most
> seem to consider it a wart for readability reasons.

Tacking an iterator on an integer isn't all that bad from
a readability viewpoint - ***except*** for the .step iterator.
..times, .upto and .downto read very nicely, but .step is
a monstrosity. Conceptually, .step has three parameters,
and separating them that way simply doesn't read right.

It's also not consistent with the .each iterator attached to
range objects in Ruby, which is at least intelligible, and is
consistent with the way iterators are done with all other
objects.

The trouble with <string>.join(<sequence of strings>) in Python
is that it reads backwards, at least to me. The arguement that
..join isn't a natural list method makes sense, but nobody seems
to want to consider that there are other solutions that read
fairly well. Of course, they're also consequences of fairly
generic changes to the language.

John Roth


>
> -- 
> Ville Vainio   http://tinyurl.com/2prnb