[Python-Dev] Why should the default hash(x) == id(x)?

[Noam Raphael]

On 11/2/05, Josiah Carlson <jcarlson at uci.edu> wrote:
...
>
> A quick search in the list archives via google search
>    "site:mail.python.org object __hash__"
> Says that Guido wanted to remove the default __hash__ method for object
> in Python 2.4, but that never actually happened.
>
> http://www.python.org/sf/660098
> http://mail.python.org/pipermail/python-dev/2003-December/041375.html
>
> There may be more code which relies on the default behavior now, but
> fixing such things is easy.
>
Cool! If Guido also thinks that it should be gone, who am I to argue...

(Seriously, I am in favor of removing it. I really think that it is confusing.)

And if backwards-compatibility is a problem: You can, in Python 2.5,
show a warning when the default __hash__ method is being called,
saying that it is going to disappear in Python 2.6.

[Snip - I will open a new thread about the equality operator]

> As for removing the default __hash__ for objects, I'm actually hovering
> around a -0, if only because it is sometimes useful to generate unique
> keys for dictionaries (which can be done right now with object() ), and
> I acknowledge that it would be easy to subclass and use that instead.
>
I can suggest a new class, that will help you in the cases that you do
want a dict of identities:

class ref(object):
    def __init__(self, obj):
        self._obj = obj
    def __call__(self):
        return self._obj
    def __eq__(self, other):
        return self._obj is other._obj
    def __hash__(self):
        return hash(id(self._obj))

It has the advantage over using ids as keys, that it saves a reference
to the object, so it won't be killed.

It lets you make a dict of object identities just as easily as before,
in a more explicit and error-prone way. Perhaps it should become a
builtin?

Noam