[Python-Dev] Proposal: add odict to collections

[Steven D'Aprano]

On Sun, 15 Jun 2008 06:42:32 pm laurent wrote:
> 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.

I think the quickest way to kill this proposal again will be to start 
overloading it with more and more complicated behaviour. Python dicts 
are one-to-one (ignoring edge cases like dict[1] vs dict[1.0]). If you 
want one-to-many, you can subclass dict and get that behaviour.

I think that an ordered dict in the standard library should follow the 
same philosophy: define the simplest, most fundamental behaviour which 
is an ordered dictionary, and then let people sub-class it to make more 
complicated types. So I vote -1 on one-to-many associations, and +1 to 
one-to-one like regular dicts.

As for a API to access items by position rather than by key, I'm neutral 
on it. You can always get the nth key by extracting the keys into a 
list. Provided it doesn't become a point of contention, then I'm +0 on 
giving the ordered dict index-based methods in addition to the 
key-based methods, but if it becomes a sticking point and puts the 
whole concept in jeopardy, then I vote -1 on the index-based API. This 
applies also to slicing.


-- 
Steven