On 04/01/2011 23:29, Guido van Rossum wrote:
On Tue, Jan 4, 2011 at 3:13 PM, Steven D'Apranosteve@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.
I prefer monkey patching builtins (where I do such a thing) in the namespace where they are used. I know it is common to monkeypatch __builtins__.open (python 2) however.
I don't recall monkey patching anything other than open and raw_input myself but I bet there are people doing it for reasons they see as legitimate in tests. :-)
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