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