> But you acknowledge they are really the same method attached to
> different classes, right? The notion of "unbound method" is mostly an
> implementation detail. The term occurs only 4 times in the whole Python
> documentation (according to Google). And in py3k they are gone. (*)

It's the same function attached to two different classes.  I don't
really buy the "implementation detail" argument - if Guido says it,
then I don't have much choice but to accept it, but I'm going to
argue about it with anyone else. :)  In this case, I'd say it's
definitely not an implementation detail because it has major
consequences visible to applications.  If I get method x from
class A and try to call it with an instance of class B, then
it's going to break.  I have to know about this behavior in order
to write a program that works.  Py3k may be different, but I'm
not going to talk about Py3k here because I'm only interested
in the Python 2.x behavior.

> Moreover, you say you want them to compare unequal because you
> *explicitly* want the same method called separately for each class it is
> defined on. Is there anything preventing you to have a set of (class,
> method) tuples instead? Because it sounds like the logical thing to do
> in your case.

I could do that.  I probably will, too, since this code needs to work
on Python 2.3 through Python 2.5.  I still want to make Python 2.6
better, though.  It seems to me that an unbound method is already
effectively a tuple of (class, function) - it has a reference to both
of those.  Requiring applications to tie it up with a class again is
just redundant.

> "Trust" is a strong word. You can trust the comparison operator if you
> agree with its semantics, you cannot trust it if you want different
> semantics. But that doesn't mean it is generally trustworthy or
> untrustworthy.

You're right.  "trust" was a bad word to use there.

> I don't think there are lots of use cases for comparing *unbound*
> methods. One such use case is checking for redefinition of inherited
> methods, and the current __eq__ semantics look fine for that.

This use-case is already satisfied though - if an application wants
to see if the function is the same, then the application can compare
the im_func attribute of the method objects.