[Python-Dev] range() as iterator (Re: More int/long integration issues)

[Guido van Rossum]

[Chad Netzer]
> >>I'd like to work on this.  I've already written a C range() iterator
> >>(incorporating PyLongs), and it would be very nice to have it
> >>automatically be a lazy range() when used in a loop.
> >>
> >>In any case, assuming you are quite busy, but would consider this for
> >>the 2.4 timeframe, I will do some work on it. If it is already being
> >>covered, I'll gladly stay away from it. :)

[Guido]
> > range() can't be changed from returning a list until at least Python
> > 3.0.

[MAL]
> Is this change really necessary ? Instead of changing the semantics
> of range() why not have the byte code compiler optimize it's typical
> usage:
> 
> for i in range(10):
>     pass
> 
> In the above case, changing the byte code compiler output would
> not introduce any change in semantics. Even better, the compiler
> could get rid off the function call altogether.

Right.  That's nice, and can be done before 3.0 (as soon as we change
the rules so that adding a 'range' attribute to a module object is
illegal).

My musing about making range() an iterator or iterator well comes from
the observation that if I had had iterators as a concept from day one,
I would have made several things iterators that currently return
lists, e.g. map(), filter(), and range().  The need for the concrete
list returned by range() (outside the tutorial :-) is rare; in those
rare cases you could say list(range(...)).

Whether this is indeed worth changing in 3.0 isn't clear, that depends
on the scope of 3.0, which isn't defined yet (because I haven't had
time to work on it, really).  I certainly plan to eradicate xrange()
in 3.0 one way or another: TOOWTDI.

--Guido van Rossum (home page: http://www.python.org/~guido/)