Tim Peters wrote:
That's more what I had in mind, 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 <blank line> b """
Then when the expected output is (exactly) "<blank line>", doctest would accept "<blank line>", or a line with nothing other than whitespace, as a match. I can't get upset by that bit of ambiguity.
I had ruled this out because I assumed that any change I made had to maintain backward compatibility. But if this (minor) incompatibility is acceptable, then let me know and I'll write up a patch to implement it. -Edward
[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 <blank line> b """
Then when the expected output is (exactly) "<blank line>", doctest would accept "<blank line>", 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 <blank line> 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 <wink>.
"Edward Loper"
Tim Peters wrote:
That's more what I had in mind, 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 <blank line> b """
Then when the expected output is (exactly) "<blank line>", doctest would accept "<blank line>", or a line with nothing other than whitespace, as a match. I can't get upset by that bit of ambiguity.
I had ruled this out because I assumed that any change I made had to maintain backward compatibility. But if this (minor) incompatibility is acceptable, then let me know and I'll write up a patch to implement it.
To me as a potential user, '<blank line>' is the uniquely obvious marker for a blank line. The ambiguity is fine; having it uniquely not match itself and therefore needing a special case escape mechanism would be worse. I think the explanation "<blank line> matches a blank line as well as itself" might be sufficient. Terry J. Reedy
participants (3)
-
Edward Loper -
Terry Reedy -
Tim Peters