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. >>> 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 >>> C.__str__ == D.__str__ True >>> C.__str__ == object.__str__ True 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. Mark _______________________________________________ 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
