[Python-Dev] Proposal: add odict to collections

[dbpokorny at gmail.com]

On Jun 14, 4:39 pm, Armin Ronacher <armin.ronac... at active-4.com>
wrote:
>   - 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.

Munging XML is a niche.

>
>   - 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.

If you don't like the fact that your web application framework loses
the order of its key:value pairs relative to the page, then you should
bring it up with the developers.

Ordered dicts, dicts that remember the chronological order of their
insertion, don't sound generally useful. In contrast, sorted dicts
sound appealing, but I can't think of any use cases where
sorted(mydict.keys()) fails to be effective; it seems to me the main
advantage of a sorted dict is that you don't have to remember to sort
the keys every time you want to use them.

> Additionally it would support slicing where a list of key, value tuples
> is returned and sort/reverse/index methods that work like their list
> equivalents.  Index based lookup could work via odict.byindex().

Slicing tuples, lists, and strings return objects of the same type, so
slicing a sorted dict should return a sorted dict.

A sorted dict is the same data structure as a Berkeley DB table. Why
not use the term 'table' instead of 'sorteddict'?

Unless I am missing something big, the implementation of new key
insert for sorteddict looks inefficient - on average you have to move
half of your elements over one space. A B tree or B+ tree (or other
tree) would be a more efficient algorithm.

-1 for ordered dict
+1 for sorted dict

David