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