Why are tuples immutable?
jeff at ccvcorp.com
Tue Dec 21 19:26:59 CET 2004
Antoon Pardon wrote:
>Op 2004-12-21, Nick Coghlan schreef <ncoghlan at iinet.net.au>:
>>Antoon Pardon wrote:
>>>Why then doesn't python think the same about sorted lists. When I have a
>>>sorted list and do operations on it that depend on it being sorted,
>>>I can mess things up just as easily by mutating an element in that
>>>sorted list as I can mess things up by mutating a dictionary key.
>>Incorrect, and this appears to be the point where our major disagreement lies.
>>Mutate a value in a sorted list and you can fix that easily, just by calling its
>>sort() method again (and, in fact, mutate and resort is a fairly common idiom
>>for small datasets). 'sorted' and 'heapified' are list properties that are
>>easily broken by direct manipulation, but are also easily restored by once again
>>'sorting' or 'heapifying'.
>That is an implemantation detail. Likewise a dictionary is probably not
>always in a sane state when a new key is inserted. The fact remains that
>in a sorted list or a heap, mutating an element arbitrarily can mess up
These comparisons to sorted lists and heaps are a red herring. The
analogous situation to those is dictionary *values*, not dictionary keys
-- in essence, the "keys" of a list (whether sorted or not) are integers.
>>Change the hash value of an item used as a key in a dictionary, and *the
>>internal state of the dictionary is likely to broken in a manner you probably
>>cannot fix*. The only reason the 'probably' is there is because you should be
>>able to 'fix it' by changing the hash value back to what it was originally.
>I could argue that this is then a failing of dictionary that doesn't
>provide a method to clean up after a key is mutated.
So show us a dictionary (i.e. hash table) implementation that can do
this. You'll need to be able to derive the old hash from the new hash,
of course, so that you can correctly associate the values already stored
under that key. And you'll have to be able to do that without referring
to the pre-modified object again, because dicts can't track every Python
operation that might modify a key object. And it needs to deal properly
with equivalent-but-different-ID list literals, because using literals
(and not references stored elsewhere) is an important and common dict
If you can show me how you plan to accomplish this, I'll accept that
you're right on this. Until then...
>>Waitasec - wouldn't it be easier if dictionaries just made it a rule that the
>>hash value wasn't allowed to change? Hang on, that's exactly what they do.
>No it is not.
Seems to me that the docs are pretty clear on that. It's true that
dictionaries can't enforce that the hash value never change over the
entire life of an object, because dicts can only take enforcement
actions when the dict itself is referenced -- but that's *why* it's
>And yes I know what to do if I want to use mutable keys as objects. I'm
>just argueing against those who think that should be somehow forbidden.
We're not arguing that it should be arbitrarily forbidden. We're
arguing that doing anything else makes it impossible to behave
sensibly. So prove us wrong, by implementing something that behaves
sensibly in the face of mutating keys (which compare by value, as lists
do, rather than by identity).
More information about the Python-list