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

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