[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