lambda

[Bengt Richter]

On 18 Jan 2005 13:28:00 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:

>Op 2005-01-18, Nick Coghlan schreef <ncoghlan at iinet.net.au>:
>> Antoon Pardon wrote:
>>> More specific the Decimal class is mutable and usable as dict key.
>>
>> It's *meant* to be immutable though. The fact that we used __slots__ instead of 
>> __setattr__ to implement the immutability, so you *can* overwrite the slot 
>> variables if you really want to is merely an artifact of the current Python 
>> implementation.
>>
>> The limited mutability bug will disappear in Python 2.5, so it's not a good 
>> example of a 'mutable' dict key (especially given that the only way to mutate it 
>> is to modify private variables directly).
>>
>> And, as I've stated previously, if the issue of sane mutable keys in 
>> dictionaries and sets really bugs you so much - implement identity_dict and 
>> identity_set in C and lobby for their inclusion in the collections module.
>
>I'm not bugged by its absence in Python. I'm bugged by the attitude
>about them. But anyway I'm thinking about implementing a safe dictionary
>that will copy whenever it would otherwise allow the risk of mutating a
>key.
I encourage you to do it. It should be a rich learning experience.
My bet is you will discover something about the real requirements of
what you are "thinking about implementing" ;-)

IANAP, but ISTM that after a certain point, trying to get made-my-point satisfaction
in a thread like this is more like OCD symptomatology than n.g. dialog ;-)

>
>> On the more general point of "don't use mutable objects with non-identity based 
>> comparisons as dictionary keys", try teaching students for a while (or listen to 
>> those who have):
>
>What kind of students?
>
>I have implemented a hash table when I was a student and its
>implementation allowed the use of 'mutable' objects as a key
>without a problem. It simply always made copies when appropiate
>and didn't allow external access to the keys. So although the
>key objects were 'mutable' there was no way a user could accidently
>mutate a key.
This is word play IMO. What you describe is effectively using the mutables
to construct immutable keys for actual use, not using immutable keys. Having
the immutable (because of access restriction) constructed keys allows
you to check on their consistency with their source any time you want,
but that doesn't change the fact that you have created an alternative dictionary
implementation with immutable keys made immutable by copying and access restriction.
If you update your dictionary when a key no longer matches its source data, you
are just deleting an immutable-by-special-means key and entering the associated
value in association with a new immutable-by-special-means key.

I can produce OCD symptoms too ;-)

>
>So don't use a mutable as a dictionary key isn't so much a dictionary
>limitation in general but a specific limitation of the python implementation.
>
>And yes I understand, the current implenatation is the result of the
>fact that the same dictionaries are used internally for variables in
>scopes and attributes in objects and the fact that no copies are
>involved gives a boost to performance. But it could be argued that
>providing these same dictionaries with those semantics to the users
>was a premature optimisation.

If you see a sign like

   +--------------------------------->
   | WILD GOOSE CHASE THIS WAY    ->
   +----------------------------->
   ||
   ||    \|/
   ||    =o=
   ||    /|\
.`.||,..__|_,.

Do you feel that you must make sure?
The sign painter may only be indicating what his own experience was, after all.
But if it was a core developer's experience, it may be prudent to bet on another trail
-- unless you have an extremely interesting hunch. Then you should follow your passion
and have your own experience, and you may wind up being able to contribute something
(even if only an exclamation point on the sign ;-)

>  
>> When stating useful general principles, it is never, ever worth it to get into 
>> the quibbly little details about exceptions to the principle. If students ask, 
>> admit that they exist, but point out that the exceptions are rare, and not worth 
>> worrying about at that point in their learning.
>
>But don't use mutable keys is not a general principle. It is a principle
>introduced by the limitations of the python implementations.
That is so in your mind, and it is so given certain interpretations of the words
you are using, but to others "mutable keys" may be a contradiction in terms, because
they do not use the words in the same sense as you. If you can't see alternative conceptual
constructs you are stuck, and if we can't agree on the meaning of words for a given dialog,
we won't be communicating very well. The difficulty is getting people to recognize their
implicit assumptions and definitions ;-)

>
>I don't like it when a good rule of thumb because of implementation
>limitations is sold as a general principle.
People take short cuts in expressing themselves, just as you do.
E.g., you say "mutable key" when you really mean a value that will
remain constant while you are using it as a dictionary key. The "safe" dictionary
that you are "thinking about" will apparently get its "safety" by ensuring that
the "mutable key" can't be "mutated" -- or do you want to discuss which copy
is the real "key" ;-) (I don't ;-)

Regards,
Bengt Richter