[Python-Dev] [python] Should we do away with unbound methods in Py3k?

[Michael Foord]

Guido van Rossum wrote:
> I'm asking a Py3k question on python-dev because I'd like to have
> opinions from people who haven't thought about Py3k much yet. Consider
> the following example:
>
>   class C:
>       def foo(self): pass
>
>   C.foo(42)
>
> This currently fails with this error message:
>
>   TypeError: unbound method foo() must be called with C instance as
> first argument (got int instance instead)
>
> This message is called when isinstance(self, C) returns False, where
> self is the first argument passed to the unbound method.
>
> That's nice, but there is a cost associated with this: the expression
> "C.foo" can't just return the function object "foo", it has to wrap it
> in an unbound method object. In Py3k the cost of calling an unbound
> method object goes up, because the isinstance() check may be
> overloaded. This typically happens when the class C uses the special
> metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119).
> in Py3k the I/O stream classes are perhaps the most common use case.
>
> Given that the error is of limited value and that otherwise the
> unbound method behaves exactly the same as the original function
> object, I'd like to see if there are strenuous objections against
> dropping unbound method objects altogether (or at least not using them
> in this case), so that explicit super calls (via the unbound method)
> may go a little faster. Also, it would make it easier to fix this
> issue: http://bugs.python.org/issue1109
>   

On occasions I've found it a drag that you *can't* call unbound methods 
with a different type. Python normally allows duck typing and this is 
one place it actually places type restrictions...

I'd be happy to see this restriction go. :-)

Michael Foord