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