[Python-Dev] Proposal: add odict to collections
Steven D'Aprano
steve at pearwood.info
Sun Jun 15 11:03:15 CEST 2008
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
More information about the Python-Dev
mailing list