Python 2.2b1 hashable dictionary bug?

[Tim Peters]

[Tim]
> It should suffice to override just __eq__ and __hash__.  However, you
> can't override __eq__ via object.__eq__ [because object.__eq__ doesn't
> exist].

[Rainer Deyke]
> That's surprising (and therefore probably a bad thing).

I don't know why it's surprising to you.  Rich comparisons are optional
behaviors; object only supplies defaults for a minimum of required
behaviors.

> My first expectation was for something like this:
>
> class object:
>   def __eq__(self, other):
>     return id(self) == id(other)
>
> The problem with that is that it breaks '__cmp__'.  My second
> expectation was for something like this:
>
> class object:
>   def __cmp__(self, other):
>     return cmp(id(self), id(other))
>   def __eq__(self, other):
>     return self.__cmp__(other) == 0
>
> I see no reason why this has not been included.

I'm not clear on what you're saying, but whatever it is I'm sure life isn't
that simple <wink>.  Note that object is *itself* an object:

>>> object.__class__
<type 'type'>
>>>

and object.__cmp__ is actually defined by object's class, the type "type"
(of course type doesn't provide a default implementation for rich
comparisons either -- else object.__eq__ would have succeeded):
object.__cmp__ is not an all-purpose "compare any two objects" function,
it's a bound method accepting one argument and comparing it to object
specifically (just as, e.g., (2).__cmp__ is a bound method that compares its
argument to 2 specifically).

>>> object.__cmp__(object)
0
>>> object.__cmp__(type)
1
>>>

type.__cmp__ is closer to what you seem to have in mind, although that's a
method restricted to comparing objects of type type (incl. subclasses of
type).

If you want to define your own comparisons, define them explicitly and
you'll have no problems.

plus-as-an-added-bonus-your-head-won't-explode-ly y'rs  - tim