[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). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com