On Nov 21, 2007 4:33 PM, Michael Foord <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
