-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
Confusion with "immutable" and "hashable" in Design and History FAQ #134114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Immutability is more strong requirement, it does. |
Is there an immutable element that can not be used as a dictionary key? Or a mutable element that can be used as a dictionary key? |
According to https://docs.python.org/3/glossary.html#term-hashable
It means that there are some kind of immutable built-in objects that aren't hashable. Additionally, you can make a class that doesn't implement |
I would say, it's just an implementation detail. I.e. yes, you could break default hashability (per default, derived from the object class types are hashable) - by setting
Sure, you can create an artificial type: class BadObj:
__hash__ = None |
Yes.
This class is unhashable (have no hash) so it cannot be the key of dict.
This class is changedable, but if a class has no "eq", the hash is default to use the hash of id, so it is hashable. |
Uh oh!
There was an error while loading. Please reload this page.
The page https://docs.python.org/3/faq/design.html#why-are-there-separate-tuple-and-list-data-types says at the end of its last paragraph:
Which is not quite correct, since dictionaries only require its keys to be hashable (see https://docs.python.org/3/library/stdtypes.html#mapping-types-dict). Immutability doesn't necessarily imply hashability.
Thanks.
Linked PRs
The text was updated successfully, but these errors were encountered: