[Python-3000] Bound and unbound methods (original) (raw)

Guido van Rossum guido at python.org
Wed Aug 16 17:48:46 CEST 2006


On 8/15/06, Calvin Spealman <ironfroggy at gmail.com> wrote:

On 8/16/06, Guido van Rossum <guido at python.org> wrote: > Right. I'm against anything that changes the current semantics. I'm > all for a compiler optimization that turns " . ( > )" into a single opcode that somehow manages to avoid creating the > bound object. As long as it also does the right thing in case the name > refers to something that's not quite a standard method -- be it a > class method or static method, or a class, or anything else callable > (or even not callable :-). And it would be fine if that optimization > wasn't used if there are keyword arguments, or *args or **kwds, or > more than N arguments for some N > 3 or so. > > But, as Thomas says, it was tried before and didn't quite work. Maybe > we can borrow some ideas from IronPython, which boasts a 7x faster > method call (or was it function call? it was a call anyway); and > according to Jim Hugunin only half of that speed-up (on a linear or > logarithmic scale? he didn't say) can be explained through the .NET > JIT.

Would a possible special method name methodcall be accepted, where if it exists on a callable, you can expect to use it as call but with the understanding that it accepts as self when called in an optimizable form? This would reduce the method call to two attribute lookups before the call instead of an instansiation and all the heavy lifting currently done. For normal functions, 'f.methodcall is f.call' may be true, but the existance of that methodcall name just gives you an extra contract.

I'd like to answer "no" (since I think this whole idea is not a very fruitful avenue) but frankly, I have no idea what you are trying to describe. Are you even aware of the descriptor protocol (get) and how it's used to create a bound method (or something else)?

No reply is needed.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-3000 mailing list