Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Peter Otten <__peter__@web.de>
Newsgroups: comp.lang.python
Subject: Re: hash values and equality
Followup-To: comp.lang.python
Date: Sat, 21 May 2011 11:24:40 +0200
Organization: None
Lines: 29
Message-ID: <ir80ci$q5u$1@solani.org>
References: <4DD2C2A5.3080403@stoneleaf.us> <BANLkTimvzZeN5dmm2xHP5xV8Kpw2Nb9kuQ@mail.gmail.com> <4DD2D89D.4000303@stoneleaf.us> <BANLkTintqgBLFtBx8+1b+R10nywuKdKHOw@mail.gmail.com> <4DD2F661.2050005@stoneleaf.us> <BANLkTikx8U4jWwLXXazpmtsL6MasDmyVyg@mail.gmail.com> <BANLkTi=_GqrNntRU7pv7x=kj3gHurk-Gaw@mail.gmail.com> <mailman.1822.1305870290.9059.python-list@python.org> <0deha8-6u9.ln1@satorlaser.homedns.org> <mailman.1850.1305915987.9059.python-list@python.org> <93pb5nF3gtU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Trace: solani.org 1305969875 26814 eJwFwYkBwCAIA8CVtCSpjIM8+4/gHU1b+UMUOByUCxPdfi2DXw1PXAFW6bniZvU6XXSrTcYDObESIw== (21 May 2011 09:24:35 GMT)
X-Complaints-To: abuse@news.solani.org
NNTP-Posting-Date: Sat, 21 May 2011 09:24:35 +0000 (UTC)
X-User-ID: eJwNwgkRBDEMAzBKTvPD8aUpfwh7I7mGxKSFh/n7O2SdzpdYy7hC5aUjfvZGd3KmL9HoNS3MEXiuu0qiWPwAVGYVKA==
Cancel-Lock: sha1:vcpxaLL790kb82jNQHzxAeVDmDk=
X-NNTP-Posting-Host: eJwFwQkBACAIA8BKirJBHD77R/BODzaKF4qrT9+S4FUB3Lpi69u2YBN1jN49I8KQHeI9TmZZDBArV/bJwgTS56gWjQF+yO4aMw==
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5911

Gregory Ewing wrote:

> Ethan Furman wrote:
>> Ulrich Eckhardt wrote:
>> 
>>> If two equal objects have different hashes, they
>>> will be stored in different places in the hash map. Looking for
>>> object1 will then not turn up with object2, even though they are equal.
>> 
>> In this case this is the behavior I want.
> 
> You can't rely on it, though. The hash value gets reduced
> modulo the size of the dict, so even if two objects have
> different hashes, in some cases they will land on the same
> dict slot anyway.
> 
> So an object such as you're postulating would behave
> unpredictably when used as a dict key. Sometimes a lookup
> using a different but equal object would find it, and
> sometimes not, seemingly at random.

I think for every potential match the current dict implementation checks 
identity, then hashes -- and equality only if the hash values are equal. The 
relevant function is lookdict() in dictobject.c.

While that means that the problem you describe cannot occur a simple 
approach that avoids relying on an implementation detail (?) would be to use 
(hash(obj), obj) tuples instead of just obj as the key.