What exactly does it mean to say that an object in Python code is hashable?
-
6that searches for hasable objects or something, but none of the links explains what hashable actually means – user1755071 Jan 26 '13 at 11:30
-
3See the documentation on [hashable](http://docs.python.org/3/glossary.html#term-hashable) and the [`__hash__()` method](http://docs.python.org/3/reference/datamodel.html#object.__hash__). – ʇsәɹoɈ Jan 26 '13 at 09:50
10 Answers
From the Python glossary:
An object is hashable if it has a hash value which never changes during its lifetime (it needs a
__hash__()
method), and can be compared to other objects (it needs an__eq__()
or__cmp__()
method). Hashable objects which compare equal must have the same hash value.Hashability makes an object usable as a dictionary key and a set member, because these data structures use the hash value internally.
All of Python’s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are. Objects which are instances of user-defined classes are hashable by default; they all compare unequal, and their hash value is their
id()
.

- 486,780
- 108
- 951
- 1,012
-
10if it has `hash value` now what is hash value. can you give some example – user1755071 Jan 26 '13 at 09:56
-
6@user55711: Here, the hash value is the result of calling `__hash__()`. More generally, see http://en.wikipedia.org/wiki/Hash_function – NPE Jan 26 '13 at 09:57
-
18@TorstenBronger: Because two unequal objects can hash to the same value. In other words, hashing is lossy. – NPE Oct 19 '15 at 23:13
-
2In python-2.7.12, the result of `id(object)` is 16x the result of `object.__hash__()`. So the glossary excerpt is incorrect for this version - the hash value is not `id()`, but it is derived from it (as indeed noted in the updated docs for python 2.7.12). – davidA Nov 14 '16 at 00:29
-
I wonder how often people fail to implement the *never changes during its lifetime* requirement. It's rather onerous since `__eq__` doesn't have the same constraint. – dimo414 Mar 14 '18 at 04:50
-
6I know this is an old post, but it's worth mentioning that the glossary entry copied here isn't entirely correct. You can put a mutable object (like a list) inside a tuple. The tuple is still immutable, but you can change the list inside it, so it's not hashable. Try `hash((1, [2, 3]))` to see it in action. I've posted a request to correct the glossary entry for hashable. – John Riehl May 26 '19 at 19:55
-
Lists are not hashable. However, `"__hash__" in dir([])` evaluates to True. So how does that fit into the picture of the glossary entry, especially the first sentence which is basically stating that it is sufficient for an object to have a `__hash__()` method to be hashable? – H.G.M. Jun 26 '19 at 15:39
-
1@H.G.M. I just did a test with Python 3.6.3, and while a list does have a `__hash__` member, it's `None` not a function. It definitely does *not* evaluate to `True`. – Mark Ransom Dec 05 '19 at 16:08
-
2As @JohnRiehl pointed the recent glossary doc does mention this: "immutable containers (such as tuples and frozensets) are only hashable if their elements are hashable." as per this [py 3.9 glossary](https://docs.python.org/3.9/glossary.html) . – Shubham Srivastava May 18 '20 at 16:05
-
12 objects that are equal NECESSARILY has the same hash value, but the opposite is NOT true. 2 differing objects can collide to the same hash value. This means even if 2 items has the same hash value, you still have to compare the data to make sure they are in fact the same. – Peppershaker May 27 '21 at 04:33
All the answers here have good working explanation of hashable objects in python, but I believe one needs to understand the term Hashing first.
Hashing is a concept in computer science which is used to create high performance, pseudo random access data structures where large amount of data is to be stored and accessed quickly.
For example, if you have 10,000 phone numbers, and you want to store them in an array (which is a sequential data structure that stores data in contiguous memory locations, and provides random access), but you might not have the required amount of contiguous memory locations.
So, you can instead use an array of size 100, and use a hash function to map a set of values to same indices, and these values can be stored in a linked list. This provides a performance similar to an array.
Now, a hash function can be as simple as dividing the number with the size of the array and taking the remainder as the index.
For more detail refer to https://en.wikipedia.org/wiki/Hash_function
Here is another good reference: http://interactivepython.org/runestone/static/pythonds/SortSearch/Hashing.html

- 1,081
- 15
- 30

- 2,215
- 1
- 13
- 11
-
2That's an interesting perspective on hashing. I haven't thought of it in that way. – yuvgin Jan 01 '19 at 00:00
-
@yuvgin hash-tables are often used to implement sparse-arrays (i.e. the example given here). – Eli Korvigo Mar 01 '19 at 19:21
-
1@EliKorvigo I like to think of regular arrays as simply highly optimized versions of a hash table. – Mark Ransom Dec 05 '19 at 16:11
-
3can you produce some simple code regarding the phone number array scenario to clarify the concept of hashing ? – Istiaque Ahmed Jan 18 '20 at 12:51
-
Edit queue is full, but here is new link to last reference https://runestone.academy/ns/books/published/pythonds/SortSearch/Hashing.html – hotenov Mar 14 '22 at 12:23
Anything that is not mutable (mutable means, likely to change) can be hashed. Besides the hash function to look for, if a class has it, by eg. dir(tuple)
and looking for the __hash__
method, here are some examples
#x = hash(set([1,2])) #set unhashable
x = hash(frozenset([1,2])) #hashable
#x = hash(([1,2], [2,3])) #tuple of mutable objects, unhashable
x = hash((1,2,3)) #tuple of immutable objects, hashable
#x = hash()
#x = hash({1,2}) #list of mutable objects, unhashable
#x = hash([1,2,3]) #list of immutable objects, unhashable
List of immutable types:
int, float, decimal, complex, bool, string, tuple, range, frozenset, bytes
List of mutable types:
list, dict, set, bytearray, user-defined classes

- 18,328
- 4
- 58
- 63

- 23,311
- 18
- 141
- 164
-
1I recently found out that the `Ellipsis` is also an immutable type and can be used as a key for a `dict`. – Gábor Fekete Jan 09 '18 at 15:09
-
Even user-defined classes can be used but only their names not instances. E.g.: `hash(MyClass)` – Gábor Fekete Jan 09 '18 at 15:18
-
5@GáborFekete instances of user-defined classes are hashable if their classes implement `__hash__` and `__eq__`. Moreover, all user-defined classes implement these methods (and are thus hashable), because they inherit the methods from `object` (the universal base-class). – Eli Korvigo Mar 01 '19 at 19:19
In my understanding according to Python glossary, when you create an instance of objects that are hashable, an unchangeable value is also calculated according to the members or values of the instance. For example, that value could then be used as a key in a dictionary as below:
>>> tuple_a = (1, 2, 3)
>>> tuple_a.__hash__()
2528502973977326415
>>> tuple_b = (2, 3, 4)
>>> tuple_b.__hash__()
3789705017596477050
>>> tuple_c = (1, 2, 3)
>>> tuple_c.__hash__()
2528502973977326415
>>> id(tuple_a) == id(tuple_c) # tuple_a and tuple_c same object?
False
>>> tuple_a.__hash__() == tuple_c.__hash__() # hash of tuple_a and tuple_c same value?
True
>>> dict_a = {}
>>> dict_a[tuple_a] = 'hiahia'
>>> dict_a[tuple_c]
'hiahia'
We can find that the hash value of tuple_a
and tuple_c
are the same since they have the same members.
When we use tuple_a
as the key in dict_a
, we can find that the value for dict_a[tuple_c]
is the same, which means that, when they are used as the key in a dictionary, they return the same value because the hash values are the same.
For those objects that are not hashable, the method __hash__
is defined as None
:
>>> type(dict.__hash__)
<class 'NoneType'>
I guess this hash value is calculated upon the initialization of the instance, not in a dynamic way, that's why only immutable objects are hashable. Hope this helps.
-
2"We can find that the hash value of tuple_a and tuple_c are the same since they have the same members." - This is a bit misleading. Having the same members is not enough, the order of the members also matters. – BcK Jan 27 '22 at 22:43
-
Can anyone explain why identity check is ``False`` in REPL and ``True`` when we run this script? (same story for ``is`` operator). Python interpreter optimizes memory usage and does not duplicate objects with the same hash value? Right? – hotenov Mar 25 '22 at 07:34
-
It seems I found answer on my question above [here](https://stackoverflow.com/questions/306313/is-operator-behaves-unexpectedly-with-integers) and [here](https://stackoverflow.com/a/15541556/3366563) *(spoiler: CPython interpreter implementation)* – hotenov Mar 31 '22 at 09:14
Hashable = capable of being hashed.
Ok, what is hashing? A hashing function is a function which takes an object, say a string such as “Python,” and returns a fixed-size code. For simplicity, assume the return value is an integer.
When I run hash(‘Python’) in Python 3, I get 5952713340227947791 as the result. Different versions of Python are free to change the underlying hash function, so you will likely get a different value. The important thing is that no matter now many times I run hash(‘Python’), I’ll always get the same result with the same version of Python.
But hash(‘Java’) returns 1753925553814008565. So if the object I am hashing changes, so does the result. On the other hand, if the object I am hashing does not change, then the result stays the same.
Why does this matter?
Well, Python dictionaries, for example, require the keys to be immutable. That is, keys must be objects which do not change. Strings are immutable in Python, as are the other basic types (int, float, bool). Tuples and frozensets are also immutable. Lists, on the other hand, are not immutable (i.e., they are mutable) because you can change them. Similarly, dicts are mutable.
So when we say something is hashable, we mean it is immutable. If I try to pass a mutable type to the hash() function, it will fail:
>>> hash('Python')
1687380313081734297
>>> hash('Java')
1753925553814008565
>>>
>>> hash([1, 2])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> hash({1, 2})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'
>>> hash({1 : 2})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'
>>>
>>> hash(frozenset({1, 2}))
-1834016341293975159
>>> hash((1, 2))
3713081631934410656

- 1,218
- 17
- 16
-
6Note that python randomly seeds the hashing algorithm at the start of each process. Therefore, you will actually get different hash values if you run hash('Python') twice in different processes. – D Hudson Jun 04 '20 at 14:29
In Python, any immutable object (such as an integer, boolean, string, tuple) is hashable, meaning its value does not change during its lifetime. This allows Python to create a unique hash value to identify it, which can be used by dictionaries to track unique keys and sets to track unique values.
This is why Python requires us to use immutable datatypes for the keys in a dictionary.

- 141
- 1
- 4
In python it means that the object can be members of sets in order to return a index. That is, they have unique identity/ id.
for example, in python 3.3:
the data structure Lists are not hashable but the data structure Tuples are hashable.
-
1The hash is not the same as the `id`, which is (approximately) the address of the object in memory. – poolie Dec 20 '16 at 15:48
Let me give you a working example to understand the hashable objects in python. I am taking 2 Tuples for this example.Each value in a tuple has a unique Hash Value which never changes during its lifetime. So based on this has value, the comparison between two tuples is done. We can get the hash value of a tuple element using the Id().

- 485
- 3
- 10
- 23
-
31
-
10it's a wrong answer. id() shows the referenced address in a memory, it's not a hash value. In order to get hash use __hash__() function. e.g: t1.__hash__() – Volodymyr Nov 02 '16 at 17:10
-
@ascentman Don't hesitate to edit an answer that you believe is wrong. Your edit will be peer-reviewed and, if accepted, you get a small score reward for it. – XavierStuvw Jun 12 '17 at 13:46
As an addition to the other answers: The Python glossary says that "Objects which are instances of user-defined classes are hashable by default.". But it also says "Hashable objects which compare equal must have the same hash value.".
By this, if you implement the __eq__
-Method without Implementing the __hash__
-Method your object will not be hashable. Otherwise deriving the hash from id()
would not guarantee that for two object which compare equal the same hash is generated (id(a) != id(b)
but a == b
)
>>> class Foo(object):
... def __eq__(self, other): pass
...
>>>
>>> class Bar(object):
... pass
...
>>> f = Foo()
>>> b = Bar()
>>>
>>> hash(f)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'Foo'
>>> hash(b)
8758325844794

- 81
- 1
- 2
For creating a hashing table from scratch, all the values has to set to "None" and modified once a requirement arises. Hashable objects refers to the modifiable datatypes(Dictionary,lists etc). Sets on the other hand cannot be reinitialized once assigned, so sets are non hashable. Whereas, The variant of set() -- frozenset() -- is hashable.

- 9
- 1