* Guido van Rossum wrote:
On Sat, Jun 14, 2008 at 4:57 PM, André Malo <nd@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)