Thomas Wouters wrote: > > ... > > For that reason I think it's better to live with xrange() ;) Thinking some more... If we had first class range syntax then it would be relatively easy to recognize the pattern for i in [x:y:z]: .... Then we could generate a special FOR_INTS bytecode. I've heard that "C" has a pretty efficient implementation of that construct. <wink> That would wipe out 96.3% of the need for xrange or tuplerange or whatever you want to call it. We could probably deprecate both functions and let the rare person who really wants an xrange use a class or math.xrange() or mxtools.xrange() or a lazy list comprehension (if we invent those!). Plus, if your loops are so large that they need xrange, you would probably get an interesting speedup from using a real C for-loop instead of an object! I mean for small values xrange is slower than range and when you think about what range is doing under the covers. <shudder> -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html
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