adding elements to set

[Duncan Booth]

Chris Angelico <rosuav at gmail.com> wrote:

> On Fri, Dec 9, 2011 at 4:32 AM, Peter Otten <__peter__ at web.de> wrote:
>> The only thing that has changed (in 2.7) is the algorithm to
>> calculate the hash value. The bits are rotated to turn the four least
>> significant bits into the most signicant ones. According to a comment
>> in Objects/objects.c the change leads to fewer hash collisions.
> 
> Interesting, but what I saw was this:
> 
>>>> class C(object):
> 
>    def __init__(self, x):
>        self.x = x
> 
>    def __eq__(self, other):
>        return self.x == other.x
> 
>>>> s=set()
>>>> c1=C(1)
>>>> s.add(c1)
> Traceback (most recent call last):
>   File "<pyshell#163>", line 1, in <module>
>     s.add(c1)
> TypeError: unhashable type: 'C'
> 
> (This is in IDLE from Python 3.2 on Windows.)
> 
> However, s.add(object()) works fine. So subclasses don't get that.
> Odd. Makes sense though - you can't get this unexpected behaviour as
> easily.
> 
Yes, the documentation describes this although I don't think anything 
highlights that it is a change from Python 2.x:

[http://docs.python.org/py3k/reference/datamodel.html]

> If a class does not define an __eq__() method it should not define a
> __hash__() operation either; if it defines __eq__() but not
> __hash__(), its instances will not be usable as items in hashable
> collections. If a class defines mutable objects and implements an
> __eq__() method, it should not implement __hash__(), since the
> implementation of hashable collections requires that a key’s hash
> value is immutable (if the object’s hash value changes, it will be in
> the wrong hash bucket). 

So in Python 2.x you could define __eq__ and get the default __hash__ which 
would break dictionaries. With Python 3.x defining __eq__ will disable the 
default __hash__ although if you subclass a class that has both methods you 
could still get in a mess by redefining one without the other.


-- 
Duncan Booth http://kupuguy.blogspot.com