On 21 September 2014 15:18, David Wilson <dw+python-ideas@hmmz.org> wrote:
Even after reviewing the original PEP, the presence of OrderedDict (and particularly under that moniker) feels wrong. Since its addition, in every case I've encountered it in commercial code, the use has been superfluous, diabolically miscomprehended, or used as a hacky stand-in for some cleaner, simpler approach.
The main intended use case for OrderedDict was preserving insertion order, such as when executing code, parsing a JSON file, or maintaining an LRU cache. For many cases involving a *sorted* key, just sorting when necessary is often easier than preserving sort order on every update (not necessarily *faster*, but often fast enough that the extra dependency isn't justified). That's the background any proposal needs to compete against: OrderedDict covers preserving insertion order, while actually sorting the keys or items when the sorted order is needed covers the sorting case. The needle to be threaded to get a "sorted container" into the standard library is clearly explaining *in terms a relatively junior programmer can understand* when you would use it over dict or OrderedDict. In particular, it likely needs to explain the trade-offs between maintaining sort order on insert, and using an unordered container that is sorted for display or serialisation. That justification needs to be in the PEP to justify the initial inclusion, but also in the eventual docs to help folks know when their current problem is the "it" in There Should Be One Obvious Way To Do It for the new type. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia