[Python-3000] Bound and unbound methods
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 "<expr> . <name> ( <args>
> > )" 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 <expr> 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