[Python-Dev] Let's get rid of unbound methods

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

> 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