Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 20 May 2011 10:56:02 -0700
From: Ethan Furman <ethan@stoneleaf.us>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Chris Rebert <clp2@rebertia.com>
Subject: Re: hash values and equality
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>	<4DD5FF8F.604@stoneleaf.us> <BANLkTikaJnjK57ySq0hzZwUOUFaQo+accw@mail.gmail.com>
In-Reply-To: <BANLkTikaJnjK57ySq0hzZwUOUFaQo+accw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: python list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1845.1305913428.9059.python-list@python.org>
Lines: 72
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:5862

Chris Rebert wrote:
> On Thu, May 19, 2011 at 10:43 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> Several folk have said that objects that compare equal must hash equal, and
>> the docs also state this
>> http://docs.python.org/dev/reference/datamodel.html#object.__hash__
>>
>> I'm hoping somebody can tell me what horrible thing will happen if this
>> isn't the case?  Here's a toy example of a class I'm thinking of writing
>> that will compare equal with int's, but hash differently:
> 
> This is the part considered "horrible":
>> --> d
>> {<Wierd object at 0x00BFE870>: '3',
>>  1: '1.0',
>>  2: '2.0',
>>  3: '3.0',
>>  <Wierd object at 0x00BFE830>: '2',
>>  <Wierd object at 0x00BFE710>: '1'}
> 
> Compare:
>>>> x = {5.0 : 'foo'}
>>>> x[5]
> 'foo'
> 
> Here's a more common/plausible "horrible" case closer to what the docs
> writers had in mind:
>--> class Naughty(object):
> ...     def __init__(self, n):
> ...         self.n = n
> ...     def __eq__(self, other):
> ...         return self.n == other.n
> ...
>--> Naughty(5) == Naughty(5)
> True
>--> Naughty(5) is Naughty(5)
> False
>--> bad = Naughty(3)
>--> y = {bad : 'foo'}
>--> y[bad] # just happens to work
> 'foo'
>--> del bad
>--> # ok, how do we get to 'foo' now?
>--> y[Naughty(3)] # try the obvious way
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> KeyError: <__main__.Naughty object at 0x2a1cb0>
>--> # We're screwed.
> 
> Naughty instances (and similar) can't be used sensibly as hash keys
> (unless you /only/ care about object identity; this is often not the
> case).

I tried this sequence (using Python 3, BTW -- forgot to mention that 
little tidbit -- sorry!):

--> del two
--> two
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name 'two' is not defined
--> d
{<__main__.Wierd object at 0x00C0C950>: '3',
  1: '1.0',
  2: '2.0',
  3: '3.0',
  <__main__.Wierd object at 0x00B3AC10>: '2',
  <__main__.Wierd object at 0x00B32E90>: '1'}
--> new_two = Wierd(2)
--> d[new_two]
'2'

~Ethan~