Devin Jeanpierre wrote:
On Fri, Mar 2, 2012 at 7:36 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Still, I reckon a directive is the right approach.
Why? That's how I do it because I am/was paranoid about compatibility, but surely fixing dicts is important enough that, done right, nobody would object if the semantics of comparison change subtly to allow for unordered container comparison in the "natural" way?
I would. doctest doesn't compare dicts. If you want to compare dicts, write your doctest like this:
d = make_dict(...) d == {'a': 42, 'b': 23, 'c': None} True
The dicts will be compared directly, and doctest need only care that the result looks like "True". doctest compares *strings*. Under no circumstances do I want the default doctest comparison to try to be "clever" by guessing when I want strings to match using string equality and when I want strings to match using something else. doctest should Do What I Say, and not try to Do What It Guesses I Mean. [...]
Punting it to a user-defined function is nice for _really_ crazy situations, but dicts and sets are not idiosyncratic or in any way exceptional. doctest itself should handle them the way a naive user would expect.
No it shouldn't. doctest should handle them the way they actually are. A naive user might expect that {'None': 1} == {None: 1}. A naive user might expect that {2: 'spam'} == {2: 'SPAM'}. The problem with trying to satisfy naive users is that their expectations are often wrong or poorly thought-out. You, the author of the package being tested, is the best person to judge what your tests should be, not some arbitrary naive user who may know nothing about Python and even less about your package. -- Steven