> The reason I noticed this is that since they compare and hash equal, if
> you put two such methods into a set, you end up with a set with one
> method.  Currently, this is preventing me from running two test methods
> because the method itself is defined on a base class and two subclasses
> which customize several other methods inherit it.  I can only run one
> test at a time.

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. (*)

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.

> Having them compare unequal means you can't actually trust unbound
> method comparison, nor using unbound methods as keys in a dictionary.

"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.

Really, this is the same as with numbers:

'b'

There are probably use cases where the above is annoying. But,
conversely, there are probably use cases where a stricter behaviour
would be annoying too.

> This means some other mapping structure is required if you want to keep
> around a bunch of methods and arguments to pass to them.

I disagree. The general use case of keeping a bunch of callables with
their respective arguments implies storing bound, not unbound, methods.
(how often do you feed an unbound method to an addCallback() ?)

> It also means
> that any time you want to check two methods against each other with the
> goal of eventually calling one or both of them, you need to use
> something other than `==´.

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.

(*)
Python 3.0b2+ (py3k, Jul 29 2008, 20:37:34)
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...  def f(): pass
...
>>> type(A.f)
<class 'function'>
>>> a = A()
>>> type(a.f)
<class 'method'>
>>> def g(): pass
...
>>> class B:
...  g = g
...
>>> B.g is g
True