[Python-Dev] Par-for/range

[Michael Hudson]

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.