Why are tuples immutable?

[Antoon Pardon]

Op 2004-12-17, Jeff Shannon schreef <jeff at ccvcorp.com>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <jeff at ccvcorp.com>:
>>  
>>
>>
>>>(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.)
>>>    
>>>
>>[...]
>>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.
>>  
>>
>
> The aesthetic purity I'm referring to is that Python respects the proper 
> meaning of hashing, even if it doesn't force the programmer to.

And why should that be given much weight, considering that python
doesn't enforce aesthetic purity in other places.

> The 
> builtin objects that Python provides don't offer a __hash__() method 
> that fails to meet the mathematical prerequisites of a proper hash 
> function -- that is, objects that are equal will hash identically.

So? Equal doesn't has to be limited by what you understand as equal.
Besides if you want aesthetic purity and go looking within mathematics,
you will find that there is a lot lacking. Because methematically,
equallity means sameness.

> In 
> addition, dictionaries expect keys to have proper hashing semantics, 
> such that a given object's hash value will not change over its 
> lifetime.

Repeating this, won't make it true. I already responded that dictioanries
expect no such thing. They only expect the hash (and equallity) to be
stable for the objects while they are used as keys.

> It is not possible for a mutable object to satisfy both 
> aspects of proper hashing behavior,

Yes it can. Nobody forces a mutable object to mutate. So a programmer
who is carefull not to mutate the objects that are used as a key in
a dictionary has mutable objects that satisfy both aspects of proper
hashing behaviour. And asking the programmer to be carefull in this
way is no more difficult as being carefull not to mutate an object
in a heapqueue or a sorted list.

> therefore Python does not pretend 
> that mutable objects are hashable.

There is no pretention there. Mutatble objects are just as hashable
as they are sortable. 

> Python does provide features that 
> allow you to define your own __hash__() on your own classes, and it has 
> no way of forcing you to make that a *proper* hash function, which 
> allows you to subvert things and create pseudo-hashable mutable objects, 
> but Python declines to do that itself -- it'll give you the rope to hang 
> yourself with, but it's not tying the noose.

Why is is subvertion? Do you think its is subvertion too when mutable
object are sorted or used in a heapqueue?

-- 
Antoon Pardon