[Python-Dev] Possible optimization for LOAD_FAST ?

Michael Foord fuzzyman at voidspace.org.uk
Wed Jan 5 00:36:32 CET 2011

On 04/01/2011 23:29, Guido van Rossum wrote:
> On Tue, Jan 4, 2011 at 3:13 PM, Steven D'Aprano<steve at pearwood.info>  wrote:
>> Guido van Rossum wrote:
>>> But why couldn't you edit the source code?
>> Because there was no source code -- I was experimenting in the interactive
>> interpreter. I could have just re-created the function by using the readline
>> history, but it was just easier to redefine len.
> The interactive interpreter will always be excluded from this kind of
> optimization (well, in my proposal anyway).
>> Oh... it's just occurred to me that you were asking for use-cases for
>> assigning to builtins.len directly, rather than just to len. No, I've never
>> done that -- sorry for the noise.
> There are two versions of the "assign to global named 'len'" idiom.
> One is benign: if the assignment occurs in the source code of the
> module (i.e., where the compiler can see it when it is compiling the
> module) the optimization will be disabled in that module.
> The second is not: if a module-global named 'len' is set in a module
> from outside that module, the compiler cannot see that assignment when
> it considers the optimization, and it may generate optimized code that
> will not take the global by that name into account (it would use an
> opcode that computes the length of an object directly).
> The third way to mess with the optimization is messing with
> builtins.len. This one is also outside what the compiler can see.
> [...]
>> Ha, well, that's the sort of thing that gives monkey-patching a bad name,
>> surely?
> Monkey-patching intentionally has a bad name -- there's always a code
> smell. (And it looks like one, too. :-)
>> Is there a use-case for globally replacing builtins for all modules,
>> everywhere? I suppose that's what you're asking.
> I think the folks referring to monkey-patching builtins in unittests
> were referring to this. But they might also be referring to the second
> option above.

The only examples I could find from a quick search (using the patch 
decorator from my mock module which is reasonably well used) patch 
__builtins__.open and raw_input.



Michael Foord

>> The only example I can think of might be the use of mocks for testing
>> purposes, but even there I'd prefer to inject the mock into the module I was
>> testing:
>> mymodule.len = mylen
>> But I haven't done much work with mocks, so I'm just guessing.
> Same here. But it would fail (i.e. not be picked up by the
> optimization) either way.


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