[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