Chris Angelico <ros...@gmail.com> wrote: > On Fri, Dec 9, 2011 at 4:32 AM, Peter Otten <__pete...@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 keys hash > value is immutable (if the objects 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 -- http://mail.python.org/mailman/listinfo/python-list
