Mark Seaborn wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
Mark Seaborn wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
I have seen a couple of objections to leaving unbound methods naked (as
functions) when retrieved in 3.0. Here is a plus.
A c.l.p poster reported that 2.6 broke his code because the addition of
default rich comparisons to object turned tests like hassattr(ob,
'__lt__') from False to True.
For the record, the post is:
http://mail.python.org/pipermail/python-list/2008-October/510540.html
The obvious fix ob.__lt__ == object.__lt__ does not work because
wrapping makes it always False, even when conceptually true. In
3.0, that equality test works. (I pointed him to 'object' in
repr(ob.__lt__) as a workaround. Others posted others.)
Assuming ob is an instance object,
It was a class derived from object. I should have made that clearer.
It appears that unbound methods do what you want in the general case
in Python 2.5 and 2.6. It's just that __lt__ behaves unlike normal
unbound methods. So this isn't an argument against unbound methods,
it's an argument for __lt__ not to be a special case.
It is not a special case.
>>> def C(object): pass
...
>>> C.__hash__ == object.__hash__
False
>>> C.__str__ == object.__str__
False
I strongly suspect that the same is true of every method that a user
class inherits from a builtin class. Still, the clp OP is specifically
interested in object as the base of his inheritance networks.
class C(object):
... def f(self): pass
... def g(self): pass
...
class D(C):
... def g(self): pass
...
C.f == D.f
True
C.g == D.g
False
It is slightly odd that C.f and D.f compare as equal when they are not
equivalent. It is not inconsistent with other cases where == returns
True on non-equivalent objects (such as dicts with equal content but
different identities), but it is odd for this to happen on a callable.
Interesting. MethodWrapper must have an over-riding equality method
that compare im.func attributes for the specific case of comparing
MethodWrappers. But not relevant to the specific need;-).
So my point remains: leaving unbound methods unwrapped makes Python3
work better for at least one real use case.
Terry Jan Reedy
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
