[Python-3000] A plus for naked unbound methods

[Terry Reedy]

Mark Seaborn wrote:
> 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.

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