From 7eb1463bb39779d8aa7046df520ad12e669f3d8b Mon Sep 17 00:00:00 2001
From: Fred Drake <fdrake@acm.org>
Date: Sat, 17 Feb 2001 17:32:41 +0000
Subject: Make a variety of minor markup adjustments.

Close some environments so that this will actually format.
---
 Doc/lib/libdoctest.tex | 70 ++++++++++++++++++++++++++------------------------
 1 file changed, 37 insertions(+), 33 deletions(-)

diff --git a/Doc/lib/libdoctest.tex b/Doc/lib/libdoctest.tex
index d4e3170..fc95a31 100644
--- a/Doc/lib/libdoctest.tex
+++ b/Doc/lib/libdoctest.tex
@@ -94,8 +94,8 @@ $
 \end{verbatim}
 
 There's no output!  That's normal, and it means all the examples worked.
-Pass \code{-v} to the script, and doctest prints a detailed log of what it's
-trying, and prints a summary at the end:
+Pass \programopt{-v} to the script, and doctest prints a detailed log
+of what it's trying, and prints a summary at the end:
 
 \begin{verbatim}
 $ python example.py -v
@@ -161,24 +161,25 @@ python M.py
 
 This won't display anything unless an example fails, in which case the
 failing example(s) and the cause(s) of the failure(s) are printed to stdout,
-and the final line of output is \code{"Test failed."}.
+and the final line of output is \code{'Test failed.'}.
 
-Run it with the \code{-v} switch instead:
+Run it with the \programopt{-v} switch instead:
 
 \begin{verbatim}
 python M.py -v
 \end{verbatim}
 
-and a detailed report of all examples tried is printed to \var{stdout},
+and a detailed report of all examples tried is printed to \code{stdout},
 along with assorted summaries at the end.
 
 You can force verbose mode by passing \code{verbose=1} to testmod, or
 prohibit it by passing \code{verbose=0}.  In either of those cases,
-\var{sys.argv} is not examined by testmod.
+\code{sys.argv} is not examined by testmod.
 
-In any case, testmod returns a 2-tuple of ints \var{(f, t)}, where \var{f}
-is the number of docstring examples that failed and \var{t} is the total
-number of docstring examples attempted.
+In any case, testmod returns a 2-tuple of ints \code{(\var{f},
+\var{t})}, where \var{f} is the number of docstring examples that
+failed and \var{t} is the total number of docstring examples
+attempted.
 
 \subsection{Which Docstrings Are Examined?}
 
@@ -187,12 +188,12 @@ module docstring, and all function, class and method docstrings are
 searched, with the exception of docstrings attached to objects with private
 names.
 
-In addition, if \var{M.__test__} exists and "is true", it must be a dict,
-and each entry maps a (string) name to a function object, class object, or
-string.  Function and class object docstrings found from \var{M.__test__}
-are searched even if the name is private, and strings are searched directly
-as if they were docstrings.  In output, a key \var{K} in \var{M.__test__}
-appears with name
+In addition, if \code{M.__test__} exists and "is true", it must be a
+dict, and each entry maps a (string) name to a function object, class
+object, or string.  Function and class object docstrings found from
+\code{M.__test__} are searched even if the name is private, and
+strings are searched directly as if they were docstrings.  In output,
+a key \code{K} in \code{M.__test__} appears with name
 
 \begin{verbatim}
       <name of M>.__test__.K
@@ -201,7 +202,7 @@ appears with name
 Any classes found are recursively searched similarly, to test docstrings in
 their contained methods and nested classes.  While private names reached
 from \module{M}'s globals are skipped, all names reached from
-\var{M.__test__} are searched.
+\code{M.__test__} are searched.
 
 \subsection{What's the Execution Context?}
 
@@ -216,7 +217,7 @@ docstrings to use globals inappropriate for them.
 
 You can force use of your own dict as the execution context by passing
 \code{globs=your_dict} to \function{testmod()} instead.  Presumably this
-would be a copy of \var{M.__dict__} merged with the globals from other
+would be a copy of \code{M.__dict__} merged with the globals from other
 imported modules.
 
 \subsection{What About Exceptions?}
@@ -233,19 +234,19 @@ traceback itself.  For example:
 \end{verbatim}
 
 Note that only the exception type and value are compared (specifically,
-only the last line in the traceback).  The various \code{"File"} lines in
+only the last line in the traceback).  The various ``File'' lines in
 between can be left out (unless they add significantly to the documentation
 value of the example).
 
 \subsection{Advanced Usage}
 
 \function{testmod()} actually creates a local instance of class
-\class{doctest.Tester}, runs appropriate methods of that class, and merges
-the results into global \class{Tester} instance \var{doctest.master}.
+\class{Tester}, runs appropriate methods of that class, and merges
+the results into global \class{Tester} instance \code{master}.
 
-You can create your own instances of \class{doctest.Tester}, and so build
-your own policies, or even run methods of \var{doctest.master} directly.
-See \var{doctest.Tester.__doc__} for details.
+You can create your own instances of \class{Tester}, and so build your
+own policies, or even run methods of \code{master} directly.  See
+\code{Tester.__doc__} for details.
 
 
 \subsection{How are Docstring Examples Recognized?}
@@ -275,7 +276,7 @@ the business of guessing what you think a tab means).
 
 Any expected output must immediately follow the final \code{">>>"} or
 \code{"..."} line containing the code, and the expected output (if any)
-extends to the next \code{">>>"} or all-whitespace line.  That's it.
+extends to the next \code{">>>"} or all-whitespace line.
 
 The fine print:
 
@@ -304,13 +305,14 @@ The starting column doesn't matter:
 
 \begin{verbatim}
 >>> assert "Easy!"
-     >>> import math
-            >>> math.floor(1.9)
-            1.0
+>>> import math
+>>> math.floor(1.9)
+1.0
 \end{verbatim}
 
 and as many leading whitespace characters are stripped from the expected
 output as appeared in the initial ">>>" line that triggered it.
+\end{itemize}
 
 \subsection{Warnings}
 
@@ -322,11 +324,12 @@ output as appeared in the initial ">>>" line that triggered it.
 from XYZ import XYZclass
 \end{verbatim}
 
-then \class{XYZclass} is a name in \var{M.__dict__} too, and doctest has no
-way to know that \class{XYZclass} wasn't *defined* in \module{M}.  So it may
-try to execute the examples in \class{XYZclass}'s docstring, and those in
-turn may require a different set of globals to work correctly.  I prefer to
-do \code{import *}- friendly imports, a la
+then \class{XYZclass} is a name in \code{M.__dict__} too, and doctest
+has no way to know that \class{XYZclass} wasn't \emph{defined} in
+\module{M}.  So it may try to execute the examples in
+\class{XYZclass}'s docstring, and those in turn may require a
+different set of globals to work correctly.  I prefer to do
+``\code{import *}''-friendly imports, a la
 
 \begin{verbatim}
 from XYZ import XYZclass as _XYZclass
@@ -400,6 +403,7 @@ often contrive doctest examples to produce numbers of that form:
 
 Simple fractions are also easier for people to understand, and that makes
 for better documentation.
+\end{enumerate}
 
 
 \subsection{Soapbox}
@@ -425,4 +429,4 @@ by and "things change".  I'm still amazed at how often one of my doctest
 examples stops working after a "harmless" change.
 
 For exhaustive testing, or testing boring cases that add no value to the
-docs, define a \var{__test__} dict instead.  That's what it's for.
+docs, define a \code{__test__} dict instead.  That's what it's for.
-- 
cgit v0.12

