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

Calvin Spealman ironfroggy at gmail.com
Wed Aug 16 07:48:00 CEST 2006

On 8/16/06, Guido van Rossum <guido at python.org> wrote:

On 8/13/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > Talin wrote: > > the compiler would note the combination of the attribute access and the > > call, and combine them into an opcode that skips the whole method > > creation step. > > Something like that could probably be made to work. You'd > want to be careful to do the optimisation only when the > attribute in question is an ordinary attribute, not > a property or other descriptor. > > I'm also -1 on eliminating bound methods entirely. > I worked through that idea in considerable depth during my > discussions with the author of Prothon, which was also to > have been without any notion of bound methods. The > consequences are further-reaching than you might think at > first. The bottom line is that without bound methods, > Python wouldn't really be Python any more.

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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

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.

More information about the Python-3000 mailing list