[Python-Dev] Let's get rid of unbound methods (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Jan 4 19:57:10 CET 2005

[Guido]

In my blog I wrote:

Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code)

Really? Unbound methods are used most often (IME) to call a base-class method from a subclass, like my_base.the_method(self, ...). It's especially easy to forget to write self, there, and the exception msg then is quite focused because of that extra bit of type checking. Otherwise I expect we'd see a more-mysterious AttributeError or TypeError when the base method got around to trying to do something with the bogus self passed to it.

I could live with that, though.

and sometimes you have to work around it;

For me, 0 times in ... what? ... about 14 years .

it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing.

Yup, it is a complication, without a compelling use case I know of. Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType is defined once and used once (believe it or not, in unittest.py).

More information about the Python-Dev mailing list