If you have a list or dictionary you want to use a key, you can convert it into a tuple which would make it immutable.
If you don't care about performance for larger collections you could just use a list instead of a dictionary, which does not require hashing. Changes to the original mutable object will also be reflected in your list.
> What would you expect to happen if the object is modified after being inserted into the dictionary?
You can try it right in your browser with Javascript and the Map() object type. You can mutate the object all you want, as long as it's the same object(-reference) you access the same value in the Map object. Just as I would expect. "Mutable" doesn't change which object you have, only what it looks like inside.
It's also worth pointing out that user-defined objects operate the way you seem to desire (e.g. default to using the id() property of the object to derive the hash). So in my mind, this strikes the perfect balance?
StdLib types that are immutable bake in more comparative hash properties while making it trivial for a user to wrap them and override this richer behavior with default hash based on id().
Consider:
```
>>> class myList(object):
... def __init__(self):
... self.inner_list = list()
...
>>> x = myList()
>>> x
<myList object at 0x10bdabf10>
>>> x.inner_list
[]
>>> y = {x: 'hi'}
>>> y
{<myList object at 0x10bdabf10>: 'hi'}
>>> x.inner_list.append(1)
>>> x.inner_list
[1]
>>> y
{<myList object at 0x10bdabf10>: 'hi'}
>>> for k in y.keys():
... print k.inner_list
...
[1]
```
> This fundamentally reduces the usefulness of hash representations though.
> Instead of thinking of dict keys, think sets.
By the way, I'm not talking about any particular implementation.
> If you want something immutable just put something immutable in.
My point is what do you expect if you do this:
>>> x = (1, 2)
>>> y = (1, 2)
>>> set([x, y])
I would argue that you would expect:
>>> set([(1,2)])
Since x is equal to y. But if you base the hash by default on id, you would get:
>>> set([(1, 2), (1, 2)]) # set([x, y])
Since x and y are different instances (have different id()) properties. I would argue that it's more useful/predictable for built-ins to hash based on content rather than id().
However, you can still hash based on id() but simply creating your own object (as I demonstrated). So you get sensible defaults for built-ins but also the option of hashing mutable objects.
Anyway, it's configurable for example in Java (http://stackoverflow.com/questions/9440380/using-an-instance...) - default is to use the reference but you can override object methods to change that. Similarly for C#(http://stackoverflow.com/questions/634826/using-an-object-as... or http://stackoverflow.com/questions/8952003/how-does-hashset-...).
For me, talking about how dicts handle hashing keys and sets hashing members are equivalent in the context of the Python language.
Given that context I was saying changing the "hashable" nature of default objects would be counter-intuitive as the new behavior would be in contrast to the expected behavior of sets and/or immutable equal types in dict keys.
This question is sometimes not important: When the mutable object is not mutated.
Which you can't guarantee when the object is mutable, so for consistency's sake it's left out.
Though you can always build your own Dict subclass and implement __hash__ on it and be angry with yourself when it fails. :)
https://docs.python.org/3/glossary.html#term-hashable
http://stackoverflow.com/questions/4348232/python-dictionary...
For set, it's a bit more annoying. But for dicts. twice in 10 years maybe ?
I mean, its not a huge deal, but it adds up.
You can use pretty much anything as a dictionary key
For example (tested on both python 2.7 and 3.4):
>>> {{'a': 1}: 2}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'
>>> {[1,2,3]: 4}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'
>>> {{1,2,3}: 4}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'
>>> class A(object):
... def __init__(self):
... self.x = 1
...
>>> a = A()
>>> b = A()
>>> d = {a: 1, b: 2}
>>> a.x = 10
>>> b.x = 10
>>> d[a]
1
>>> d[b]
2
You can, of course, implement your own __hash__ to make it work, but you have to do it manually for any object you want it and most third-party objects won't have implemented it so you'd have to monkey patch them.
Contrast that with Clojure, where all built-in data structures (maps, sets, lists, dicts etc) work as keys out of the box.
[1] I guess its true in the sense that you can implement __hash__ to make it work. But its not particularly easy or idiomatic.
I'm a Python programmer too, and I also fully expect dict keys to be able to be arbitary objects, and I get really frustrated with the fact that they can't be arbitary objects. They have to be hashable objects, and the hash function refuses to hash certain objects that it has decided aren't allowed.