[Python-checkins] cpython (merge 3.2 -> default): Merge #14617: clarify discussion of interrelationship of __eq__ and __hash__.
r.david.murray
python-checkins at python.org
Tue Sep 11 19:02:29 CEST 2012
http://hg.python.org/cpython/rev/c8d60d0c736b
changeset: 78997:c8d60d0c736b
parent: 78995:8042b87bb762
parent: 78996:957e1eef3296
user: R David Murray <rdmurray at bitdance.com>
date: Tue Sep 11 13:02:13 2012 -0400
summary:
Merge #14617: clarify discussion of interrelationship of __eq__ and __hash__.
files:
Doc/reference/datamodel.rst | 26 ++++++++++++------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst
+++ b/Doc/reference/datamodel.rst
@@ -1271,22 +1271,22 @@
and ``x.__hash__()`` returns an appropriate value such that ``x == y``
implies both that ``x is y`` and ``hash(x) == hash(y)``.
- Classes which inherit a :meth:`__hash__` method from a parent class but
- change the meaning of :meth:`__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 :exc:`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 :meth:`__hash__` to explicitly raise :exc:`TypeError`).
+ A class that overrides :meth:`__eq__` and does not define :meth:`__hash__`
+ will have its :meth:`__hash__` implicitly set to ``None``. When the
+ :meth:`__hash__` method of a class is ``None``, instances of the class will
+ raise an appropriate :exc:`TypeError` when a program attempts to retrieve
+ their hash value, and will also be correctly identified as unhashable when
+ checking ``isinstance(obj, collections.Hashable``).
If a class that overrides :meth:`__eq__` needs to retain the implementation
of :meth:`__hash__` from a parent class, the interpreter must be told this
- explicitly by setting ``__hash__ = <ParentClass>.__hash__``. Otherwise the
- inheritance of :meth:`__hash__` will be blocked, just as if :attr:`__hash__`
- had been explicitly set to :const:`None`.
+ explicitly by setting ``__hash__ = <ParentClass>.__hash__``.
+
+ If a class that does not override :meth:`__eq__` wishes to suppress hash
+ support, it should include ``__hash__ = None`` in the class definition.
+ A class which defines its own :meth:`__hash__` that explicitly raises
+ a :exc:`TypeError` would be incorrectly identified as hashable by
+ an ``isinstance(obj, collections.Hashable)`` call.
.. note::
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list