lambda

[Antoon Pardon]

Op 2005-01-18, Bengt Richter schreef <bokr at oz.net>:
> On 18 Jan 2005 13:28:00 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>
>>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.

No it is not wordplay. There is a difference between inaccessible and
immutable. The difference is that the user can mutate his own objects
which he wants to use as a key, which wouldn't be the case if he was
using immutables as 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.

The immutable vs mutable as keys IMO refers to the class the key belongs
to. Not the accessibiliy of individual instances.

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

Talk to my wife. She regularly complains that I don't accept
her word often enough on what she says. :-)

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

As far as I understand I using them in a standard python interpretation.

> but to others "mutable keys" may be a contradiction in terms, because
> they do not use the words in the same sense as you.

I don't think so. I have seen defenders of only immutables as keys, use
the argument that using mutables as keys would require a copy of the key.
Therefore using only immutables allows for optimisations in the implementation.
I saw nothing in there discourse that implied they saw this copy as
immutable.

> 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 can be wrong, but until now I have seen no indication that I was
using mutable and immutable differently than other people. AFAICT
we all refer to whether an object belongs to a mutable or immutable
class.

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

What I mean is a key that belongs to a mutable class. Whether I
actually mutate it in certain circumstances or not doesn't change
that.

I also don't want my values to change when I have sorted a list
and still need to apply a number of algorithms that rely on
that. Nobody seems to have problems with the possibility that
the list items are mutable (and called such).

-- 
Antoon Pardon