[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4