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

Guido van Rossum guido@python.org
Sat, 12 Apr 2003 09:25:15 -0400

[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. :)

> > 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
> 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

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/)