Op 2005-01-18, Bengt Richter schreef <[EMAIL PROTECTED]>: > On 18 Jan 2005 13:28:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
