[Python-3000] Bound and unbound methods

[Calvin Spealman]

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