[Python-3000] object.__hash__()

[Steven Bethard]

[Guido van Rossum]
> I propose to take the same approach as for callable: if it has
> __hash__ we consider it hashable even though the hash may fail

[Greg Ewing]
> Fair enough, although since object has __hash__
> we end up concluding that everything is
> hashable except when it isn't. :-)

[Guido van Rossum]
> Ouch, that's a problem indeed. There's not really a clean way out
> unfortunately: either we remove object.__hash__ and let hash() do the
> default implementation, and then presence of __hash__ is no longer an
> indicator of hashability; or we keep it, and override it to raise an
> exception in unhashable types (like list.__hash__ does); or we remove
> the hashability of objects by default, which lets us solve the above
> problems at the cost of having a convenient hash by default.

If I understand the problem right, the reason for not wanting to
remove __hash__ from object  is that it's often convenient to have a
dict or set where objects are compared by id() instead of by value.
One alternative that I didn't see mentioned is to drop
object.__hash__() and introduce something like collections.iddict()
and collections.idset() for these purposes. Basically, we'd be moving
the "default implementation" of hash() into the specific classes that
needed it.

I guess you might then need to add id* variants of some user-defined
collection classes.  How big of an issue this is depends on how common
it is to create a user-defined collection class that (1) requires
hashing and (2) needs to be able to compare objects either by value or
id().

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy