Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
d8bbde35
Commit
d8bbde35
authored
Sep 11, 2012
by
R David Murray
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
#14617: clarify discussion of interrelationship of __eq__ and __hash__.
parent
5557a9c7
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
13 additions
and
13 deletions
+13
-13
Doc/reference/datamodel.rst
Doc/reference/datamodel.rst
+13
-13
No files found.
Doc/reference/datamodel.rst
View file @
d8bbde35
...
...
@@ -1255,22 +1255,22 @@ Basic customization
by default; with them, all objects compare unequal (except with themselves)
and ``x.__hash__()`` returns ``id(x)``.
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.
See also the :option:`-R` command-line option.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment