On 21 Dec 2004 10:37:20 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:

>Op 2004-12-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>>
>>>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
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to