> Guido writes: > > IMO, xrange() must die. > > > > As a compromise to practicality, it should lose functionality, not > > gain any. [Michael Chermside] > Glad to hear it. I always found range() vs xrange() a wart. It is, and it is one that I hate. > But if you had it do do over, how would you do it? I'd make range() an iterator. To get a concrete list that you can modify, you'd have to write list(range(N)). But that can't be done without breaking backwards compatibility, so I won't. [David Abrahams] > OK, range() becomes lazy, then? Or is there another plan? The bytecode compiler should be clever enough to see that you're writing for i in range(...): ... and that there's no definition of range other than the built-in one (this requires a subtle change of language rules); it can then substitute an internal equivalent to xrange(). --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