[Changed subject *and* list]

> 2010/12/31 Maciej Fijalkowski <fijall@gmail.com>
>> How do you know that range is a builtin you're thinking
>> about and not some other object?

On Fri, Dec 31, 2010 at 7:02 AM, Cesare Di Mauro
<cesare.di.mauro@gmail.com> wrote:
> By a special opcode which could do this work. ]:-)

That can't be the answer, because then the question would become "how
does the compiler know it can use the special opcode". This particular
issue (generating special opcodes for certain builtins) has actually
been discussed many times before. Alas, given Python's extremely
dynamic promises it is very hard to do it in a way that is
*guaranteed* not to change the semantics. For example, I could have
replaced builtins['range'] with something else; or I could have
inserted a variable named 'range' into the module's __dict__. (Note
that I am not talking about just creating a global variable named
'range' in the module; those the compiler could recognize. I am
talking about interceptions that a compiler cannot see, assuming it
compiles each module independently, i.e. without whole-program
optimizations.)

Now, *in practice* such manipulations are rare

(with the possible
exception of people replacing open() with something providing hooks
for e.g. a virtual filesystem) and there is probably some benefit to
be had. (I expect that the biggest benefit might well be from
replacing len() with an opcode.) I have in the past proposed to change
the official semantics of the language subtly to allow such
optimizations (i.e. recognizing builtins and replacing them with
dedicated opcodes). There should also be a simple way to disable them,
e.g. by setting "len = len" at the top of a module, one would be
signalling that len() is not to be replaced by an opcode. But it
remains messy and nobody has really gotten very far with implementing
this. It is certainly not "low-hanging fruit" to do it properly.

I should also refer people interested in this subject to at least
three PEPs that were written about this topic: PEP 266, PEP 267 and
PEP 280. All three have been deferred, since nobody was bold enough to
implement at least one of them well enough to be able to tell if it
was even worth the trouble. I haven't read either of those in a long
time, and they may well be outdated by current JIT technology. I just
want to warn folks that it's not such a simple matter to replace "for
i in range(....):" with a special opcode.

(FWIW, optimizing "x[i] = i" would be much simpler -- I don't really
care about the argument that a debugger might interfere. But again,
apart from the simplest cases, it requires a sophisticated parser to
determine that it is really safe to do so.)

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas