On 11/2/05, Josiah Carlson <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
