[Python-3000] A plus for naked unbound methods

[Mark Seaborn]

Terry Reedy <tjreedy at udel.edu> wrote:

> Mark Seaborn wrote:
> > Terry Reedy <tjreedy at udel.edu> 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