Skip to content

Commit 8b3c66b

Browse files
miss-islingtonAlexWaygoodhugovk
authored
[3.12] gh-101100 : Fix Sphinx warnings in library/doctest.rst (GH-112399) (#112402)
Co-authored-by: Alex Waygood <[email protected]> Co-authored-by: Hugo van Kemenade <[email protected]>
1 parent e93af80 commit 8b3c66b

File tree

3 files changed

+30
-22
lines changed

3 files changed

+30
-22
lines changed

Doc/library/doctest.rst

Lines changed: 28 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -143,13 +143,13 @@ Simple Usage: Checking Examples in Docstrings
143143
---------------------------------------------
144144

145145
The simplest way to start using doctest (but not necessarily the way you'll
146-
continue to do it) is to end each module :mod:`M` with::
146+
continue to do it) is to end each module :mod:`!M` with::
147147

148148
if __name__ == "__main__":
149149
import doctest
150150
doctest.testmod()
151151

152-
:mod:`doctest` then examines docstrings in module :mod:`M`.
152+
:mod:`!doctest` then examines docstrings in module :mod:`!M`.
153153

154154
Running the module as a script causes the examples in the docstrings to get
155155
executed and verified::
@@ -403,10 +403,10 @@ What's the Execution Context?
403403
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
404404

405405
By default, each time :mod:`doctest` finds a docstring to test, it uses a
406-
*shallow copy* of :mod:`M`'s globals, so that running tests doesn't change the
407-
module's real globals, and so that one test in :mod:`M` can't leave behind
406+
*shallow copy* of :mod:`!M`'s globals, so that running tests doesn't change the
407+
module's real globals, and so that one test in :mod:`!M` can't leave behind
408408
crumbs that accidentally allow another test to work. This means examples can
409-
freely use any names defined at top-level in :mod:`M`, and names defined earlier
409+
freely use any names defined at top-level in :mod:`!M`, and names defined earlier
410410
in the docstring being run. Examples cannot see names defined in other
411411
docstrings.
412412

@@ -958,7 +958,8 @@ and :ref:`doctest-simple-testfile`.
958958

959959
Optional argument *exclude_empty* defaults to false. If true, objects for which
960960
no doctests are found are excluded from consideration. The default is a backward
961-
compatibility hack, so that code still using :meth:`doctest.master.summarize` in
961+
compatibility hack, so that code still using
962+
:meth:`doctest.master.summarize <DocTestRunner.summarize>` in
962963
conjunction with :func:`testmod` continues to get output for objects with no
963964
tests. The *exclude_empty* argument to the newer :class:`DocTestFinder`
964965
constructor defaults to true.
@@ -997,7 +998,7 @@ As your collection of doctest'ed modules grows, you'll want a way to run all
997998
their doctests systematically. :mod:`doctest` provides two functions that can
998999
be used to create :mod:`unittest` test suites from modules and text files
9991000
containing doctests. To integrate with :mod:`unittest` test discovery, include
1000-
a :func:`load_tests` function in your test module::
1001+
a :ref:`load_tests <load_tests-protocol>` function in your test module::
10011002

10021003
import unittest
10031004
import doctest
@@ -1111,19 +1112,24 @@ from text files and modules with doctests:
11111112
:func:`DocTestSuite` returns an empty :class:`unittest.TestSuite` if *module*
11121113
contains no docstrings instead of raising :exc:`ValueError`.
11131114

1115+
.. exception:: failureException
1116+
1117+
When doctests which have been converted to unit tests by :func:`DocFileSuite`
1118+
or :func:`DocTestSuite` fail, this exception is raised showing the name of
1119+
the file containing the test and a (sometimes approximate) line number.
11141120

11151121
Under the covers, :func:`DocTestSuite` creates a :class:`unittest.TestSuite` out
1116-
of :class:`doctest.DocTestCase` instances, and :class:`DocTestCase` is a
1117-
subclass of :class:`unittest.TestCase`. :class:`DocTestCase` isn't documented
1122+
of :class:`!doctest.DocTestCase` instances, and :class:`!DocTestCase` is a
1123+
subclass of :class:`unittest.TestCase`. :class:`!DocTestCase` isn't documented
11181124
here (it's an internal detail), but studying its code can answer questions about
11191125
the exact details of :mod:`unittest` integration.
11201126

11211127
Similarly, :func:`DocFileSuite` creates a :class:`unittest.TestSuite` out of
1122-
:class:`doctest.DocFileCase` instances, and :class:`DocFileCase` is a subclass
1123-
of :class:`DocTestCase`.
1128+
:class:`!doctest.DocFileCase` instances, and :class:`!DocFileCase` is a subclass
1129+
of :class:`!DocTestCase`.
11241130

11251131
So both ways of creating a :class:`unittest.TestSuite` run instances of
1126-
:class:`DocTestCase`. This is important for a subtle reason: when you run
1132+
:class:`!DocTestCase`. This is important for a subtle reason: when you run
11271133
:mod:`doctest` functions yourself, you can control the :mod:`doctest` options in
11281134
use directly, by passing option flags to :mod:`doctest` functions. However, if
11291135
you're writing a :mod:`unittest` framework, :mod:`unittest` ultimately controls
@@ -1144,14 +1150,14 @@ reporting flags specific to :mod:`unittest` support, via this function:
11441150
section :ref:`doctest-options`. Only "reporting flags" can be used.
11451151

11461152
This is a module-global setting, and affects all future doctests run by module
1147-
:mod:`unittest`: the :meth:`runTest` method of :class:`DocTestCase` looks at
1148-
the option flags specified for the test case when the :class:`DocTestCase`
1153+
:mod:`unittest`: the :meth:`!runTest` method of :class:`!DocTestCase` looks at
1154+
the option flags specified for the test case when the :class:`!DocTestCase`
11491155
instance was constructed. If no reporting flags were specified (which is the
1150-
typical and expected case), :mod:`doctest`'s :mod:`unittest` reporting flags are
1156+
typical and expected case), :mod:`!doctest`'s :mod:`unittest` reporting flags are
11511157
:ref:`bitwise ORed <bitwise>` into the option flags, and the option flags
11521158
so augmented are passed to the :class:`DocTestRunner` instance created to
11531159
run the doctest. If any reporting flags were specified when the
1154-
:class:`DocTestCase` instance was constructed, :mod:`doctest`'s
1160+
:class:`!DocTestCase` instance was constructed, :mod:`!doctest`'s
11551161
:mod:`unittest` reporting flags are ignored.
11561162

11571163
The value of the :mod:`unittest` reporting flags in effect before the function
@@ -1321,7 +1327,8 @@ Example Objects
13211327
A dictionary mapping from option flags to ``True`` or ``False``, which is used
13221328
to override default options for this example. Any option flags not contained
13231329
in this dictionary are left at their default value (as specified by the
1324-
:class:`DocTestRunner`'s :attr:`optionflags`). By default, no options are set.
1330+
:class:`DocTestRunner`'s :ref:`optionflags <doctest-options>`).
1331+
By default, no options are set.
13251332

13261333

13271334
.. _doctest-doctestfinder:
@@ -1448,7 +1455,7 @@ DocTestRunner objects
14481455
passing a subclass of :class:`OutputChecker` to the constructor.
14491456

14501457
The test runner's display output can be controlled in two ways. First, an output
1451-
function can be passed to :meth:`TestRunner.run`; this function will be called
1458+
function can be passed to :meth:`run`; this function will be called
14521459
with strings that should be displayed. It defaults to ``sys.stdout.write``. If
14531460
capturing the output is not sufficient, then the display output can be also
14541461
customized by subclassing DocTestRunner, and overriding the methods
@@ -1534,7 +1541,7 @@ DocTestRunner objects
15341541

15351542
The output of each example is checked using the :class:`DocTestRunner`'s
15361543
output checker, and the results are formatted by the
1537-
:meth:`DocTestRunner.report_\*` methods.
1544+
:meth:`!DocTestRunner.report_\*` methods.
15381545

15391546

15401547
.. method:: summarize(verbose=None)
@@ -1692,12 +1699,12 @@ code under the debugger:
16921699
module) of the object with the doctests of interest. The result is a string,
16931700
containing the object's docstring converted to a Python script, as described for
16941701
:func:`script_from_examples` above. For example, if module :file:`a.py`
1695-
contains a top-level function :func:`f`, then ::
1702+
contains a top-level function :func:`!f`, then ::
16961703

16971704
import a, doctest
16981705
print(doctest.testsource(a, "a.f"))
16991706

1700-
prints a script version of function :func:`f`'s docstring, with doctests
1707+
prints a script version of function :func:`!f`'s docstring, with doctests
17011708
converted to code, and the rest placed in comments.
17021709

17031710

Doc/library/unittest.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2318,6 +2318,8 @@ Loading and running tests
23182318
test names.
23192319

23202320

2321+
.. _load_tests-protocol:
2322+
23212323
load_tests Protocol
23222324
###################
23232325

Doc/tools/.nitignore

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -56,7 +56,6 @@ Doc/library/csv.rst
5656
Doc/library/datetime.rst
5757
Doc/library/dbm.rst
5858
Doc/library/decimal.rst
59-
Doc/library/doctest.rst
6059
Doc/library/email.charset.rst
6160
Doc/library/email.compat32-message.rst
6261
Doc/library/email.errors.rst

0 commit comments

Comments
 (0)