Why are there no ordered dictionaries?

[Bengt Richter]

On Tue, 29 Nov 2005 23:30:45 +0100, Christoph Zwerschke <cito at online.de> wrote:

>I had the same idea to create a py.test to verify and compare various 
>implementations. The doctests in odict.py are nice, but you can't use 
>them for this purpose and they may not test enough. It would be also 
>good to have something for testing and comparing performance.
>
Well, the previous post test file just grew to make a simple check for various
aspects, so it's not super clean. I just grepped for defs in the implementation
and bulk appended "test_" to make an empty starting point. Then I just filled
in tests after a preliminary sanity check test. But there are some things
that could still accidentally be inherited from the base class when builtin
utility functions are called on the dict object. Also there's a lot of cut-paste
duplication an no full explorations of corner cases. There's neat generator-based
test driving with different parameters that I didn't take advantage of,
etc. etc.

I should really read the py test docs and learn to use it
better if I am going to use it. But anyway, it's a q&d hack to show and
sanity-check different usages. The semantics of assigning slices
to d.keys[i:j] and d.values[i:j] are kind of tricky when the size changes
and/or key names match or don't match in various ways, or the incoming
data represents collapsing redundant keys that are legal sequential assignment
overrides but change the size, etc.

One could add keyword args to the constructor to vary key eq and cmp used
on keys to determine "key collisions" between e.g. tuple keys and also for
sort. You could even allow partially non-hashable keys that way if you got tricky.
But maybe this is getting too tricky ;-)

I'll make some simple mods to the test to allow applying it to arbitrary
candidate implementations with different names and directory locations, so
I can try it on odict.py and other versions. But are the semantics right?

Doctest is handy, and in some ways I like examples showing up in the help docs,
but maybe help should take a keyword arg to select showing them (and some other
things too perhaps. A brief version excluding a lot of inheritance for classes
might be nice. Or a pattern for method and class var inclusion.

But I like the separation of the py.test tests with no need to mod the original.
Where next? This ordered dict thing is kind of a side-track from a side-track for me ;-)

Regards,
Bengt Richter