Why are tuples immutable?

[Antoon Pardon]

Op 2004-12-17, Jeff Shannon schreef <jeff at ccvcorp.com>:
> 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.

In the same way as mutability makes an object poorly suited to be
a member of a sorted list.

Mutability doesn't make an object unsuitable to be used in a structure
that depends on some invariant, as dictionaries are one example. We
only need to ensure that the object is stable while it is used in
such a way.

Is it such a rare occasion that objects are mutated during some time
in a program after which they remain stable? And while we have collected
a number of such stable objects couldn't it be usefull to be able to
sort them, use them as a dict key or in some other structure that
requires an invariant?

Would you have us construct two related classes each time we find
ourselves in such a situation and copy an object from one
class to the other depending on the circumstances?

> 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.

No it wouldn't.

1) A copy wouldn't be needed on a rebind of a variable name because
the name would then already be in the directory.

2) Some techniques could be used so that even a lot of binds will
not require a copie.

3) Nothing stops python from checking if one of its standard immutables
is used as a key and then proceed as it does now.


Now I'm not asking that the people oblige me and implement this.
I'm more then happy to take my own resposibility as a programmer
and provide a copy myself to the dictionary when I have use of
a mutable object as 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.)

You shouldn't limit the usefullness of a language to your ability
to imagine what is usefull and what not.

Besides python doesn't provide such an aesthetic purity. Even if
it was true that only immutables could be used as keys in dictionaries
there are other times some invariant is established or depended upon
and yet python doesn't enforce immutable objects in those cases.
So much of the aesthetic purity python provides.

-- 
Antoon Pardon