[Python-ideas] doctest
Steven D'Aprano
steve at pearwood.info
Fri Mar 2 15:57:52 CET 2012
Devin Jeanpierre wrote:
>> On Fri, Mar 2, 2012 at 7:36 AM, Steven D'Aprano <steve at 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
More information about the Python-ideas
mailing list