On Mon, Feb 2, 2015 at 10:00 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
As I indicated in an earlier response, there is some performance value
to replacing the range function call with this (or other) syntactic

It's my impression that adding stuff like this primarily for performance is nothing on the list ;-)

But you could get the same effect by making range a keyword -- how often does anyone re-define it?

And if you allow variables:

range(i,j,k)  or (i:j:k)

Then any optimizer needs to to run-time type checking, or type inference, or what have you anyway, so checking if the name range is the range object seems like a small issue.

FWIW, Cython does turn range calls into simple C loops:

for i in range(10):


for (__pyx_t_1 = 0; __pyx_t_1 < 10; __pyx_t_1+=1) {

In that case, the cython "language" doesn't allow re-defining of "range"

And it will do this if either literals or variables that have been type-def'd as integer types are passed in as arguments.

What difference this really makes to performance I have no idea -- you'd have to have something pretty trivial in that loop to notice it.


While exceedingly rare, there is nothing to prevent a
programmer from redefining the range builtin function or inserting a
different version of range() in the local or global scopes:

    def my_range(*args):
        # completely ignore args, returning something weird...
        return [1, "a", None, 2]

    import __builtin__
    __builtin__.range = my_range

If you have a for loop which uses range():

    for i in range(27):
        do something interesting with i

optimizers like PyPy which aim to be precisely compatible with CPython
semantics must look up "range" every time it occurs and decide if it's
the real builtin range function, in which case it can emit/execute
machine code which is something like the C for loop:

    for (i=start; i<stop; i+=step) {
        do something interesting with i

or not, in which case it has to call whatever range is, then respond
with its list of (arbtrary) Python objects.

Syntactic sugar would lock down the standard behavior.

Python-ideas mailing list


Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception