[Python-Dev] Proposal: add odict to collections

[André Malo]

* Guido van Rossum wrote:

> On Sat, Jun 14, 2008 at 4:57 PM, André Malo <nd at perlig.de> wrote:
> > * Armin Ronacher wrote:
> >> Some reasons why ordered dicts are a useful feature:
> >>
> >>   - in XML/HTML processing it's often desired to keep the attributes
> >> of an tag ordered during processing.  So that input ordering is the
> >> same as the output ordering.
> >>
> >>   - Form data transmitted via HTTP is usually ordered by the position
> >>     of the input/textarea/select field in the HTML document.  That
> >>     information is currently lost in most Python web applications /
> >>     frameworks.
> >>
> >>   - Eaiser transition of code from Ruby/PHP which have sorted
> >>     associative arrays / hashmaps.
> >>
> >>   - Having an ordered dict in the standard library would allow other
> >>     libraries support them.  For example a PHP serializer could return
> >>     odicts rather then dicts which drops the ordering information.
> >>     XML libraries such as etree could add support for it when creating
> >>     elements or return attribute dicts.
> >
> > I find this collection of cases pretty weak as an argument for
> > implementing that in the stdlib. A lot of special purpose types would
> > fit into such reasoning, but do you want to have all of them maintained
> > here?
>
> No, but an ordered dict happens to be a *very* common thing to need,
> for a variety of reasons. So I'm +0.5 on adding this to the
> collections module. However someone needs to contribute working code.
> It would also be useful to verify that it actually fulfills the needs
> of some actual use case. Perhaps looking at how Django uses its
> version would be helpful.

FWIW, I'm working a lot in the contexts described above and I never needed 
ordered dicts so far (what do I have to do in order to need them?). I've 
found myself implementing, for example, mutlivaluedicts instead, several 
times.

nd
-- 
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31.  -- Unknown

                                      (found in ssl_engine_mutex.c)