[Python-Dev] Should we do away with unbound methods in Py3k? (original) (raw)

Amaury Forgeot d'Arc amauryfa at gmail.com
Thu Nov 22 01:41:28 CET 2007

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

More information about the Python-Dev mailing list