[Python-ideas] Optimizing builtins

[Michael Foord]

On 31 December 2010 18:49, Guido van Rossum <guido at python.org> wrote:

> [Changed subject *and* list]
>
> > 2010/12/31 Maciej Fijalkowski <fijall at 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 at 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



Actually range is the one I've seen *most* overridden, not in order to
replace functionality but because range is such a useful (or relevant)
variable name in all sorts of circumstances...

Michael


> (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 <http://python.org/%7Eguido>)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101231/75cea961/attachment.html>