Thoughts on PEP284

[Tim Hochberg]

David Eppstein wrote:

> In article <mailman.1064341934.21653.python-list at python.org>,
>  Michael Chermside <mcherm at mcherm.com> wrote:
> 
> 
>>Stephen Horne writes:
>>
>>>True, it is mostly just an alternative notation for range or xrange.
>>>But the integer for loops thing is something that never seems to go
>>>away. PEP284 itself quotes four previous PEPs on broadly the same
>>>issue.
>>
>>I am of the opinion that the introduction of enumerate() (in 2.3) will
>>go a long ways toward reducing the desire for better integer loop
>>syntax. I'm sure it will never go away completely, but if the demand
>>seems to die down after a year or so, then I'd guess it was due to
>>enumerate().
> 
> 
> It will certainly reduce the typical range(len(L)) verbosity.  It 
> doesn't do anything to help the readability of expressions like 
> range(dim-2,-1,-1) (example from some code I wrote a couple weeks ago).

Dealing with reversed ranges is one area that range bugs me. However, in 
2.3 you can replace ``range(n-1,-1,-1)`` with ``range(n)[::-1]``, which 
while still verbose is a lot easier for me to interpret. [Now if I could 
just convinve Armin Rigo to special case that in Psyco so that it was as 
fast as the original...]

I know someone's going to suggest that, since I'm already using slices, 
I should be in favor of int[a:b:c] or similar. But, that doesn't work 
any better than range with reversed ranges since you still have to use 
two slices to make things clear. That is, to get the equivalent of 
``range(n-1,-1,-1)`` one would need to use ``int[n-1:-1:-1]``, which is 
no clearer, or ``int[:n][::-1]`` which doesn't seem like a particular 
win over ``range(n)[::-1]``, which you can do now.


> Actually, looking at that code, the range is not the least readable part 
> of it:

[Snip dictionary comprehension stuff]

-tim