[Python-Dev] doctest improvements (original) (raw)

Tim Peters tim.one at comcast.net
Mon May 31 23:40:38 EDT 2004


[Tim Peters]

... but if the marker is changed to something wordy instead of "a magic character", I don't think the dedent trick is of much value anymore:

r""" A different marker: >>> print 'a\n\nb' a b """ Then when the expected output is (exactly) "", doctest would accept "", or a line with nothing other than whitespace, as a match. I can't get upset by that bit of ambiguity.

[Edward Loper]

I had ruled this out because I assumed that any change I made had to maintain backward compatibility.

We broke that last time around, with the gimmick to accept "True" ("False") when "1" ("0") is expected. Such highly limited ambiguities are OK by me by default, when they've got strong pragmatic benefit, and there's a way to turn them off.

But if this (minor) incompatibility is acceptable,

It is to me. Anyone object? The consequence is that, by default, a doctest that has

<blank line>

as a line of its expected output will pass if it actually produces

<blank line>

there, or if it produces an empty line there. There's no effect on doctests that currently contain an empty line as part of their expected output, because no such doctest exits (the rules made it impossible -- and still will).

BTW, I liked the dedent with the one-character "_" marker because then it screams "something's fishy here", provoking a user to stare at the docs to figure out what that may be. Something like is so close to being self-explanatory that I don't think an extra nudge is necessary (or even helpful -- I'd find it annoying).

then let me know and I'll write up a patch to implement it.

Cool! Let's wait to see if someone objects ... OK, time's up. Go for it.

Edward, are you familiar with the doctest uses in Zope3? doctest is getting used heavily there, and it's turning out very well so far. Jim has ideas for making it more useful there, and if you'd like I'd be delighted to have you join us in thrashing those ideas out. This week I expect we'll be buried under making various Zope and ZODB releases, but with some luck we'll plunge into the doctest ideas next week. While the invitation is being made to you, it's not necessarily limited to you .



More information about the Python-Dev mailing list