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

[Amaury Forgeot d'Arc]

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.

Could we check for "real" inheritance first, and call
__instancecheck__ only when the previous is false? It would speed-up
the common cases.
Or is there really a use case for a derived class to appear as NOT
being a subclass of its base class?

-- 
Amaury Forgeot d'Arc