Martin v. Löwis <martin <at> v.loewis.de> writes:
I compared multiple ordered dicts now (including Babel, Django and the C-implementation I mentioned earlier) and implemented a python version of the ordered dict as reference implementation:
I find the slicing API surprising. IMO, if you do support slicing, then a) the start and end indices should be the same ones that you also use in regular indexing. b) the result should be of the same kind as the thing being sliced, i.e. an odict.
So I would rather expect
odict.odict([('c', 'd'), ('foo', 'bar')])
The slicing operation that you provide should be spelled as d.items()[1:3], or, if you don't want to pay the cost of creating the full items list, then add a method such as d.slice_by_index(1,3). What's the use case for this operation, anyway?
The use case in my particular case is a ordered dict for messages of a .po file I want to display page-wise in an application. However I agree that it's not useful most of the time so dropping it makes sense. If an application really needs slicing it can still subclass it and implement that.
Furthermore with dict-views in Python 3 it would be possible to implement an efficient slicing operation on the dict view returned.