[Python-Dev] Possible optimization for LOAD_FAST ?

Michael Foord fuzzyman at voidspace.org.uk
Tue Jan 4 11:49:04 CET 2011

On 04/01/2011 01:02, Guido van Rossum wrote:
> On Mon, Jan 3, 2011 at 9:52 AM, David Malcolm<dmalcolm at redhat.com>  wrote:
>> On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote:
>>> On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor<alex.gaynor at gmail.com>  wrote:
>>>> No, it's singularly impossible to prove that any global load will be any given
>>>> value at compile time.  Any optimization based on this premise is wrong.
>>> True.
>>> My proposed way out of this conundrum has been to change the language
>>> semantics slightly so that global names which (a) coincide with a
>>> builtin, and (b) have no explicit assignment to them in the current
>>> module, would be fair game for such optimizations, with the
>>> understanding that the presence of e.g. "len = len" anywhere in the
>>> module (even in dead code!) would be sufficient to disable the
>>> optimization.
>>> But barring someone interested in implementing something based on this
>>> rule, the proposal has languished for many years.
>> Is there a PEP for this?
> Not that I know of, otherwise I'd have mentioned it. :-)
> It would be useful if someone wrote it up, since the idea comes back
> in one form or another regularly.
>>> FWIW, this is reminiscent of Fortran's rules for "intrinsics" (its
>>> name for builtins), which have a similar optimization behavior (except
>>> there the potential overrides that the compiler doesn't need to take
>>> into account are load-time definitions).
>> I've been attempting another way in:
>>   http://bugs.python.org/issue10399
>> using a new "JUMP_IF_SPECIALIZABLE" opcode.  This compares what a value
>> is against a compile-time prediction, branching to an optimized
>> implementation if the guess was correct.  I use this to implement
>> function-call inlining within the generated bytecode.
> Yeah, that's what everybody proposes to keep the language semantics
> unchanged. But I claim that an easier solution is to say to hell with
> those semantics, let's change them to make the implementation simpler.
> That's from the Zen of Python: "If the implementation is easy to
> explain, it may be a good idea." I guess few people can seriously
> propose to change Python's semantics, that's why *I* am proposing it.
> :-) Note that the semantics of locals (e.g. UnboundLocalError) were
> also changed specifically to allow a significant optimization -- again
> by me.

I think someone else pointed this out, but replacing builtins externally 
to a module is actually common for testing. In particular replacing the 
open function, but also other builtins, is often done temporarily to 
replace it with a mock. It seems like this optimisation would break 
those tests.


>> Caveat-of-doom: That code's very much a work-in-progress at this stage,
>> though: sometimes it doesn't segfault :) and the way that I track the
>> predicted values is taking some other liberties with semantics (see that
>> URL and the dmalcolm-ast-optimization-branch in SVN).
>> (There's probably at least 2 PEPs in the above idea, though have yet to
>> write my first PEP)
> If you want to write up a PEP for the semantics change I am proposing,
> everything you need is in this thread.


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

More information about the Python-Dev mailing list