Skip Montanaro <skip@mojam.com> writes:
> One of the original arguments for range literals as I recall was that
> indexing of loops could get more efficient. The compiler would know that
> [0:100:2] represents a series of integers and could conceivably generate
> more efficient loop indexing code (and so could Python2C and other compilers
> that generated C code). This argument doesn't seem to be showing up here at
> all. Does it carry no weight in the face of the relative inscrutability of
> the syntax?
IMHO, no. A compiler sufficiently smart to optimize range literals
ought to be sufficiently smart to optimize most calls to "range". At
least, I think so. I also think the inefficiency of list construction
in Python loops is a red herring; executing the list body involves
going round & round the eval loop, and I'd be amazed if that didn't
dominate (note that - on my system at least - loops involving range
are often (marginally) faster than ones using xrange, presumably due
to the special casing of list[integer] in eval_code2).
Sure, it would be nice is this aspect got optimized, but lets speed up
the rest of the interpreter enough so you can notice first!
Cheers,
Michael
--
Very rough; like estimating the productivity of a welder by the
amount of acetylene used. -- Paul Svensson, comp.lang.python
[on the subject of the measuring programmer productivity by LOC]
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