PEP 276 Simple Iterator for ints (fwd)

[Bengt Richter]

On Tue, 11 Dec 2001 15:29:56 -0800, David Eppstein <eppstein at ics.uci.edu> wrote:

>In article <3c169178.96189593 at wa.news.verio.net>,
> bokr at accessone.com (Bengt Richter) wrote:
>
>> How about if a bare [x:y:z] were interepreted as an abbreviation for 
>> slice(x,y,z)
>> and you defined what one might expect as an iterator for the slice type?
>> 
>> Then you could write
>>     for i in [0:5]:   # or [:5]
>>         ...
>
>I don't know about the rest of the participants in this discussion, but I 
>am not interested in a more concise notation for range() that repeats its 
>drawbacks (limited to half-open intervals, non-Pythonists need to look it 
>up in the manual in order to understand it).  Why is that any better than 
>what we have now?

I didn't mean it to be "a more concise notation for range()" though superficially
it looks that way. As to concise notation, I like it, but chacun a son gout ;-)

The idea was to substitute an iterator for the slice type in place of the PEP 276
iterator for int, and thereby get control over start, end, and step using a
familar (?!) syntax as a concise abbreviation for the *slice* type (unlike PEP 204,
which uses the syntax as a range literal resulting in a *list* type, UIAM).

Note that I was suggesting a "bare" slice, not "... the slicing literal syntax
attached to the int class ..." as mentioned in PEP 276.

Of course, a list expression is valid after 'in' so it might be a little messy
disambiguating a list expression from a "bare slice" in the grammar (which may be
a reason PEP 204 was rejected?). (Prefixing 'int' as rejected in PEP 276 solves the
grammar problem, but opens other considerations, as it mentions.)

Then again, you could just spell it out, avoiding the grammar problems, and using
an iterator more obviously based in the slice type:

     for i in slice(0,5,2):
         ...

Which could get rid of xrange(). Didn't someone say xrange() was bad? ;-)