On Tue, 29 Nov 2005 23:30:45 +0100, Christoph Zwerschke <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
