Why are tuples immutable?

[Bengt Richter]

On 21 Dec 2004 10:37:20 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:

>Op 2004-12-18, Bengt Richter schreef <bokr at oz.net>:
>>>
>>>As it turns out, python makes no difference in difficulty for making
>>>either mutable or immutable objects usable as dictionary keys. The
>>>only difference is that python only made its standard immutable
>>>types hashable and not its standard mutable objects.
>>>
>> In one sense a mutable could looked upon as immutable until it is mutated,
>> so why not allow its use in the same way as immutables?
>> Is that basically the point of view you are trying to explain?
>>
>> Ok, suppose you did allow that. What kind of error symptoms would you like
>> to have after a dict key is mutated and an attempt is made to look up the value
>> using a mutable equal to the original key value? Presumably a KeyError exception?
>> Or did you want to use a "frozen" copy of the original key, and not get a KeyError?
>> Or should a new value equal to the mutated current value of the original key succeed?
>
>Why should we expect certain error symptoms? If you have sorted mutable
>objects, mutated one element in the list and then apply an algorithm
>that depended on the list to be sorted; would you then expect a
>particular error symptom?
It depends on the use of the sorted list, but the subject I was discussing was your requirements
for a mutable-key dict. I was asking how you would like the mutable-key dict to behave
IF a key was mutated and an attempt was made to retrieve the origninally stored value
using a mutable key equal to the mutated value of the original key. E.g., if mkd is the mutable key dict,
 key = [0]
 mkd[key]=123
 key[0] = 1
 mkd[[1]] => ?

I said I would go with the assumption that you would like it to succeed (return the 123 above).
You said I assumed wrongly, but for some reason chose not to answer my questions or say what
a "correct" assumption would be. Ok. If you're not interested in pursuing the "correct" version
of the dict behavior _you_ were asking for, what are you interested in? ;-)

In the above, I am in a position to detect some "errors," depending what _your_ specs are.
I think it would be sloppy to let detectable errors pass silently, and in the case of mkd[[1]] above
clearly it will succeed or not, depending on design. The logical thing would seem to be to
return the matching value or design the dict so that mkd[[0]] would still retrieve 123 and
mkd[[1]] would raise a KeyError. Either way, this is a particular error symptom to expect, because
it is a direct consequence of a design decision. Your sorted list example does not say enough about
the designed usage to say what specific errors might be expected, so it's not directly comparable.

If you are saying you are happy with "undefined behavior" as the outcome of mutating keys, ok,
but if your implementation lets mutated-key errors pass silently, good luck debugging ;-)

>
>> Assuming the latter, what does this imply implementation-wise?
>
>You assume wrongly. I'm a bit sorry for that, because you obviously
>spend time in this.
That's ok, I made the choice ;-) I enjoy exploring ideas, and I thought it might
be useful to help you explore the consequences of what you seemed to be asking for,
and I was a bit curious how it would work out in practice when mutable keys were mutated.

I obviously could have made it work differently, and was trying to guess what alternative
you might be interested in. ISTM from the little experiment I posted in this thread that
mutable keys for dicts is fraught with pitfalls even if you intend never to mutate keys
in use, because of the potential for silent bugs if you accidentally do. But perhaps something
useful can be designed, if design decisions are carefully made.

If you enjoy exploring ideas too, you might get even more enjoyment by participating
more directly. E.g., at this point you might have volunteered to mention what would have
been a "correct" assumption to make in place of the one you say I made wrongly.

Your reticence does make me wonder what you consider to be rewarding about participating
in this kind of thread ;-) Cruel rejection is not the style of c.l.py, but if you have
had such experience, somewhere, bringing that baggage with you into the present in search
of resolution is likely to limit your new experiences to something less than an optimally
pleasant dialog ;-) The kids here mostly play nice ;-)

>
>> Hm, just for the heck of it, does this do what you want? (all features not tested, none tested beyond what you see,
>> and special methods like update and iterators will just work on the plain dict part if they work at all, unless
>> you add the code ;-)
>
>I don't expect anyting special. Python provides all that is needed. It
>is just that the documentation suggests otherwise.
>
So is there anything you would like to do to help make things better
for yourself and everyone? ;-)

Regards,
Bengt Richter