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

Steven Bethard steven.bethard at gmail.com
Thu Nov 22 01:25:52 CET 2007

On Nov 21, 2007 4:33 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

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. :-)

I agree.

Though I'd like to know what happens when I do something like::

>>> class C(object):
...     def __setitem__(self, key, value):
...         print key, value
...
>>> c = C()
>>> dict.update(c, foo='bar')
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
TypeError: descriptor 'update' requires a 'dict' object but received a 'C'

I assume the code will fail (though it would be really cool if it didn't). How will it fail?

STeVe

I'm not in-sane. Indeed, I am so far out of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

More information about the Python-Dev mailing list