[Python-3000] Bound and unbound methods

Guido van Rossum guido at python.org
Wed Aug 16 06:13:11 CEST 2006

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

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

More information about the Python-3000 mailing list