Skip to content

Commit 158219b

Browse files
author
Jim DeLaHunt
committed
bpo-29428: make doctest documentation clearer
Clarify the introduction of section, "How are Docstring Examples Recognized", by moving it to above the example and rewriting for clarity. Change the example in that section to use more plausible code, which also demonstrates a multi-line test fixture. Add three "fine print" points, about the example prefix strings, blank expected output, and multi-line expected output. Clarify the introduction of section, "What's the Execution Context", by rewriting for clarity, and breaking into three paragraphs. Copy-edit the first paragraph in section, "Which Docstrings Are Examined?".
1 parent e7ffb99 commit 158219b

File tree

1 file changed

+48
-23
lines changed

1 file changed

+48
-23
lines changed

Doc/library/doctest.rst

Lines changed: 48 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -276,8 +276,9 @@ sections.
276276
Which Docstrings Are Examined?
277277
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
278278

279-
The module docstring, and all function, class and method docstrings are
280-
searched. Objects imported into the module are not searched.
279+
The docstring for the module, and the docstrings for all functions,
280+
classes, and methods in that module, are searched.
281+
Objects imported into the module are not searched.
281282

282283
In addition, if ``M.__test__`` exists and "is true", it must be a dict, and each
283284
entry maps a (string) name to a function object, class object, or string.
@@ -300,33 +301,49 @@ their contained methods and nested classes.
300301
How are Docstring Examples Recognized?
301302
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
302303

304+
The :mod:`doctest` module treats any line beginning with ``>>>`` as an
305+
example to be tested.
306+
Following lines which begin with ``...`` continue the example.
307+
Subsequent non-blank lines, if any, form an expected output string.
308+
A blank (all-whitespace) line, or a line with ``>>>`` (beginning the
309+
next example), ends the expected output string.
310+
303311
In most cases a copy-and-paste of an interactive console session works fine,
304312
but doctest isn't trying to do an exact emulation of any specific Python shell.
305313

306314
::
307315

308316
>>> # comments are ignored
309-
>>> x = 12
310-
>>> x
311-
12
312-
>>> if x == 13:
313-
... print("yes")
317+
...
318+
>>> import math
319+
>>> x = factorial(10); math.ceil(math.log10(x))
320+
7
321+
>>> if x == factorial(9)*10:
322+
... print("same:\n{0}".format(x))
314323
... else:
315-
... print("no")
316-
... print("NO")
317-
... print("NO!!!")
324+
... print("differ:\n{0}\n{1}".format(x, factorial(9)*10))
318325
...
319-
no
320-
NO
321-
NO!!!
326+
same:
327+
3628800
322328
>>>
323329

324-
Any expected output must immediately follow the final ``'>>> '`` or ``'... '``
325-
line containing the code, and the expected output (if any) extends to the next
326-
``'>>> '`` or all-whitespace line.
327-
328330
The fine print:
329331

332+
* The ``>>>`` string tells the module to look for an interactive statement:
333+
that is, a statement list ending with a newline, or a
334+
:ref:`compound statement <compound>`.
335+
The ``...`` string tells the module that the line continues a compound
336+
statement. (Actually, doctest gets these strings from the PS1 and PS2
337+
values of the :mod:`sys` module.)
338+
339+
* The expected output can be absent. This indicates that the example generates
340+
no output when run. If the example does generate output, the module reports
341+
it as a failure.
342+
343+
* The expected output can contain multiple lines. These lines become a
344+
string, which is compared to the string of actual output from
345+
testing the example.
346+
330347
* Expected output cannot contain an all-whitespace line, since such a line is
331348
taken to signal the end of expected output. If expected output does contain a
332349
blank line, put ``<BLANKLINE>`` in your doctest example each place a blank line
@@ -381,12 +398,20 @@ The fine print:
381398
What's the Execution Context?
382399
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
383400

384-
By default, each time :mod:`doctest` finds a docstring to test, it uses a
385-
*shallow copy* of :mod:`M`'s globals, so that running tests doesn't change the
386-
module's real globals, and so that one test in :mod:`M` can't leave behind
387-
crumbs that accidentally allow another test to work. This means examples can
388-
freely use any names defined at top-level in :mod:`M`, and names defined earlier
389-
in the docstring being run. Examples cannot see names defined in other
401+
Within a docstring, later examples can use names defined by earlier
402+
examples. It's fine for an example to set up state, and
403+
have no output.
404+
405+
For each docstring, :mod:`doctest` makes (by default) a
406+
*shallow copy* of :mod:`M`'s globals.
407+
This means examples can freely use any names defined at the top level of
408+
:mod:`M`.
409+
When doctest tests examples, it doesn't change the module's real globals.
410+
411+
This shallow copy of globals is discarded at the end of each docstring,
412+
and copied afresh for the next docstring. Thus, examples in one docstring
413+
in :mod:`M` can't leave behind crumbs that accidentally allow an example
414+
in another docstring to work. Examples cannot see names defined in other
390415
docstrings.
391416

392417
You can force use of your own dict as the execution context by passing

0 commit comments

Comments
 (0)