This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Clarify hashability of custom class instances
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: cito, docs@python, rhettinger
Priority: normal Keywords:

Created on 2019-05-31 09:07 by cito, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg344042 - (view) Author: Christoph Zwerschke (cito) * Date: 2019-05-31 09:07
The Python documentation says about hashability in the glossary (https://docs.python.org/3/glossary.html#term-hashable):

"Objects which are instances of user-defined classes are hashable by default."

This is not quite true. Objects of a user-defined class with an __eq__ method are not hashable. Maybe it would be better to make this more explicit:

"Objects which are instances of user_defined classes without custom __eq__ and __hash__ methods are hashable by default."
msg344138 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-05-31 23:00
The docs look correct to me:

    >>> class A:
            pass

    >>> hash(A())
    274859987

User defined classes are in-fact hashable by default.  Other methods can be defined to change hashability, but they are not the default.

FWIW, it isn't the purpose of the glossary to be a language spec; rather, it is to provide a rough meaning of what the word "hashable" means.  Already, the wording has exceeded its original intent.  The correct place for a more detailed specification in the language reference for object.__hash__():

   https://docs.python.org/3/reference/datamodel.html?highlight=__hash__#object.__hash__

Thank you for the suggestion, but we'll pass on this one.
msg344139 - (view) Author: Christoph Zwerschke (cito) * Date: 2019-05-31 23:25
My point was that it's not immediately obvious what "by default" means and that hashability is not only affected by the __hash__ method but also by __eq__.

But I agree, you can argue that "by default" already includes not adding any special methods like __eq__ and the glossary should not become too verbose. (I remember these words from Donald Knuth in one of his books: "In the interest of conciseness, you need to indulge in simplifications that are really little lies; these should be overlooked.")
History
Date User Action Args
2022-04-11 14:59:16adminsetgithub: 81291
2019-05-31 23:25:28citosetmessages: + msg344139
2019-05-31 23:00:39rhettingersetstatus: open -> closed

assignee: docs@python -> rhettinger

nosy: + rhettinger
messages: + msg344138
resolution: rejected
stage: resolved
2019-05-31 09:07:25citocreate