[Python-Dev] Possible optimization for LOAD_FAST ?

Guido van Rossum guido at python.org
Wed Jan 5 00:29:37 CET 2011

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 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.

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list