Steven D'Aprano wrote: > Gisle Aas wrote: > >> Instead of introducing a sorteddict I would instead suggest that the >> future should bring an odict with a sort method; possibly also >> keys_sorted and items_sorted methods. > > Instead of odict.sorted(), that can be spelled: > > sorted(odict) # sort the keys > sorted(odict.values()) # sort the items > sorted(odict.items()) # sort the (key, value) pairs All of these are useful, but not when you want to sort the odict in-place. Since ordered dict is all about order, a method for changing the underlying key order seems quite useful. An odict.sort() would be easy to implement both in the current code (where it would delegate to self._keys.sort()) and in an alternative implementation using a linked list of keys (variants of mergesort work very nicely with linked lists). > The idea of a SortedDict is that it should be sorted at all times, A SortedDict would be nice to have, but we might rather want to use a balanced tree for the its C implementation, i.e. not inherit from dict at all.
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