). Nun bin ich mir gar nicht sicher was da genau passiert.
Code: Alles auswählen
>>> d = {'a': 42, 'b': 23}
>>> d
{'a': 42, 'b': 23}
>>> d['a'] = 1337
>>> d
{'a': 1337, 'b': 23}
>>> 'a' == 'a'
True
>>> hash('a') == hash('a')
True
Code: Alles auswählen
class Point(object):
def __init__(self, x, y):
self.x = x
self.y = y
def __cmp__(self, other):
return cmp((self.x, self.y), (other.x, other.y))
def __hash__(self):
return hash((self.x, self.y))
Code: Alles auswählen
>>> class Foo(object):
... def __init__(self, bar, baz):
... self.bar = bar
... self.baz = baz
... def __repr__(self):
... return '{}(bar={!r}, baz={!r})'.format(
... self.__class__.__name__,
... self.bar,
... self.baz)
... def __eq__(self, other):
... return self.bar == other.bar and self.baz == other.baz
... def __ne__(self, other):
... return not (self == other)
... def __hash__(self):
... return hash(self.bar) ^ hash(self.baz)
...
>>> foo1 = Foo(23, 42)
>>> foo2 = Foo(23, 42)
>>> map(hash, [foo1, foo2])
[61, 61]
>>> foo1 == foo2
True
>>> d = {foo1: 'this is foo1'}
>>> d
{Foo(bar=23, baz=42): 'this is foo1'}
>>> d[foo2] = 'this is foo2'
>>> d
{Foo(bar=23, baz=42): 'this is foo2'}Nein, ist es nicht und deswegen wurde dies in Python 3.x geändert, so dass __hash__ nicht mehr vererbt wird wenn Vergleichsoperationen implementiert werden (oder zumindest __eq__).syntor hat geschrieben:Jedes benutzerdefinierte Objekt hat eine __hash__ Methode, sie gibt standardmässig id(self) zurück. Das sich daraus ergebende Verhalten ist vollkommen intuitiv, finde ich.
Ich verstehe nicht, weshalb meine Aussage nicht stimmen soll.object.__hash__(self)¶
Called by built-in function hash() and for operations on members of hashed collections including set, frozenset, and dict. __hash__() should return an integer. The only required property is that objects which compare equal have the same hash value; it is advised to somehow mix together (e.g. using exclusive or) the hash values for the components of the object that also play a part in comparison of objects.
If a class does not define a __cmp__() or __eq__() method it should not define a __hash__() operation either; if it defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable in hashed collections. If a class defines mutable objects and implements a __cmp__() or __eq__() method, it should not implement __hash__(), since hashable collection implementations require that a object’s hash value is immutable (if the object’s hash value changes, it will be in the wrong hash bucket).
User-defined classes have __cmp__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns id(x).
Classes which inherit a __hash__() method from a parent class but change the meaning of __cmp__() or __eq__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError).
Changed in version 2.5: __hash__() may now also return a long integer object; the 32-bit integer is then derived from the hash of that object.
Changed in version 2.6: __hash__ may now be set to None to explicitly flag instances of a class as unhashable.
lunar hat geschrieben:@DasIch: Die Quelle für Deine Behauptung hinsichtlich der Änderung im Verhalten von "__hash__()" und Python 3?
http://docs.python.org/py3k/reference/datamodel.html#object.__hash__ hat geschrieben: If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = <ParentClass>.__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None.
Es kommt recht häufig vor das __eq__ implementiert wird __hash__ aber weder auf None gesetzt wird oder implementiert wird.Ich verstehe auch nicht ganz, was nicht intuitiv daran sein soll, Hashing und Gleichheit standardmäßig über Objektidentität zu implementieren. Ich finde das ziemlich naheliegend, zumal andere Sprache sich genauso verhalten, und es eigentlich keine sinnvolle Alternative gibt.