Dennis Benzinger wrote: > I'd prefer encoding the order in the class name, therefore I suggest > (Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the > first group to simply I probably is too confusing because of the use of > I as a prefix for interfaces. Except I just don't see this proliferation of dict types with different sort orders ever happening. The distinction between OrderedDict and dict is that the order of keys()/values()/items() isn't arbitrary the way it is in a regular dict - there's a defined order that will always be used. That's all the name tells you - if someone assumes they know what that ordering is without actually looking at the documentation (and gets it wrong as a result), then I don't see how that is any different from the fact that someone might mistakenly assume that list.sort() puts the items in descending order instead of ascending order. For other sort orders, it seems far more likely to me that a collections.SortedMap type would be added at some point in the future that accepts a key function like the one accepted by sorted() and list.sort(). Such a data type would make different trade-offs between insertion, deletion and lookup speeds than those made in the hash map based OrderedDict. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4