12 Jul 2000 22:03:53 +0100
Paul Prescod <email@example.com> 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...