Paul Prescod <paul@prescod.net> writes: > 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> Hmm, yes, but how on earth would you implement that in ceval.c? You'd need another eval loop inside the code for FOR_INTS! (unless I'm being dense, of course). > 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> To invent more statistics on the spot, I'll declare that loop overhead is a problem in about 3.4% of all interesting loops; what we need is a way to execute the body quicker... Cheers, M.
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