From: "Cesare Di Mauro" <[EMAIL PROTECTED]>
The same problem happens with dictionary updates:d = {} d[k1] = v1 d[k2] = v2 d[k1] = v3 The last instruction just replaces the existing entry, so I'm +0 for the first result.
There's a difference. With dicts, the third insertion *replaces* the value while leaving data structure unmolested. Also, the key doesn't update (an equal but identical key doesn't get substituted).
With an odict that preserves insertion order, you're talking about *deleting* the old entry and *appending* the new one, complete with both the new key and new value. If that is the desired behavior, then it becomes impossible to update the value of an odict entry while leaving its insertion order unchanged. What a bummer.
An alternative behavior is to replace the value, leaving the key in its original position. But then, you've messed-up the expectation that v2 occurs before v3 eventhough v3 was inserted later. This is especially weird because you keep k1 which was inserted earlier, not k3 which is equivalent but not necessarily identical.
Neither behavior is de facto, TheRightWay(tm). Each has its uses. Each has its oddities. Each will have its fans who find that particular way to be the best and most intuitive.
One other issue arises if you choose the approach where updating a value triggers re-ordering -- the the dict view concept no longer translates very well. With regular dicts, you can update values while iterating. Losing that would be a bummer too.
I don't favor one over the other. Am just pointing-out that the proposal is a little more complex than simply wishing for an ordered verion of a dictionary and expecting that that wish is self-defining in a way the matches everyone's intuition, use cases, and expectations.
Raymond
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
