Why are tuples immutable?

Antoon Pardon apardon at forel.vub.ac.be
Thu Dec 16 04:21:58 EST 2004


Op 2004-12-16, Jeremy Bowers schreef <jerf at jerf.org>:
> On Wed, 15 Dec 2004 15:08:09 +0000, Antoon Pardon wrote:
>
>> And I think that is a stupid reason. There are enough other situations
>> were people work with mutable objects but don't wish to mutate specific
>> objects.  Like objects in a sorted sequence you want to keep that way
>> or objects in a heapqueue etc.
>> 
>> Demanding that users of dictioanaries somehow turn their mutable objects
>> into tuples when used as a key and back again when you retrieve the keys
>> and need the object can IMO ibe a bigger support nightmare than the
>> possibility that code mutates a key in a dictionary.
>
> Steve plonks you as a troll but I fear this is a point that either I am in
> grave error on, or in our zeal to make this point simple for everyone
> we've elided an important point and I'm not convinced it is as obvious as
> he thinks it is. So, before trusting this message, wait for the angered
> replies from those who know.

Well IMO there are two sides in this argument. The first is whether
or not python allows mutable keys. The second is whether or not
limiting keys to immutables in dictionaries provides a performance
gain.

The two get mixed up a lot in this list, because a reasaonable amount
argue that python only allows for immutable keys because of this
supposed performance gain and that is why tuples are immutable because
otherwise there wouldn't be a sequence type suitable as dictionary key.

Then when I give arguments against the performance gain, people
come with the argument that it is to protect keys in dictionaries
from changing. 

> A dict key doesn't *really* need to be immutable. What it needs is the
> following: the hash does not change over time, and an "equal" key will
> always compare equally with no changes over time. Sample run:

IMO there is nothing wrong with the hash or the equal comparisson
being changable over time as long as the programmer is carefull not to
change them while they are a key in a dictionary.

Two guidelines can make it easier for a programmer to do this.

1) Put a copy in the dictionary, so that mutating the original
   object won't affect what is in the dictonary.

2) Don't mutate keys that come from a dictionary iterator.

> [ Example ]
>
> I've seen this go by over and over and ISTM nobody ever clearly says this,
> so either I'm in error on some point, or people are afraid to try to
> explain the properties that must hold for mutable objects to be used in
> hashes. Because the slightest violation can kill you...

Yes, I find the python community a bit overprotective about some issues.
I wouldn't be surprised the eas of doing something wrong here makes
some people shy away from this. On the other hand if you have a sorted list
or a heapqueue and you unknowingly mutate one of the elements in it you
can be screwed too. Yet I don't see people suggest that only lists with
immutable elements should be able to be sorted or that heapqueues should
be limited to immutable elements.

-- 
Antoon Pardon



More information about the Python-list mailing list