[Python-Dev] range() as iterator (Re: More int/long integration
Guido van Rossum
Sat, 12 Apr 2003 09:25:15 -0400
> >>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. :)
> > range() can't be changed from returning a list until at least Python
> > 3.0.
> Is this change really necessary ? Instead of changing the semantics
> of range() why not have the byte code compiler optimize it's typical
> for i in range(10):
> 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
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/)