[Python-checkins] python/dist/src/Doc/lib libdoctest.tex,1.25,1.26

tim_one at users.sourceforge.net tim_one at users.sourceforge.net
Fri Aug 13 05:55:07 CEST 2004


Update of /cvsroot/python/python/dist/src/Doc/lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6538/Doc/lib

Modified Files:
	libdoctest.tex 
Log Message:
Doctest has new traceback gimmicks in 2.4.  While trying to document
them (which they are now), I had to rewrite the code to understand
it.  This has got to be the most DWIM part of doctest -- but in context
is really necessary.


Index: libdoctest.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/lib/libdoctest.tex,v
retrieving revision 1.25
retrieving revision 1.26
diff -C2 -d -r1.25 -r1.26
*** libdoctest.tex	13 Aug 2004 01:49:12 -0000	1.25
--- libdoctest.tex	13 Aug 2004 03:55:05 -0000	1.26
***************
*** 109,113 ****
  Trying: [factorial(long(n)) for n in range(6)]
  Expecting: [1, 1, 2, 6, 24, 120]
! ok\end{verbatim}
  
  And so on, eventually ending with:
--- 109,114 ----
  Trying: [factorial(long(n)) for n in range(6)]
  Expecting: [1, 1, 2, 6, 24, 120]
! ok
! \end{verbatim}
  
  And so on, eventually ending with:
***************
*** 130,139 ****
  
  That's all you need to know to start making productive use of
! \module{doctest}!  Jump in.
  
  \subsection{Simple Usage}
  
! The simplest (not necessarily the best) way to start using doctest is to
! end each module \module{M} with:
  
  \begin{verbatim}
--- 131,142 ----
  
  That's all you need to know to start making productive use of
! \module{doctest}!  Jump in.  The following sections provide full
! details.  Note that there are many examples of doctests in
! the standard Python test suite and libraries.
  
  \subsection{Simple Usage}
  
! The simplest way to start using doctest (but not necessarily the way
! you'll continue to do it) is to end each module \module{M} with:
  
  \begin{verbatim}
***************
*** 147,152 ****
  
  \module{doctest} then examines docstrings in the module calling
! \function{testmod()}.  If you want to test a different module, you can
! pass that module object to \function{testmod()}.
  
  Running the module as a script causes the examples in the docstrings
--- 150,154 ----
  
  \module{doctest} then examines docstrings in the module calling
! \function{testmod()}.
  
  Running the module as a script causes the examples in the docstrings
***************
*** 293,312 ****
  \subsection{What's the Execution Context?}
  
! By default, each time \function{testmod()} finds a docstring to test, it uses
! a \emph{copy} of \module{M}'s globals, so that running tests on a module
  doesn't change the module's real globals, and so that one test in
  \module{M} can't leave behind crumbs that accidentally allow another test
  to work.  This means examples can freely use any names defined at top-level
  in \module{M}, and names defined earlier in the docstring being run.
  
  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 \code{M.__dict__} merged with the globals from other
! imported modules.
  
  \subsection{What About Exceptions?}
  
! No problem, as long as the only output generated by the example is the
! traceback itself.  For example:
  
  \begin{verbatim}
--- 295,317 ----
  \subsection{What's the Execution Context?}
  
! By default, each time \function{testmod()} finds a docstring to test, it
! uses a \emph{shallow copy} of \module{M}'s globals, so that running tests
  doesn't change the module's real globals, and so that one test in
  \module{M} can't leave behind crumbs that accidentally allow another test
  to work.  This means examples can freely use any names defined at top-level
  in \module{M}, and names defined earlier in the docstring being run.
+ Examples cannot see names defined in other docstrings.
  
  You can force use of your own dict as the execution context by passing
! \code{globs=your_dict} to \function{testmod()} instead.
  
  \subsection{What About Exceptions?}
  
! No problem:  just paste in the expected traceback.  Since
! tracebacks contain details that are likely to change
! rapidly (for example, exact file paths and line numbers), this is one
! case where doctest works hard to be flexible in what it accepts.
! This makes the full story involved, but you really don't have
! to remember much.  Simple example:
  
  \begin{verbatim}
***************
*** 315,325 ****
    File "<stdin>", line 1, in ?
  ValueError: list.remove(x): x not in list
- >>>
  \end{verbatim}
  
! Note that only the exception type and value are compared (specifically,
! 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{Option Flags and Directive Names\label{doctest-options}}
--- 320,387 ----
    File "<stdin>", line 1, in ?
  ValueError: list.remove(x): x not in list
  \end{verbatim}
  
! That doctest succeeds if, and only if, \exception{ValueError} is raised,
! with the \samp{list.remove(x): x not in list} detail as shown.
! 
! The expected output for an exception is divided into four parts.
! First, an example may produce some normal output before an exception
! is raised, although that's unusual.  The "normal output" is taken to
! be everything until the first "Traceback" line, and is usually an
! empty string.  Next, the traceback line must be one of these two, and
! indented the same as the first line in the example:
! 
! \begin{verbatim}
! Traceback (most recent call last):
! Traceback (innermost last):
! \end{verbatim}
! 
! The most interesting part is the last part:  the line(s) starting with the
! exception type and detail.  This is usually the last line of a traceback,
! but can extend across any number of lines.  After the "Traceback" line,
! doctest simply ignores everything until the first line indented the same as
! the first line of the example, \emph{and} starting with an alphanumeric
! character.  This example illustrates the complexities that are possible:
! 
! \begin{verbatim}
! >>> print 1, 2; raise ValueError('printed 1\nand 2\n  but not 3')
! 1 2
! Traceback (most recent call last):
! ... indented the same, but doesn't start with an alphanumeric
!   not indented the same, so ignored too
!   File "/Python23/lib/doctest.py", line 442, in _run_examples_inner
!     compileflags, 1) in globs
!   File "<string>", line 1, in ?   # and all these are ignored
! ValueError: printed 1
! and 2
!   but not 3
! \end{verbatim}
! 
! The first (\samp{1 2}) and last three (starting with
! \exception{ValueError}) lines are compared, and the rest are ignored.
! 
! Best practice is to omit the ``File'' lines, unless they add
! significant documentation value to the example.  So the example above
! is probably better as:
! 
! \begin{verbatim}
! >>> print 1, 2; raise ValueError('printed 1\nand 2\n  but not 3')
! 1 2
! Traceback (most recent call last):
!    ...
! ValueError: printed 1
! and 2
!   but not 3
! \end{verbatim}
! 
! Note the tracebacks are treated very specially.  In particular, in the
! rewritten example, the use of \samp{...} is independent of doctest's
! \constant{ELLIPSIS} option.  The ellipsis in that example could
! be left out, or could just as well be three (or three hundred) commas.
! 
! \versionchanged[The abilities to check both normal output and an
!                 exception in a single example, and to have a multi-line
!                 exception detail, were added]{2.4}
! 
  
  \subsection{Option Flags and Directive Names\label{doctest-options}}



More information about the Python-checkins mailing list