[Python-Dev] Proposal: add odict to collections

laurent lgautier at gmail.com
Sun Jun 15 10:42:32 CEST 2008


On Sun, 2008-06-15 at 00:12 -0700, Raymond Hettinger wrote:
> From: "Cesare Di Mauro" <cesare at pronto.it>
> > 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.

An other behavior making sense would be to append a new position for the
key. With your example above:

d.index(k1) = [0, 2]
d.index(k2) = [1, ]

Deletion of a key would have to be explicit (and
delete all associated indexes).

An other way to think of such a structure would be as a list, for which
each item would also have an associated key. 
I think someone mentioned the link with a list during this thread, but
here I am not referring to implementation, but the feature of a
container-like class that would allow to access elements either by
position (index), and that would be a one-to-one association, or key,
and that would be a one-to-possibly-many association.



> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com



More information about the Python-Dev mailing list