Issue 933238: doctest: add a special (dedented) marker for blank lines (original) (raw)

Issue933238

Created on 2004-04-11 15:11 by edloper, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
doctest_blankline_marker.diff edloper,2004-04-11 15:11 Diff against doctest.py
Messages (4)
msg45742 - (view) Author: Edward Loper (edloper) * (Python triager) Date: 2004-04-11 15:11
A current limitation of doctest is that it can't handle output containing blank lines, since it uses blank lines to detect the end of the example. This patch uses adds special "blank line marker" to mark blank lines in the expected output. In order to distinguish this marker from actual output, it must be dedented such that it ends just before the doctest example's indentation. Here's an example use, with BLANKLINE_MARKER set to "-" (as it is in the patch): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ If desired, BLANKLINE_MARKER could be changed to another string. (This is an option for the developers of doctest, *not* for users.) E.g., here's the same example with BLANKLINE_MARKER="BL>": def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line BL> this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too BL> """ In the patch, the indentation rules for BLANKLINE_MARKER are fairly strict: it must be dedented to end one character before the indentation defined by the doctest example's prompt (>>>). But if desired, we could relax this restriction, and say that it simply has to be dedented further than the prompt. E.g., this would make the following legal (it currently is not): def _test_blankline_marker(): r""" This test example uses BLANKLINE_MARKER to signify a blank line: >>> print 'first line\n\nthis is after a blank line' first line - this is after a blank line >>> print 'trailing blanks can be marked too\n' trailing blanks can be marked too - """ This patch is probably mutually exclusive with patch #932933 [1], since they both have the same goal: to allow blank lines in doctest output. I thought of the other solution first, but I think I prefer this patch. Here's a comparison of pros and cons of this patch vs #932933. [+] it doesn't need a special option to turn it on [+] it handles trailing blank lines [+] it won't break external tools like epytext and restructuredtext that look for doctest blocks. [-] the user must manually add blank line markers. [1] <http://sourceforge.net/tracker/index.php? func=detail&aid=932933&group_id=5470&atid=3054 70> The patch was made avainst revision 1.33 of doctest.py. If this patch looks good, I'd be happy to write a patch for docs & test cases.
msg45743 - (view) Author: Edward Loper (edloper) * (Python triager) Date: 2004-04-11 15:18
Logged In: YES user_id=195958 I just noticed that sourceforge strips leading whitespace from every line. (Why does it do that?) You should be able to reconstruct what the examples should look like from the text, but if not, here's the first example with leading spaces replaced by periods: def _test_blankline_marker(): ....r""" ....This test example uses BLANKLINE_MARKER to signify ....a blank line: .... ........>>> print 'first line\n\nthis is after a blank line' ........first line .......- ........this is after a blank line ........>>> print 'trailing blanks can be marked too\n' ........trailing blank lines can be marked too .......- ...."""
msg45744 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-05-31 18:56
Logged In: YES user_id=21627 This patch is incomplete: It lacks changes to the documentation (libdoctest.tex) and to the test suite (test_libdoctest.tex). Pasting examples into the patch submission is futile: they are lost once the patch is accepted. So if you think users of your patch should know them, you should incorporate them into your patch - if not in the documentation, then perhaps in the Demo directory. Please submit a single patch file containing all changes. SF has not stripped the indentation; if you look at the HTML source, you'll see it is still there. However, in HTML, indentation is stripped by the web browsers. That is one reason why the submission guidelines say not to include the code in the description.
msg45745 - (view) Author: Johannes Gijsbers (jlgijsbers) * (Python triager) Date: 2004-08-21 11:19
Logged In: YES user_id=469548 Edward, it seems like recent doctest checkins have addressed this, so I'm closing this. Please reopen if I'm mistaken.
History
Date User Action Args
2022-04-11 14:56:03 admin set github: 40141
2004-04-11 15:11:22 edloper create