Why are tuples immutable?

[Jeff Shannon]

Antoon Pardon wrote:

>Op 2004-12-16, Jeff Shannon schreef <jeff at ccvcorp.com>:
>  
>
>
>>nevermind the fact that I can't think of a case where I'm 
>>likely to "retrieve" a key from a dict, modify it, and then put it 
>>back.  (I can think of endless cases where I'd want to do that with 
>>*values*, but not with keys...)
>>    
>>
>
>Well neither can I, but yet the fact that lists are mutable and tuples
>are not, is frequently presented as reason why tuples are allowed as
>keys and tuples are not.
>  
>

True -- in much the same way that the inability to see is why sighted 
people are allowed to get driver's licenses and blind people are not.  
The fact of mutability makes an object very poorly suited for use as a 
dict key, and therefore allowing them to be used as dict keys would be a 
dangerous thing.  I'm sure that, with careful guidance and supervision, 
a blind person could manage to operate a motor vehicle, but no matter 
how high my regard for that blind person was I'd be a bit hesitant to 
give them my car keys for a quick trip to the corner store...

>>(And if dicts were somehow changed so that keys were copied when added 
>>to a dict, just so that every once in a while someone might be able to 
>>avoid a few conversions to/from tuple, then you're adding the overhead 
>>of an object copy to *every* dict insertion, thus slowing down (possibly 
>>by a significant amount) a large proportion of Python operations.  How 
>>is that a gain?)
>>    
>>
>
>Well will look at two scenario's. In each we will work with mutable
>objects that we would like to use a keys. In the first we transform
>them into an immutable object, in the second we just allow mutables to
>be inserted as keys, but insert a copy of the key instead of the key
>itself in order to protect the programmer somewhat from mutating
>dictionary keys.
>
>Now in scenario one we will have a lot more copies then in scenario
>two, because each time we want to use an object as a key we will
>first have to transform it into an immutable. That means every
>addition to the dictionary as well as every key access and each
>such transform means a copy.
>
>In scenario two we will only make a copy when a key is added to
>the dictionary, we don't need to make copies with key accesses.
>
>
>I think scenario two is a performance gain over scenario one.
>  
>

Except that Python uses dicts internally, quite heavily.  Much of the 
speed gains of recent versions of Python have reportedly come 
specifically due to extensive and impressive optimization of 
dictionaries.  Forcing an (extra) object copy every time a variable name 
is bound (or rebound) would be hell on Python's performance across the 
board, not just in those rare cases where someone thinks that they'd 
benefit from using a mutable object as a key.

(And I have to reiterate, here, that I have *never* felt it a hardship 
to be unable to use lists as dictionary keys; it's just never come up 
that the data that I had in a list was something that I wanted to use 
as-is for a dict key, and I can't think of a situation where it *would* 
happen.  What you're saying, essentially, is that for the sake of one 
form of aesthetic purity with no significant practical benefits, we 
should break another form of aesthetic purity with massive practical 
benefits.)

Jeff Shannon
Technician/Programmer
Credit International