p!ranha?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>25.2. doctest — Test interactive Python examples — Python 2.7.5 documentation</title> <link rel="stylesheet" href="../_static/default.css" type="text/css" /> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" /> <script type="text/javascript"> var DOCUMENTATION_OPTIONS = { URL_ROOT: '../', VERSION: '2.7.5', COLLAPSE_INDEX: false, FILE_SUFFIX: '.html', HAS_SOURCE: true }; </script> <script type="text/javascript" src="../_static/jquery.js"></script> <script type="text/javascript" src="../_static/underscore.js"></script> <script type="text/javascript" src="../_static/doctools.js"></script> <script type="text/javascript" src="../_static/sidebar.js"></script> <link rel="search" type="application/opensearchdescription+xml" title="Search within Python 2.7.5 documentation" href="../_static/opensearch.xml"/> <link rel="author" title="About these documents" href="../about.html" /> <link rel="copyright" title="Copyright" href="../copyright.html" /> <link rel="top" title="Python 2.7.5 documentation" href="../index.html" /> <link rel="up" title="25. Development Tools" href="development.html" /> <link rel="next" title="25.3. unittest — Unit testing framework" href="unittest.html" /> <link rel="prev" title="25.1. pydoc — Documentation generator and online help system" href="pydoc.html" /> <link rel="shortcut icon" type="image/png" href="../_static/py.png" /> <script type="text/javascript" src="../_static/copybutton.js"></script> </head> <body> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="../genindex.html" title="General Index" accesskey="I">index</a></li> <li class="right" > <a href="../py-modindex.html" title="Python Module Index" >modules</a> |</li> <li class="right" > <a href="unittest.html" title="25.3. unittest — Unit testing framework" accesskey="N">next</a> |</li> <li class="right" > <a href="pydoc.html" title="25.1. pydoc — Documentation generator and online help system" accesskey="P">previous</a> |</li> <li><img src="../_static/py.png" alt="" style="vertical-align: middle; margin-top: -1px"/></li> <li><a href="http://www.python.org/">Python</a> »</li> <li> <a href="../index.html">Python 2.7.5 documentation</a> » </li> <li><a href="index.html" >The Python Standard Library</a> »</li> <li><a href="development.html" accesskey="U">25. Development Tools</a> »</li> </ul> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body"> <div class="section" id="module-doctest"> <h1>25.2. <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> — Test interactive Python examples<a class="headerlink" href="#module-doctest" title="Permalink to this headline">¶</a></h1> The <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> module searches for pieces of text that look like interactive Python sessions, and then executes those sessions to verify that they work exactly as shown. There are several common ways to use doctest: <ul class="simple"> <li>To check that a module’s docstrings are up-to-date by verifying that all interactive examples still work as documented.</li> <li>To perform regression testing by verifying that interactive examples from a test file or a test object work as expected.</li> <li>To write tutorial documentation for a package, liberally illustrated with input-output examples. Depending on whether the examples or the expository text are emphasized, this has the flavor of “literate testing” or “executable documentation”.</li> </ul> Here’s a complete but small example module: <div class="highlight-python"><div class="highlight"><pre>""" This is the "example" module. The example module supplies one function, factorial(). For example, >>> factorial(5) 120 """ def factorial(n): """Return the factorial of n, an exact integer >= 0. If the result is small enough to fit in an int, return an int. Else return a long. >>> [factorial(n) for n in range(6)] [1, 1, 2, 6, 24, 120] >>> [factorial(long(n)) for n in range(6)] [1, 1, 2, 6, 24, 120] >>> factorial(30) 265252859812191058636308480000000L >>> factorial(30L) 265252859812191058636308480000000L >>> factorial(-1) Traceback (most recent call last): ... ValueError: n must be >= 0 Factorials of floats are OK, but the float must be an exact integer: >>> factorial(30.1) Traceback (most recent call last): ... ValueError: n must be exact integer >>> factorial(30.0) 265252859812191058636308480000000L It must also not be ridiculously large: >>> factorial(1e100) Traceback (most recent call last): ... OverflowError: n too large """ import math if not n >= 0: raise ValueError("n must be >= 0") if math.floor(n) != n: raise ValueError("n must be exact integer") if n+1 == n: # catch a value like 1e300 raise OverflowError("n too large") result = 1 factor = 2 while factor <= n: result *= factor factor += 1 return result if __name__ == "__main__": import doctest doctest.testmod() </pre></div> </div> If you run <tt class="file docutils literal">example.py</tt> directly from the command line, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> works its magic: <div class="highlight-python"><pre>$ python example.py $</pre> </div> There’s no output! That’s normal, and it means all the examples worked. Pass <tt class="docutils literal">-v</tt> to the script, and <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> prints a detailed log of what it’s trying, and prints a summary at the end: <div class="highlight-python"><pre>$ python example.py -v Trying: factorial(5) Expecting: 120 ok Trying: [factorial(n) for n in range(6)] Expecting: [1, 1, 2, 6, 24, 120] ok Trying: [factorial(long(n)) for n in range(6)] Expecting: [1, 1, 2, 6, 24, 120] ok</pre> </div> And so on, eventually ending with: <div class="highlight-python"><pre>Trying: factorial(1e100) Expecting: Traceback (most recent call last): ... OverflowError: n too large ok 2 items passed all tests: 1 tests in __main__ 8 tests in __main__.factorial 9 tests in 2 items. 9 passed and 0 failed. Test passed. $</pre> </div> That’s all you need to know to start making productive use of <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a>! Jump in. The following sections provide full details. Note that there are many examples of doctests in the standard Python test suite and libraries. Especially useful examples can be found in the standard test file <tt class="file docutils literal">Lib/test/test_doctest.py</tt>. <div class="section" id="simple-usage-checking-examples-in-docstrings"> <h2>25.2.1. Simple Usage: Checking Examples in Docstrings<a class="headerlink" href="#simple-usage-checking-examples-in-docstrings" title="Permalink to this headline">¶</a></h2> The simplest way to start using doctest (but not necessarily the way you’ll continue to do it) is to end each module <tt class="xref py py-mod docutils literal">M</tt> with: <div class="highlight-python"><div class="highlight"><pre>if __name__ == "__main__": import doctest doctest.testmod() </pre></div> </div> <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> then examines docstrings in module <tt class="xref py py-mod docutils literal">M</tt>. Running the module as a script causes the examples in the docstrings to get executed and verified: <div class="highlight-python"><pre>python M.py</pre> </div> 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 <tt class="docutils literal">***Test Failed*** N failures.</tt>, where N is the number of examples that failed. Run it with the <tt class="docutils literal">-v</tt> switch instead: <div class="highlight-python"><pre>python M.py -v</pre> </div> and a detailed report of all examples tried is printed to standard output, along with assorted summaries at the end. You can force verbose mode by passing <tt class="docutils literal">verbose=True</tt> to <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>, or prohibit it by passing <tt class="docutils literal">verbose=False</tt>. In either of those cases, <tt class="docutils literal">sys.argv</tt> is not examined by <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> (so passing <tt class="docutils literal">-v</tt> or not has no effect). Since Python 2.6, there is also a command line shortcut for running <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>. You can instruct the Python interpreter to run the doctest module directly from the standard library and pass the module name(s) on the command line: <div class="highlight-python"><pre>python -m doctest -v example.py</pre> </div> This will import <tt class="file docutils literal">example.py</tt> as a standalone module and run <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> on it. Note that this may not work correctly if the file is part of a package and imports other submodules from that package. For more information on <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>, see section <a class="reference internal" href="#doctest-basic-api">Basic API</a>. </div> <div class="section" id="simple-usage-checking-examples-in-a-text-file"> <h2>25.2.2. Simple Usage: Checking Examples in a Text File<a class="headerlink" href="#simple-usage-checking-examples-in-a-text-file" title="Permalink to this headline">¶</a></h2> Another simple application of doctest is testing interactive examples in a text file. This can be done with the <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> function: <div class="highlight-python"><div class="highlight"><pre>import doctest doctest.testfile("example.txt") </pre></div> </div> That short script executes and verifies any interactive Python examples contained in the file <tt class="file docutils literal">example.txt</tt>. The file content is treated as if it were a single giant docstring; the file doesn’t need to contain a Python program! For example, perhaps <tt class="file docutils literal">example.txt</tt> contains this: <div class="highlight-python"><pre>The ``example`` module ====================== Using ``factorial`` ------------------- This is an example text file in reStructuredText format. First import ``factorial`` from the ``example`` module: >>> from example import factorial Now use it: >>> factorial(6) 120</pre> </div> Running <tt class="docutils literal">doctest.testfile("example.txt")</tt> then finds the error in this documentation: <div class="highlight-python"><pre>File "./example.txt", line 14, in example.txt Failed example: factorial(6) Expected: 120 Got: 720</pre> </div> As with <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>, <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> won’t display anything unless an example fails. If an example does fail, then the failing example(s) and the cause(s) of the failure(s) are printed to stdout, using the same format as <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>. By default, <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> looks for files in the calling module’s directory. See section <a class="reference internal" href="#doctest-basic-api">Basic API</a> for a description of the optional arguments that can be used to tell it to look for files in other locations. Like <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>, <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a>‘s verbosity can be set with the <tt class="docutils literal">-v</tt> command-line switch or with the optional keyword argument verbose. Since Python 2.6, there is also a command line shortcut for running <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a>. You can instruct the Python interpreter to run the doctest module directly from the standard library and pass the file name(s) on the command line: <div class="highlight-python"><pre>python -m doctest -v example.txt</pre> </div> Because the file name does not end with <tt class="file docutils literal">.py</tt>, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> infers that it must be run with <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a>, not <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>. For more information on <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a>, see section <a class="reference internal" href="#doctest-basic-api">Basic API</a>. </div> <div class="section" id="how-it-works"> <h2>25.2.3. How It Works<a class="headerlink" href="#how-it-works" title="Permalink to this headline">¶</a></h2> This section examines in detail how doctest works: which docstrings it looks at, how it finds interactive examples, what execution context it uses, how it handles exceptions, and how option flags can be used to control its behavior. This is the information that you need to know to write doctest examples; for information about actually running doctest on these examples, see the following sections. <div class="section" id="which-docstrings-are-examined"> <h3>25.2.3.1. Which Docstrings Are Examined?<a class="headerlink" href="#which-docstrings-are-examined" title="Permalink to this headline">¶</a></h3> The module docstring, and all function, class and method docstrings are searched. Objects imported into the module are not searched. In addition, if <tt class="docutils literal">M.__test__</tt> 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 <tt class="docutils literal">M.__test__</tt> are searched, and strings are treated as if they were docstrings. In output, a key <tt class="docutils literal">K</tt> in <tt class="docutils literal">M.__test__</tt> appears with name <div class="highlight-python"><pre><name of M>.__test__.K</pre> </div> Any classes found are recursively searched similarly, to test docstrings in their contained methods and nested classes. Changed in version 2.4: A “private name” concept is deprecated and no longer documented. </div> <div class="section" id="how-are-docstring-examples-recognized"> <h3>25.2.3.2. How are Docstring Examples Recognized?<a class="headerlink" href="#how-are-docstring-examples-recognized" title="Permalink to this headline">¶</a></h3> In most cases a copy-and-paste of an interactive console session works fine, but doctest isn’t trying to do an exact emulation of any specific Python shell. <div class="highlight-python"><div class="highlight"><pre>>>> # comments are ignored >>> x = 12 >>> x 12 >>> if x == 13: ... print "yes" ... else: ... print "no" ... print "NO" ... print "NO!!!" ... no NO NO!!! >>> </pre></div> </div> Any expected output must immediately follow the final <tt class="docutils literal">'>>> '</tt> or <tt class="docutils literal">'... '</tt> line containing the code, and the expected output (if any) extends to the next <tt class="docutils literal">'>>> '</tt> or all-whitespace line. The fine print: <ul> <li>Expected output cannot contain an all-whitespace line, since such a line is taken to signal the end of expected output. If expected output does contain a blank line, put <tt class="docutils literal"><BLANKLINE></tt> in your doctest example each place a blank line is expected. New in version 2.4: <tt class="docutils literal"><BLANKLINE></tt> was added; there was no way to use expected output containing empty lines in previous versions. </li> <li>All hard tab characters are expanded to spaces, using 8-column tab stops. Tabs in output generated by the tested code are not modified. Because any hard tabs in the sample output are expanded, this means that if the code output includes hard tabs, the only way the doctest can pass is if the <a class="reference internal" href="#doctest.NORMALIZE_WHITESPACE" title="doctest.NORMALIZE_WHITESPACE"><tt class="xref py py-const docutils literal">NORMALIZE_WHITESPACE</tt></a> option or <a class="reference internal" href="#doctest-directives">directive</a> is in effect. Alternatively, the test can be rewritten to capture the output and compare it to an expected value as part of the test. This handling of tabs in the source was arrived at through trial and error, and has proven to be the least error prone way of handling them. It is possible to use a different algorithm for handling tabs by writing a custom <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> class. Changed in version 2.4: Expanding tabs to spaces is new; previous versions tried to preserve hard tabs, with confusing results. </li> <li>Output to stdout is captured, but not output to stderr (exception tracebacks are captured via a different means). </li> <li>If you continue a line via backslashing in an interactive session, or for any other reason use a backslash, you should use a raw docstring, which will preserve your backslashes exactly as you type them: <div class="highlight-python"><div class="highlight"><pre>>>> def f(x): ... r'''Backslashes in a raw docstring: m\n''' >>> print f.__doc__ Backslashes in a raw docstring: m\n </pre></div> </div> Otherwise, the backslash will be interpreted as part of the string. For example, the <tt class="docutils literal">\n</tt> above would be interpreted as a newline character. Alternatively, you can double each backslash in the doctest version (and not use a raw string): <div class="highlight-python"><div class="highlight"><pre>>>> def f(x): ... '''Backslashes in a raw docstring: m\\n''' >>> print f.__doc__ Backslashes in a raw docstring: m\n </pre></div> </div> </li> <li>The starting column doesn’t matter: <div class="highlight-python"><div class="highlight"><pre>>>> assert "Easy!" >>> import math >>> math.floor(1.9) 1.0 </pre></div> </div> and as many leading whitespace characters are stripped from the expected output as appeared in the initial <tt class="docutils literal">'>>> '</tt> line that started the example. </li> </ul> </div> <div class="section" id="what-s-the-execution-context"> <h3>25.2.3.3. What’s the Execution Context?<a class="headerlink" href="#what-s-the-execution-context" title="Permalink to this headline">¶</a></h3> By default, each time <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> finds a docstring to test, it uses a shallow copy of <tt class="xref py py-mod docutils literal">M</tt>‘s globals, so that running tests doesn’t change the module’s real globals, and so that one test in <tt class="xref py py-mod docutils literal">M</tt> 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 <tt class="xref py py-mod docutils literal">M</tt>, 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 <tt class="docutils literal">globs=your_dict</tt> to <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> or <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> instead. </div> <div class="section" id="what-about-exceptions"> <h3>25.2.3.4. What About Exceptions?<a class="headerlink" href="#what-about-exceptions" title="Permalink to this headline">¶</a></h3> No problem, provided that the traceback is the only output produced by the example: just paste in the traceback. <a class="footnote-reference" href="#id2" id="id1">[1]</a> 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. Simple example: <div class="highlight-python"><div class="highlight"><pre>>>> [1, 2, 3].remove(42) Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: list.remove(x): x not in list </pre></div> </div> That doctest succeeds if <a class="reference internal" href="exceptions.html#exceptions.ValueError" title="exceptions.ValueError"><tt class="xref py py-exc docutils literal">ValueError</tt></a> is raised, with the <tt class="docutils literal">list.remove(x): x not in list</tt> detail as shown. The expected output for an exception must start with a traceback header, which may be either of the following two lines, indented the same as the first line of the example: <div class="highlight-python"><pre>Traceback (most recent call last): Traceback (innermost last):</pre> </div> The traceback header is followed by an optional traceback stack, whose contents are ignored by doctest. The traceback stack is typically omitted, or copied verbatim from an interactive session. The traceback stack is followed by the most interesting part: the line(s) containing the exception type and detail. This is usually the last line of a traceback, but can extend across multiple lines if the exception has a multi-line detail: <div class="highlight-python"><div class="highlight"><pre>>>> raise ValueError('multi\n line\ndetail') Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: multi line detail </pre></div> </div> The last three lines (starting with <a class="reference internal" href="exceptions.html#exceptions.ValueError" title="exceptions.ValueError"><tt class="xref py py-exc docutils literal">ValueError</tt></a>) are compared against the exception’s type and detail, and the rest are ignored. Changed in version 2.4: Previous versions were unable to handle multi-line exception details. Best practice is to omit the traceback stack, unless it adds significant documentation value to the example. So the last example is probably better as: <div class="highlight-python"><div class="highlight"><pre>>>> raise ValueError('multi\n line\ndetail') Traceback (most recent call last): ... ValueError: multi line detail </pre></div> </div> Note that tracebacks are treated very specially. In particular, in the rewritten example, the use of <tt class="docutils literal">...</tt> is independent of doctest’s <a class="reference internal" href="#doctest.ELLIPSIS" title="doctest.ELLIPSIS"><tt class="xref py py-const docutils literal">ELLIPSIS</tt></a> option. The ellipsis in that example could be left out, or could just as well be three (or three hundred) commas or digits, or an indented transcript of a Monty Python skit. Some details you should read once, but won’t need to remember: <ul> <li>Doctest can’t guess whether your expected output came from an exception traceback or from ordinary printing. So, e.g., an example that expects <tt class="docutils literal">ValueError: 42 is prime</tt> will pass whether <a class="reference internal" href="exceptions.html#exceptions.ValueError" title="exceptions.ValueError"><tt class="xref py py-exc docutils literal">ValueError</tt></a> is actually raised or if the example merely prints that traceback text. In practice, ordinary output rarely begins with a traceback header line, so this doesn’t create real problems. </li> <li>Each line of the traceback stack (if present) must be indented further than the first line of the example, or start with a non-alphanumeric character. The first line following the traceback header indented the same and starting with an alphanumeric is taken to be the start of the exception detail. Of course this does the right thing for genuine tracebacks. </li> <li>When the <a class="reference internal" href="#doctest.IGNORE_EXCEPTION_DETAIL" title="doctest.IGNORE_EXCEPTION_DETAIL"><tt class="xref py py-const docutils literal">IGNORE_EXCEPTION_DETAIL</tt></a> doctest option is specified, everything following the leftmost colon and any module information in the exception name is ignored. </li> <li>The interactive shell omits the traceback header line for some <a class="reference internal" href="exceptions.html#exceptions.SyntaxError" title="exceptions.SyntaxError"><tt class="xref py py-exc docutils literal">SyntaxError</tt></a>s. But doctest uses the traceback header line to distinguish exceptions from non-exceptions. So in the rare case where you need to test a <a class="reference internal" href="exceptions.html#exceptions.SyntaxError" title="exceptions.SyntaxError"><tt class="xref py py-exc docutils literal">SyntaxError</tt></a> that omits the traceback header, you will need to manually add the traceback header line to your test example. </li> <li>For some <a class="reference internal" href="exceptions.html#exceptions.SyntaxError" title="exceptions.SyntaxError"><tt class="xref py py-exc docutils literal">SyntaxError</tt></a>s, Python displays the character position of the syntax error, using a <tt class="docutils literal">^</tt> marker: <div class="highlight-python"><div class="highlight"><pre>>>> 1 1 File "<stdin>", line 1 1 1 ^ SyntaxError: invalid syntax </pre></div> </div> Since the lines showing the position of the error come before the exception type and detail, they are not checked by doctest. For example, the following test would pass, even though it puts the <tt class="docutils literal">^</tt> marker in the wrong location: <div class="highlight-python"><div class="highlight"><pre>>>> 1 1 File "<stdin>", line 1 1 1 ^ SyntaxError: invalid syntax </pre></div> </div> </li> </ul> </div> <div class="section" id="option-flags"> <h3>25.2.3.5. Option Flags<a class="headerlink" href="#option-flags" title="Permalink to this headline">¶</a></h3> A number of option flags control various aspects of doctest’s behavior. Symbolic names for the flags are supplied as module constants, which can be or’ed together and passed to various functions. The names can also be used in <a class="reference internal" href="#doctest-directives">doctest directives</a>. The first group of options define test semantics, controlling aspects of how doctest decides whether actual output matches an example’s expected output: <dl class="data"> <dt id="doctest.DONT_ACCEPT_TRUE_FOR_1"> <tt class="descclassname">doctest.</tt><tt class="descname">DONT_ACCEPT_TRUE_FOR_1</tt><a class="headerlink" href="#doctest.DONT_ACCEPT_TRUE_FOR_1" title="Permalink to this definition">¶</a></dt> <dd>By default, if an expected output block contains just <tt class="docutils literal">1</tt>, an actual output block containing just <tt class="docutils literal">1</tt> or just <tt class="docutils literal">True</tt> is considered to be a match, and similarly for <tt class="docutils literal">0</tt> versus <tt class="docutils literal">False</tt>. When <a class="reference internal" href="#doctest.DONT_ACCEPT_TRUE_FOR_1" title="doctest.DONT_ACCEPT_TRUE_FOR_1"><tt class="xref py py-const docutils literal">DONT_ACCEPT_TRUE_FOR_1</tt></a> is specified, neither substitution is allowed. The default behavior caters to that Python changed the return type of many functions from integer to boolean; doctests expecting “little integer” output still work in these cases. This option will probably go away, but not for several years. </dd></dl> <dl class="data"> <dt id="doctest.DONT_ACCEPT_BLANKLINE"> <tt class="descclassname">doctest.</tt><tt class="descname">DONT_ACCEPT_BLANKLINE</tt><a class="headerlink" href="#doctest.DONT_ACCEPT_BLANKLINE" title="Permalink to this definition">¶</a></dt> <dd>By default, if an expected output block contains a line containing only the string <tt class="docutils literal"><BLANKLINE></tt>, then that line will match a blank line in the actual output. Because a genuinely blank line delimits the expected output, this is the only way to communicate that a blank line is expected. When <a class="reference internal" href="#doctest.DONT_ACCEPT_BLANKLINE" title="doctest.DONT_ACCEPT_BLANKLINE"><tt class="xref py py-const docutils literal">DONT_ACCEPT_BLANKLINE</tt></a> is specified, this substitution is not allowed. </dd></dl> <dl class="data"> <dt id="doctest.NORMALIZE_WHITESPACE"> <tt class="descclassname">doctest.</tt><tt class="descname">NORMALIZE_WHITESPACE</tt><a class="headerlink" href="#doctest.NORMALIZE_WHITESPACE" title="Permalink to this definition">¶</a></dt> <dd>When specified, all sequences of whitespace (blanks and newlines) are treated as equal. Any sequence of whitespace within the expected output will match any sequence of whitespace within the actual output. By default, whitespace must match exactly. <a class="reference internal" href="#doctest.NORMALIZE_WHITESPACE" title="doctest.NORMALIZE_WHITESPACE"><tt class="xref py py-const docutils literal">NORMALIZE_WHITESPACE</tt></a> is especially useful when a line of expected output is very long, and you want to wrap it across multiple lines in your source. </dd></dl> <dl class="data"> <dt id="doctest.ELLIPSIS"> <tt class="descclassname">doctest.</tt><tt class="descname">ELLIPSIS</tt><a class="headerlink" href="#doctest.ELLIPSIS" title="Permalink to this definition">¶</a></dt> <dd>When specified, an ellipsis marker (<tt class="docutils literal">...</tt>) in the expected output can match any substring in the actual output. This includes substrings that span line boundaries, and empty substrings, so it’s best to keep usage of this simple. Complicated uses can lead to the same kinds of “oops, it matched too much!” surprises that <tt class="docutils literal">.*</tt> is prone to in regular expressions. </dd></dl> <dl class="data"> <dt id="doctest.IGNORE_EXCEPTION_DETAIL"> <tt class="descclassname">doctest.</tt><tt class="descname">IGNORE_EXCEPTION_DETAIL</tt><a class="headerlink" href="#doctest.IGNORE_EXCEPTION_DETAIL" title="Permalink to this definition">¶</a></dt> <dd>When specified, an example that expects an exception passes if an exception of the expected type is raised, even if the exception detail does not match. For example, an example expecting <tt class="docutils literal">ValueError: 42</tt> will pass if the actual exception raised is <tt class="docutils literal">ValueError: 3*14</tt>, but will fail, e.g., if <a class="reference internal" href="exceptions.html#exceptions.TypeError" title="exceptions.TypeError"><tt class="xref py py-exc docutils literal">TypeError</tt></a> is raised. It will also ignore the module name used in Python 3 doctest reports. Hence both of these variations will work with the flag specified, regardless of whether the test is run under Python 2.7 or Python 3.2 (or later versions): <div class="highlight-python"><div class="highlight"><pre>>>> raise CustomError('message') Traceback (most recent call last): CustomError: message >>> raise CustomError('message') Traceback (most recent call last): my_module.CustomError: message </pre></div> </div> Note that <a class="reference internal" href="#doctest.ELLIPSIS" title="doctest.ELLIPSIS"><tt class="xref py py-const docutils literal">ELLIPSIS</tt></a> can also be used to ignore the details of the exception message, but such a test may still fail based on whether or not the module details are printed as part of the exception name. Using <a class="reference internal" href="#doctest.IGNORE_EXCEPTION_DETAIL" title="doctest.IGNORE_EXCEPTION_DETAIL"><tt class="xref py py-const docutils literal">IGNORE_EXCEPTION_DETAIL</tt></a> and the details from Python 2.3 is also the only clear way to write a doctest that doesn’t care about the exception detail yet continues to pass under Python 2.3 or earlier (those releases do not support <a class="reference internal" href="#doctest-directives">doctest directives</a> and ignore them as irrelevant comments). For example: <div class="highlight-python"><div class="highlight"><pre>>>> (1, 2)[3] = 'moo' Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object doesn't support item assignment </pre></div> </div> passes under Python 2.3 and later Python versions with the flag specified, even though the detail changed in Python 2.4 to say “does not” instead of “doesn’t”. Changed in version 2.7: <a class="reference internal" href="#doctest.IGNORE_EXCEPTION_DETAIL" title="doctest.IGNORE_EXCEPTION_DETAIL"><tt class="xref py py-const docutils literal">IGNORE_EXCEPTION_DETAIL</tt></a> now also ignores any information relating to the module containing the exception under test </dd></dl> <dl class="data"> <dt id="doctest.SKIP"> <tt class="descclassname">doctest.</tt><tt class="descname">SKIP</tt><a class="headerlink" href="#doctest.SKIP" title="Permalink to this definition">¶</a></dt> <dd>When specified, do not run the example at all. This can be useful in contexts where doctest examples serve as both documentation and test cases, and an example should be included for documentation purposes, but should not be checked. E.g., the example’s output might be random; or the example might depend on resources which would be unavailable to the test driver. The SKIP flag can also be used for temporarily “commenting out” examples. </dd></dl> New in version 2.5. <dl class="data"> <dt id="doctest.COMPARISON_FLAGS"> <tt class="descclassname">doctest.</tt><tt class="descname">COMPARISON_FLAGS</tt><a class="headerlink" href="#doctest.COMPARISON_FLAGS" title="Permalink to this definition">¶</a></dt> <dd>A bitmask or’ing together all the comparison flags above. </dd></dl> The second group of options controls how test failures are reported: <dl class="data"> <dt id="doctest.REPORT_UDIFF"> <tt class="descclassname">doctest.</tt><tt class="descname">REPORT_UDIFF</tt><a class="headerlink" href="#doctest.REPORT_UDIFF" title="Permalink to this definition">¶</a></dt> <dd>When specified, failures that involve multi-line expected and actual outputs are displayed using a unified diff. </dd></dl> <dl class="data"> <dt id="doctest.REPORT_CDIFF"> <tt class="descclassname">doctest.</tt><tt class="descname">REPORT_CDIFF</tt><a class="headerlink" href="#doctest.REPORT_CDIFF" title="Permalink to this definition">¶</a></dt> <dd>When specified, failures that involve multi-line expected and actual outputs will be displayed using a context diff. </dd></dl> <dl class="data"> <dt id="doctest.REPORT_NDIFF"> <tt class="descclassname">doctest.</tt><tt class="descname">REPORT_NDIFF</tt><a class="headerlink" href="#doctest.REPORT_NDIFF" title="Permalink to this definition">¶</a></dt> <dd>When specified, differences are computed by <tt class="docutils literal">difflib.Differ</tt>, using the same algorithm as the popular <tt class="file docutils literal">ndiff.py</tt> utility. This is the only method that marks differences within lines as well as across lines. For example, if a line of expected output contains digit <tt class="docutils literal">1</tt> where actual output contains letter <tt class="docutils literal">l</tt>, a line is inserted with a caret marking the mismatching column positions. </dd></dl> <dl class="data"> <dt id="doctest.REPORT_ONLY_FIRST_FAILURE"> <tt class="descclassname">doctest.</tt><tt class="descname">REPORT_ONLY_FIRST_FAILURE</tt><a class="headerlink" href="#doctest.REPORT_ONLY_FIRST_FAILURE" title="Permalink to this definition">¶</a></dt> <dd>When specified, display the first failing example in each doctest, but suppress output for all remaining examples. This will prevent doctest from reporting correct examples that break because of earlier failures; but it might also hide incorrect examples that fail independently of the first failure. When <a class="reference internal" href="#doctest.REPORT_ONLY_FIRST_FAILURE" title="doctest.REPORT_ONLY_FIRST_FAILURE"><tt class="xref py py-const docutils literal">REPORT_ONLY_FIRST_FAILURE</tt></a> is specified, the remaining examples are still run, and still count towards the total number of failures reported; only the output is suppressed. </dd></dl> <dl class="data"> <dt id="doctest.REPORTING_FLAGS"> <tt class="descclassname">doctest.</tt><tt class="descname">REPORTING_FLAGS</tt><a class="headerlink" href="#doctest.REPORTING_FLAGS" title="Permalink to this definition">¶</a></dt> <dd>A bitmask or’ing together all the reporting flags above. </dd></dl> New in version 2.4: The constants <a class="reference internal" href="#doctest.DONT_ACCEPT_BLANKLINE" title="doctest.DONT_ACCEPT_BLANKLINE"><tt class="xref py py-const docutils literal">DONT_ACCEPT_BLANKLINE</tt></a>, <a class="reference internal" href="#doctest.NORMALIZE_WHITESPACE" title="doctest.NORMALIZE_WHITESPACE"><tt class="xref py py-const docutils literal">NORMALIZE_WHITESPACE</tt></a>, <a class="reference internal" href="#doctest.ELLIPSIS" title="doctest.ELLIPSIS"><tt class="xref py py-const docutils literal">ELLIPSIS</tt></a>, <a class="reference internal" href="#doctest.IGNORE_EXCEPTION_DETAIL" title="doctest.IGNORE_EXCEPTION_DETAIL"><tt class="xref py py-const docutils literal">IGNORE_EXCEPTION_DETAIL</tt></a>, <a class="reference internal" href="#doctest.REPORT_UDIFF" title="doctest.REPORT_UDIFF"><tt class="xref py py-const docutils literal">REPORT_UDIFF</tt></a>, <a class="reference internal" href="#doctest.REPORT_CDIFF" title="doctest.REPORT_CDIFF"><tt class="xref py py-const docutils literal">REPORT_CDIFF</tt></a>, <a class="reference internal" href="#doctest.REPORT_NDIFF" title="doctest.REPORT_NDIFF"><tt class="xref py py-const docutils literal">REPORT_NDIFF</tt></a>, <a class="reference internal" href="#doctest.REPORT_ONLY_FIRST_FAILURE" title="doctest.REPORT_ONLY_FIRST_FAILURE"><tt class="xref py py-const docutils literal">REPORT_ONLY_FIRST_FAILURE</tt></a>, <a class="reference internal" href="#doctest.COMPARISON_FLAGS" title="doctest.COMPARISON_FLAGS"><tt class="xref py py-const docutils literal">COMPARISON_FLAGS</tt></a> and <a class="reference internal" href="#doctest.REPORTING_FLAGS" title="doctest.REPORTING_FLAGS"><tt class="xref py py-const docutils literal">REPORTING_FLAGS</tt></a> were added. There’s also a way to register new option flag names, although this isn’t useful unless you intend to extend <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> internals via subclassing: <dl class="function"> <dt id="doctest.register_optionflag"> <tt class="descclassname">doctest.</tt><tt class="descname">register_optionflag</tt><big>(</big>name<big>)</big><a class="headerlink" href="#doctest.register_optionflag" title="Permalink to this definition">¶</a></dt> <dd>Create a new option flag with a given name, and return the new flag’s integer value. <a class="reference internal" href="#doctest.register_optionflag" title="doctest.register_optionflag"><tt class="xref py py-func docutils literal">register_optionflag()</tt></a> can be used when subclassing <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> or <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to create new options that are supported by your subclasses. <a class="reference internal" href="#doctest.register_optionflag" title="doctest.register_optionflag"><tt class="xref py py-func docutils literal">register_optionflag()</tt></a> should always be called using the following idiom: <div class="highlight-python"><div class="highlight"><pre>MY_FLAG = register_optionflag('MY_FLAG') </pre></div> </div> New in version 2.4. </dd></dl> </div> <div class="section" id="directives"> <h3>25.2.3.6. Directives<a class="headerlink" href="#directives" title="Permalink to this headline">¶</a></h3> Doctest directives may be used to modify the <a class="reference internal" href="#doctest-options">option flags</a> for an individual example. Doctest directives are special Python comments following an example’s source code: <pre> directive ::= "#" "doctest:" <a class="reference internal" href="#grammar-token-directive_options"><tt class="xref docutils literal">directive_options</tt></a> directive_options ::= <a class="reference internal" href="#grammar-token-directive_option"><tt class="xref docutils literal">directive_option</tt></a> ("," <a class="reference internal" href="#grammar-token-directive_option"><tt class="xref docutils literal">directive_option</tt></a>)\* directive_option ::= <a class="reference internal" href="#grammar-token-on_or_off"><tt class="xref docutils literal">on_or_off</tt></a> <a class="reference internal" href="#grammar-token-directive_option_name"><tt class="xref docutils literal">directive_option_name</tt></a> on_or_off ::= "+" \| "-" directive_option_name ::= "DONT_ACCEPT_BLANKLINE" \| "NORMALIZE_WHITESPACE" \| ... </pre> Whitespace is not allowed between the <tt class="docutils literal">+</tt> or <tt class="docutils literal">-</tt> and the directive option name. The directive option name can be any of the option flag names explained above. An example’s doctest directives modify doctest’s behavior for that single example. Use <tt class="docutils literal">+</tt> to enable the named behavior, or <tt class="docutils literal">-</tt> to disable it. For example, this test passes: <div class="highlight-python"><div class="highlight"><pre>>>> print range(20) # doctest: +NORMALIZE_WHITESPACE [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] </pre></div> </div> Without the directive it would fail, both because the actual output doesn’t have two blanks before the single-digit list elements, and because the actual output is on a single line. This test also passes, and also requires a directive to do so: <div class="highlight-python"><div class="highlight"><pre>>>> print range(20) # doctest: +ELLIPSIS [0, 1, ..., 18, 19] </pre></div> </div> Multiple directives can be used on a single physical line, separated by commas: <div class="highlight-python"><div class="highlight"><pre>>>> print range(20) # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE [0, 1, ..., 18, 19] </pre></div> </div> If multiple directive comments are used for a single example, then they are combined: <div class="highlight-python"><div class="highlight"><pre>>>> print range(20) # doctest: +ELLIPSIS ... # doctest: +NORMALIZE_WHITESPACE [0, 1, ..., 18, 19] </pre></div> </div> As the previous example shows, you can add <tt class="docutils literal">...</tt> lines to your example containing only directives. This can be useful when an example is too long for a directive to comfortably fit on the same line: <div class="highlight-python"><div class="highlight"><pre>>>> print range(5) + range(10,20) + range(30,40) + range(50,60) ... # doctest: +ELLIPSIS [0, ..., 4, 10, ..., 19, 30, ..., 39, 50, ..., 59] </pre></div> </div> Note that since all options are disabled by default, and directives apply only to the example they appear in, enabling options (via <tt class="docutils literal">+</tt> in a directive) is usually the only meaningful choice. However, option flags can also be passed to functions that run doctests, establishing different defaults. In such cases, disabling an option via <tt class="docutils literal">-</tt> in a directive can be useful. New in version 2.4: Support for doctest directives was added. </div> <div class="section" id="warnings"> <h3>25.2.3.7. Warnings<a class="headerlink" href="#warnings" title="Permalink to this headline">¶</a></h3> <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> is serious about requiring exact matches in expected output. If even a single character doesn’t match, the test fails. This will probably surprise you a few times, as you learn exactly what Python does and doesn’t guarantee about output. For example, when printing a dict, Python doesn’t guarantee that the key-value pairs will be printed in any particular order, so a test like <div class="highlight-python"><div class="highlight"><pre>>>> foo() {"Hermione": "hippogryph", "Harry": "broomstick"} </pre></div> </div> is vulnerable! One workaround is to do <div class="highlight-python"><div class="highlight"><pre>>>> foo() == {"Hermione": "hippogryph", "Harry": "broomstick"} True </pre></div> </div> instead. Another is to do <div class="highlight-python"><div class="highlight"><pre>>>> d = foo().items() >>> d.sort() >>> d [('Harry', 'broomstick'), ('Hermione', 'hippogryph')] </pre></div> </div> There are others, but you get the idea. Another bad idea is to print things that embed an object address, like <div class="highlight-python"><div class="highlight"><pre>>>> id(1.0) # certain to fail some of the time 7948648 >>> class C: pass >>> C() # the default repr() for instances embeds an address <__main__.C instance at 0x00AC18F0> </pre></div> </div> The <a class="reference internal" href="#doctest.ELLIPSIS" title="doctest.ELLIPSIS"><tt class="xref py py-const docutils literal">ELLIPSIS</tt></a> directive gives a nice approach for the last example: <div class="highlight-python"><div class="highlight"><pre>>>> C() #doctest: +ELLIPSIS <__main__.C instance at 0x...> </pre></div> </div> Floating-point numbers are also subject to small output variations across platforms, because Python defers to the platform C library for float formatting, and C libraries vary widely in quality here. <div class="highlight-python"><div class="highlight"><pre>>>> 1./7 # risky 0.14285714285714285 >>> print 1./7 # safer 0.142857142857 >>> print round(1./7, 6) # much safer 0.142857 </pre></div> </div> Numbers of the form <tt class="docutils literal">I/2.**J</tt> are safe across all platforms, and I often contrive doctest examples to produce numbers of that form: <div class="highlight-python"><div class="highlight"><pre>>>> 3./4 # utterly safe 0.75 </pre></div> </div> Simple fractions are also easier for people to understand, and that makes for better documentation. </div> </div> <div class="section" id="basic-api"> <h2>25.2.4. Basic API<a class="headerlink" href="#basic-api" title="Permalink to this headline">¶</a></h2> The functions <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> and <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> provide a simple interface to doctest that should be sufficient for most basic uses. For a less formal introduction to these two functions, see sections <a class="reference internal" href="#doctest-simple-testmod">Simple Usage: Checking Examples in Docstrings</a> and <a class="reference internal" href="#doctest-simple-testfile">Simple Usage: Checking Examples in a Text File</a>. <dl class="function"> <dt id="doctest.testfile"> <tt class="descclassname">doctest.</tt><tt class="descname">testfile</tt><big>(</big>filename[, module_relative][, name][, package][, globs][, verbose][, report][, optionflags][, extraglobs][, raise_on_error][, parser][, encoding]<big>)</big><a class="headerlink" href="#doctest.testfile" title="Permalink to this definition">¶</a></dt> <dd>All arguments except filename are optional, and should be specified in keyword form. Test examples in the file named filename. Return <tt class="docutils literal">(failure_count, test_count)</tt>. Optional argument module_relative specifies how the filename should be interpreted: <ul class="simple"> <li>If module_relative is <tt class="docutils literal">True</tt> (the default), then filename specifies an OS-independent module-relative path. By default, this path is relative to the calling module’s directory; but if the package argument is specified, then it is relative to that package. To ensure OS-independence, filename should use <tt class="docutils literal">/</tt> characters to separate path segments, and may not be an absolute path (i.e., it may not begin with <tt class="docutils literal">/</tt>).</li> <li>If module_relative is <tt class="docutils literal">False</tt>, then filename specifies an OS-specific path. The path may be absolute or relative; relative paths are resolved with respect to the current working directory.</li> </ul> Optional argument name gives the name of the test; by default, or if <tt class="docutils literal">None</tt>, <tt class="docutils literal">os.path.basename(filename)</tt> is used. Optional argument package is a Python package or the name of a Python package whose directory should be used as the base directory for a module-relative filename. If no package is specified, then the calling module’s directory is used as the base directory for module-relative filenames. It is an error to specify package if module_relative is <tt class="docutils literal">False</tt>. Optional argument globs gives a dict to be used as the globals when executing examples. A new shallow copy of this dict is created for the doctest, so its examples start with a clean slate. By default, or if <tt class="docutils literal">None</tt>, a new empty dict is used. Optional argument extraglobs gives a dict merged into the globals used to execute examples. This works like <a class="reference internal" href="stdtypes.html#dict.update" title="dict.update"><tt class="xref py py-meth docutils literal">dict.update()</tt></a>: if globs and extraglobs have a common key, the associated value in extraglobs appears in the combined dict. By default, or if <tt class="docutils literal">None</tt>, no extra globals are used. This is an advanced feature that allows parameterization of doctests. For example, a doctest can be written for a base class, using a generic name for the class, then reused to test any number of subclasses by passing an extraglobs dict mapping the generic name to the subclass to be tested. Optional argument verbose prints lots of stuff if true, and prints only failures if false; by default, or if <tt class="docutils literal">None</tt>, it’s true if and only if <tt class="docutils literal">'-v'</tt> is in <tt class="docutils literal">sys.argv</tt>. Optional argument report prints a summary at the end when true, else prints nothing at the end. In verbose mode, the summary is detailed, else the summary is very brief (in fact, empty if all tests passed). Optional argument optionflags or’s together option flags. See section <a class="reference internal" href="#doctest-options">Option Flags</a>. Optional argument raise_on_error defaults to false. If true, an exception is raised upon the first failure or unexpected exception in an example. This allows failures to be post-mortem debugged. Default behavior is to continue running examples. Optional argument parser specifies a <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> (or subclass) that should be used to extract tests from the files. It defaults to a normal parser (i.e., <tt class="docutils literal">DocTestParser()</tt>). Optional argument encoding specifies an encoding that should be used to convert the file to unicode. New in version 2.4. Changed in version 2.5: The parameter encoding was added. </dd></dl> <dl class="function"> <dt id="doctest.testmod"> <tt class="descclassname">doctest.</tt><tt class="descname">testmod</tt><big>(</big>[m][, name][, globs][, verbose][, report][, optionflags][, extraglobs][, raise_on_error][, exclude_empty]<big>)</big><a class="headerlink" href="#doctest.testmod" title="Permalink to this definition">¶</a></dt> <dd>All arguments are optional, and all except for m should be specified in keyword form. Test examples in docstrings in functions and classes reachable from module m (or module <a class="reference internal" href="__main__.html#module-__main__" title="__main__: The environment where the top-level script is run."><tt class="xref py py-mod docutils literal">__main__</tt></a> if m is not supplied or is <tt class="docutils literal">None</tt>), starting with <tt class="docutils literal">m.__doc__</tt>. Also test examples reachable from dict <tt class="docutils literal">m.__test__</tt>, if it exists and is not <tt class="docutils literal">None</tt>. <tt class="docutils literal">m.__test__</tt> maps names (strings) to functions, classes and strings; function and class docstrings are searched for examples; strings are searched directly, as if they were docstrings. Only docstrings attached to objects belonging to module m are searched. Return <tt class="docutils literal">(failure_count, test_count)</tt>. Optional argument name gives the name of the module; by default, or if <tt class="docutils literal">None</tt>, <tt class="docutils literal">m.__name__</tt> is used. Optional argument exclude_empty defaults to false. If true, objects for which no doctests are found are excluded from consideration. The default is a backward compatibility hack, so that code still using <tt class="xref py py-meth docutils literal">doctest.master.summarize()</tt> in conjunction with <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> continues to get output for objects with no tests. The exclude_empty argument to the newer <a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a> constructor defaults to true. Optional arguments extraglobs, verbose, report, optionflags, raise_on_error, and globs are the same as for function <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> above, except that globs defaults to <tt class="docutils literal">m.__dict__</tt>. Changed in version 2.3: The parameter optionflags was added. Changed in version 2.4: The parameters extraglobs, raise_on_error and exclude_empty were added. Changed in version 2.5: The optional argument isprivate, deprecated in 2.4, was removed. </dd></dl> There’s also a function to run the doctests associated with a single object. This function is provided for backward compatibility. There are no plans to deprecate it, but it’s rarely useful: <dl class="function"> <dt id="doctest.run_docstring_examples"> <tt class="descclassname">doctest.</tt><tt class="descname">run_docstring_examples</tt><big>(</big>f, globs[, verbose][, name][, compileflags][, optionflags]<big>)</big><a class="headerlink" href="#doctest.run_docstring_examples" title="Permalink to this definition">¶</a></dt> <dd>Test examples associated with object f; for example, f may be a module, function, or class object. A shallow copy of dictionary argument globs is used for the execution context. Optional argument name is used in failure messages, and defaults to <tt class="docutils literal">"NoName"</tt>. If optional argument verbose is true, output is generated even if there are no failures. By default, output is generated only in case of an example failure. Optional argument compileflags gives the set of flags that should be used by the Python compiler when running the examples. By default, or if <tt class="docutils literal">None</tt>, flags are deduced corresponding to the set of future features found in globs. Optional argument optionflags works as for function <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> above. </dd></dl> </div> <div class="section" id="unittest-api"> <h2>25.2.5. Unittest API<a class="headerlink" href="#unittest-api" title="Permalink to this headline">¶</a></h2> As your collection of doctest’ed modules grows, you’ll want a way to run all their doctests systematically. Prior to Python 2.4, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> had a barely documented <tt class="xref py py-class docutils literal">Tester</tt> class that supplied a rudimentary way to combine doctests from multiple modules. <tt class="xref py py-class docutils literal">Tester</tt> was feeble, and in practice most serious Python testing frameworks build on the <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> module, which supplies many flexible ways to combine tests from multiple sources. So, in Python 2.4, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a>‘s <tt class="xref py py-class docutils literal">Tester</tt> class is deprecated, and <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> provides two functions that can be used to create <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> test suites from modules and text files containing doctests. To integrate with <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> test discovery, include a <tt class="xref py py-func docutils literal">load_tests()</tt> function in your test module: <div class="highlight-python"><div class="highlight"><pre>import unittest import doctest import my_module_with_doctests def load_tests(loader, tests, ignore): tests.addTests(doctest.DocTestSuite(my_module_with_doctests)) return tests </pre></div> </div> There are two main functions for creating <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> instances from text files and modules with doctests: <dl class="function"> <dt id="doctest.DocFileSuite"> <tt class="descclassname">doctest.</tt><tt class="descname">DocFileSuite</tt><big>(</big>*paths, [module_relative][, package][, setUp][, tearDown][, globs][, optionflags][, parser][, encoding]<big>)</big><a class="headerlink" href="#doctest.DocFileSuite" title="Permalink to this definition">¶</a></dt> <dd>Convert doctest tests from one or more text files to a <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a>. The returned <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> is to be run by the unittest framework and runs the interactive examples in each file. If an example in any file fails, then the synthesized unit test fails, and a <tt class="xref py py-exc docutils literal">failureException</tt> exception is raised showing the name of the file containing the test and a (sometimes approximate) line number. Pass one or more paths (as strings) to text files to be examined. Options may be provided as keyword arguments: Optional argument module_relative specifies how the filenames in paths should be interpreted: <ul class="simple"> <li>If module_relative is <tt class="docutils literal">True</tt> (the default), then each filename in paths specifies an OS-independent module-relative path. By default, this path is relative to the calling module’s directory; but if the package argument is specified, then it is relative to that package. To ensure OS-independence, each filename should use <tt class="docutils literal">/</tt> characters to separate path segments, and may not be an absolute path (i.e., it may not begin with <tt class="docutils literal">/</tt>).</li> <li>If module_relative is <tt class="docutils literal">False</tt>, then each filename in paths specifies an OS-specific path. The path may be absolute or relative; relative paths are resolved with respect to the current working directory.</li> </ul> Optional argument package is a Python package or the name of a Python package whose directory should be used as the base directory for module-relative filenames in paths. If no package is specified, then the calling module’s directory is used as the base directory for module-relative filenames. It is an error to specify package if module_relative is <tt class="docutils literal">False</tt>. Optional argument setUp specifies a set-up function for the test suite. This is called before running the tests in each file. The setUp function will be passed a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object. The setUp function can access the test globals as the globs attribute of the test passed. Optional argument tearDown specifies a tear-down function for the test suite. This is called after running the tests in each file. The tearDown function will be passed a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object. The setUp function can access the test globals as the globs attribute of the test passed. Optional argument globs is a dictionary containing the initial global variables for the tests. A new copy of this dictionary is created for each test. By default, globs is a new empty dictionary. Optional argument optionflags specifies the default doctest options for the tests, created by or-ing together individual option flags. See section <a class="reference internal" href="#doctest-options">Option Flags</a>. See function <a class="reference internal" href="#doctest.set_unittest_reportflags" title="doctest.set_unittest_reportflags"><tt class="xref py py-func docutils literal">set_unittest_reportflags()</tt></a> below for a better way to set reporting options. Optional argument parser specifies a <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> (or subclass) that should be used to extract tests from the files. It defaults to a normal parser (i.e., <tt class="docutils literal">DocTestParser()</tt>). Optional argument encoding specifies an encoding that should be used to convert the file to unicode. New in version 2.4. Changed in version 2.5: The global <tt class="docutils literal">__file__</tt> was added to the globals provided to doctests loaded from a text file using <a class="reference internal" href="#doctest.DocFileSuite" title="doctest.DocFileSuite"><tt class="xref py py-func docutils literal">DocFileSuite()</tt></a>. Changed in version 2.5: The parameter encoding was added. <div class="admonition note"> Note Unlike <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a> and <a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a>, this function raises a <a class="reference internal" href="exceptions.html#exceptions.ValueError" title="exceptions.ValueError"><tt class="xref py py-exc docutils literal">ValueError</tt></a> if module contains no docstrings. You can prevent this error by passing a <a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a> instance as the test_finder argument with its exclude_empty keyword argument set to <tt class="docutils literal">False</tt>: <div class="last highlight-python"><div class="highlight"><pre>>>> finder = doctest.DocTestFinder(exclude_empty=False) >>> suite = doctest.DocTestSuite(test_finder=finder) </pre></div> </div> </div> </dd></dl> <dl class="function"> <dt id="doctest.DocTestSuite"> <tt class="descclassname">doctest.</tt><tt class="descname">DocTestSuite</tt><big>(</big>[module][, globs][, extraglobs][, test_finder][, setUp][, tearDown][, checker]<big>)</big><a class="headerlink" href="#doctest.DocTestSuite" title="Permalink to this definition">¶</a></dt> <dd>Convert doctest tests for a module to a <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a>. The returned <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> is to be run by the unittest framework and runs each doctest in the module. If any of the doctests fail, then the synthesized unit test fails, and a <tt class="xref py py-exc docutils literal">failureException</tt> exception is raised showing the name of the file containing the test and a (sometimes approximate) line number. Optional argument module provides the module to be tested. It can be a module object or a (possibly dotted) module name. If not specified, the module calling this function is used. Optional argument globs is a dictionary containing the initial global variables for the tests. A new copy of this dictionary is created for each test. By default, globs is a new empty dictionary. Optional argument extraglobs specifies an extra set of global variables, which is merged into globs. By default, no extra globals are used. Optional argument test_finder is the <a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a> object (or a drop-in replacement) that is used to extract doctests from the module. Optional arguments setUp, tearDown, and optionflags are the same as for function <a class="reference internal" href="#doctest.DocFileSuite" title="doctest.DocFileSuite"><tt class="xref py py-func docutils literal">DocFileSuite()</tt></a> above. New in version 2.3. Changed in version 2.4: The parameters globs, extraglobs, test_finder, setUp, tearDown, and optionflags were added; this function now uses the same search technique as <a class="reference internal" href="#doctest.testmod" title="doctest.testmod"><tt class="xref py py-func docutils literal">testmod()</tt></a>. </dd></dl> Under the covers, <a class="reference internal" href="#doctest.DocTestSuite" title="doctest.DocTestSuite"><tt class="xref py py-func docutils literal">DocTestSuite()</tt></a> creates a <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> out of <tt class="xref py py-class docutils literal">doctest.DocTestCase</tt> instances, and <tt class="xref py py-class docutils literal">DocTestCase</tt> is a subclass of <a class="reference internal" href="unittest.html#unittest.TestCase" title="unittest.TestCase"><tt class="xref py py-class docutils literal">unittest.TestCase</tt></a>. <tt class="xref py py-class docutils literal">DocTestCase</tt> isn’t documented here (it’s an internal detail), but studying its code can answer questions about the exact details of <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> integration. Similarly, <a class="reference internal" href="#doctest.DocFileSuite" title="doctest.DocFileSuite"><tt class="xref py py-func docutils literal">DocFileSuite()</tt></a> creates a <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> out of <tt class="xref py py-class docutils literal">doctest.DocFileCase</tt> instances, and <tt class="xref py py-class docutils literal">DocFileCase</tt> is a subclass of <tt class="xref py py-class docutils literal">DocTestCase</tt>. So both ways of creating a <a class="reference internal" href="unittest.html#unittest.TestSuite" title="unittest.TestSuite"><tt class="xref py py-class docutils literal">unittest.TestSuite</tt></a> run instances of <tt class="xref py py-class docutils literal">DocTestCase</tt>. This is important for a subtle reason: when you run <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> functions yourself, you can control the <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> options in use directly, by passing option flags to <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> functions. However, if you’re writing a <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> framework, <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> ultimately controls when and how tests get run. The framework author typically wants to control <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> reporting options (perhaps, e.g., specified by command line options), but there’s no way to pass options through <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> to <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> test runners. For this reason, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> also supports a notion of <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> reporting flags specific to <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> support, via this function: <dl class="function"> <dt id="doctest.set_unittest_reportflags"> <tt class="descclassname">doctest.</tt><tt class="descname">set_unittest_reportflags</tt><big>(</big>flags<big>)</big><a class="headerlink" href="#doctest.set_unittest_reportflags" title="Permalink to this definition">¶</a></dt> <dd>Set the <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> reporting flags to use. Argument flags or’s together option flags. See section <a class="reference internal" href="#doctest-options">Option Flags</a>. Only “reporting flags” can be used. This is a module-global setting, and affects all future doctests run by module <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a>: the <tt class="xref py py-meth docutils literal">runTest()</tt> method of <tt class="xref py py-class docutils literal">DocTestCase</tt> looks at the option flags specified for the test case when the <tt class="xref py py-class docutils literal">DocTestCase</tt> instance was constructed. If no reporting flags were specified (which is the typical and expected case), <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a>‘s <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> reporting flags are or’ed into the option flags, and the option flags so augmented are passed to the <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> instance created to run the doctest. If any reporting flags were specified when the <tt class="xref py py-class docutils literal">DocTestCase</tt> instance was constructed, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a>‘s <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> reporting flags are ignored. The value of the <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> reporting flags in effect before the function was called is returned by the function. New in version 2.4. </dd></dl> </div> <div class="section" id="advanced-api"> <h2>25.2.6. Advanced API<a class="headerlink" href="#advanced-api" title="Permalink to this headline">¶</a></h2> The basic API is a simple wrapper that’s intended to make doctest easy to use. It is fairly flexible, and should meet most users’ needs; however, if you require more fine-grained control over testing, or wish to extend doctest’s capabilities, then you should use the advanced API. The advanced API revolves around two container classes, which are used to store the interactive examples extracted from doctest cases: <ul class="simple"> <li><a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a>: A single Python <a class="reference internal" href="../glossary.html#term-statement">statement</a>, paired with its expected output.</li> <li><a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>: A collection of <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a>s, typically extracted from a single docstring or text file.</li> </ul> Additional processing classes are defined to find, parse, and run, and check doctest examples: <ul class="simple"> <li><a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a>: Finds all docstrings in a given module, and uses a <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> to create a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> from every docstring that contains interactive examples.</li> <li><a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a>: Creates a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object from a string (such as an object’s docstring).</li> <li><a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a>: Executes the examples in a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>, and uses an <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> to verify their output.</li> <li><a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a>: Compares the actual output from a doctest example with the expected output, and decides whether they match.</li> </ul> The relationships among these processing classes are summarized in the following diagram: <div class="highlight-python"><pre> list of: +------+ +---------+ |module| --DocTestFinder-> | DocTest | --DocTestRunner-> results +------+ | ^ +---------+ | ^ (printed) | | | Example | | | v | | ... | v | DocTestParser | Example | OutputChecker +---------+</pre> </div> <div class="section" id="doctest-objects"> <h3>25.2.6.1. DocTest Objects<a class="headerlink" href="#doctest-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.DocTest"> class <tt class="descclassname">doctest.</tt><tt class="descname">DocTest</tt><big>(</big>examples, globs, name, filename, lineno, docstring<big>)</big><a class="headerlink" href="#doctest.DocTest" title="Permalink to this definition">¶</a></dt> <dd>A collection of doctest examples that should be run in a single namespace. The constructor arguments are used to initialize the attributes of the same names. New in version 2.4. <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> defines the following attributes. They are initialized by the constructor, and should not be modified directly. <dl class="attribute"> <dt id="doctest.DocTest.examples"> <tt class="descname">examples</tt><a class="headerlink" href="#doctest.DocTest.examples" title="Permalink to this definition">¶</a></dt> <dd>A list of <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a> objects encoding the individual interactive Python examples that should be run by this test. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTest.globs"> <tt class="descname">globs</tt><a class="headerlink" href="#doctest.DocTest.globs" title="Permalink to this definition">¶</a></dt> <dd>The namespace (aka globals) that the examples should be run in. This is a dictionary mapping names to values. Any changes to the namespace made by the examples (such as binding new variables) will be reflected in <a class="reference internal" href="#doctest.DocTest.globs" title="doctest.DocTest.globs"><tt class="xref py py-attr docutils literal">globs</tt></a> after the test is run. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTest.name"> <tt class="descname">name</tt><a class="headerlink" href="#doctest.DocTest.name" title="Permalink to this definition">¶</a></dt> <dd>A string name identifying the <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>. Typically, this is the name of the object or file that the test was extracted from. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTest.filename"> <tt class="descname">filename</tt><a class="headerlink" href="#doctest.DocTest.filename" title="Permalink to this definition">¶</a></dt> <dd>The name of the file that this <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> was extracted from; or <tt class="docutils literal">None</tt> if the filename is unknown, or if the <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> was not extracted from a file. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTest.lineno"> <tt class="descname">lineno</tt><a class="headerlink" href="#doctest.DocTest.lineno" title="Permalink to this definition">¶</a></dt> <dd>The line number within <a class="reference internal" href="#doctest.DocTest.filename" title="doctest.DocTest.filename"><tt class="xref py py-attr docutils literal">filename</tt></a> where this <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> begins, or <tt class="docutils literal">None</tt> if the line number is unavailable. This line number is zero-based with respect to the beginning of the file. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTest.docstring"> <tt class="descname">docstring</tt><a class="headerlink" href="#doctest.DocTest.docstring" title="Permalink to this definition">¶</a></dt> <dd>The string that the test was extracted from, or ‘None’ if the string is unavailable, or if the test was not extracted from a string. </dd></dl> </dd></dl> </div> <div class="section" id="example-objects"> <h3>25.2.6.2. Example Objects<a class="headerlink" href="#example-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.Example"> class <tt class="descclassname">doctest.</tt><tt class="descname">Example</tt><big>(</big>source, want[, exc_msg][, lineno][, indent][, options]<big>)</big><a class="headerlink" href="#doctest.Example" title="Permalink to this definition">¶</a></dt> <dd>A single interactive example, consisting of a Python statement and its expected output. The constructor arguments are used to initialize the attributes of the same names. New in version 2.4. <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a> defines the following attributes. They are initialized by the constructor, and should not be modified directly. <dl class="attribute"> <dt id="doctest.Example.source"> <tt class="descname">source</tt><a class="headerlink" href="#doctest.Example.source" title="Permalink to this definition">¶</a></dt> <dd>A string containing the example’s source code. This source code consists of a single Python statement, and always ends with a newline; the constructor adds a newline when necessary. </dd></dl> <dl class="attribute"> <dt id="doctest.Example.want"> <tt class="descname">want</tt><a class="headerlink" href="#doctest.Example.want" title="Permalink to this definition">¶</a></dt> <dd>The expected output from running the example’s source code (either from stdout, or a traceback in case of exception). <a class="reference internal" href="#doctest.Example.want" title="doctest.Example.want"><tt class="xref py py-attr docutils literal">want</tt></a> ends with a newline unless no output is expected, in which case it’s an empty string. The constructor adds a newline when necessary. </dd></dl> <dl class="attribute"> <dt id="doctest.Example.exc_msg"> <tt class="descname">exc_msg</tt><a class="headerlink" href="#doctest.Example.exc_msg" title="Permalink to this definition">¶</a></dt> <dd>The exception message generated by the example, if the example is expected to generate an exception; or <tt class="docutils literal">None</tt> if it is not expected to generate an exception. This exception message is compared against the return value of <a class="reference internal" href="traceback.html#traceback.format_exception_only" title="traceback.format_exception_only"><tt class="xref py py-func docutils literal">traceback.format_exception_only()</tt></a>. <a class="reference internal" href="#doctest.Example.exc_msg" title="doctest.Example.exc_msg"><tt class="xref py py-attr docutils literal">exc_msg</tt></a> ends with a newline unless it’s <tt class="docutils literal">None</tt>. The constructor adds a newline if needed. </dd></dl> <dl class="attribute"> <dt id="doctest.Example.lineno"> <tt class="descname">lineno</tt><a class="headerlink" href="#doctest.Example.lineno" title="Permalink to this definition">¶</a></dt> <dd>The line number within the string containing this example where the example begins. This line number is zero-based with respect to the beginning of the containing string. </dd></dl> <dl class="attribute"> <dt id="doctest.Example.indent"> <tt class="descname">indent</tt><a class="headerlink" href="#doctest.Example.indent" title="Permalink to this definition">¶</a></dt> <dd>The example’s indentation in the containing string, i.e., the number of space characters that precede the example’s first prompt. </dd></dl> <dl class="attribute"> <dt id="doctest.Example.options"> <tt class="descname">options</tt><a class="headerlink" href="#doctest.Example.options" title="Permalink to this definition">¶</a></dt> <dd>A dictionary mapping from option flags to <tt class="docutils literal">True</tt> or <tt class="docutils literal">False</tt>, which is used to override default options for this example. Any option flags not contained in this dictionary are left at their default value (as specified by the <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a>‘s <tt class="xref py py-attr docutils literal">optionflags</tt>). By default, no options are set. </dd></dl> </dd></dl> </div> <div class="section" id="doctestfinder-objects"> <h3>25.2.6.3. DocTestFinder objects<a class="headerlink" href="#doctestfinder-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.DocTestFinder"> class <tt class="descclassname">doctest.</tt><tt class="descname">DocTestFinder</tt><big>(</big>[verbose][, parser][, recurse][, exclude_empty]<big>)</big><a class="headerlink" href="#doctest.DocTestFinder" title="Permalink to this definition">¶</a></dt> <dd>A processing class used to extract the <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>s that are relevant to a given object, from its docstring and the docstrings of its contained objects. <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>s can currently be extracted from the following object types: modules, functions, classes, methods, staticmethods, classmethods, and properties. The optional argument verbose can be used to display the objects searched by the finder. It defaults to <tt class="docutils literal">False</tt> (no output). The optional argument parser specifies the <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> object (or a drop-in replacement) that is used to extract doctests from docstrings. If the optional argument recurse is false, then <a class="reference internal" href="#doctest.DocTestFinder.find" title="doctest.DocTestFinder.find"><tt class="xref py py-meth docutils literal">DocTestFinder.find()</tt></a> will only examine the given object, and not any contained objects. If the optional argument exclude_empty is false, then <a class="reference internal" href="#doctest.DocTestFinder.find" title="doctest.DocTestFinder.find"><tt class="xref py py-meth docutils literal">DocTestFinder.find()</tt></a> will include tests for objects with empty docstrings. New in version 2.4. <a class="reference internal" href="#doctest.DocTestFinder" title="doctest.DocTestFinder"><tt class="xref py py-class docutils literal">DocTestFinder</tt></a> defines the following method: <dl class="method"> <dt id="doctest.DocTestFinder.find"> <tt class="descname">find</tt><big>(</big>obj[, name][, module][, globs][, extraglobs]<big>)</big><a class="headerlink" href="#doctest.DocTestFinder.find" title="Permalink to this definition">¶</a></dt> <dd>Return a list of the <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>s that are defined by obj‘s docstring, or by any of its contained objects’ docstrings. The optional argument name specifies the object’s name; this name will be used to construct names for the returned <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>s. If name is not specified, then <tt class="docutils literal">obj.__name__</tt> is used. The optional parameter module is the module that contains the given object. If the module is not specified or is None, then the test finder will attempt to automatically determine the correct module. The object’s module is used: <ul class="simple"> <li>As a default namespace, if globs is not specified.</li> <li>To prevent the DocTestFinder from extracting DocTests from objects that are imported from other modules. (Contained objects with modules other than module are ignored.)</li> <li>To find the name of the file containing the object.</li> <li>To help find the line number of the object within its file.</li> </ul> If module is <tt class="docutils literal">False</tt>, no attempt to find the module will be made. This is obscure, of use mostly in testing doctest itself: if module is <tt class="docutils literal">False</tt>, or is <tt class="docutils literal">None</tt> but cannot be found automatically, then all objects are considered to belong to the (non-existent) module, so all contained objects will (recursively) be searched for doctests. The globals for each <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> is formed by combining globs and extraglobs (bindings in extraglobs override bindings in globs). A new shallow copy of the globals dictionary is created for each <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>. If globs is not specified, then it defaults to the module’s __dict__, if specified, or <tt class="docutils literal">{}</tt> otherwise. If extraglobs is not specified, then it defaults to <tt class="docutils literal">{}</tt>. </dd></dl> </dd></dl> </div> <div class="section" id="doctestparser-objects"> <h3>25.2.6.4. DocTestParser objects<a class="headerlink" href="#doctestparser-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.DocTestParser"> class <tt class="descclassname">doctest.</tt><tt class="descname">DocTestParser</tt><a class="headerlink" href="#doctest.DocTestParser" title="Permalink to this definition">¶</a></dt> <dd>A processing class used to extract interactive examples from a string, and use them to create a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object. New in version 2.4. <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> defines the following methods: <dl class="method"> <dt id="doctest.DocTestParser.get_doctest"> <tt class="descname">get_doctest</tt><big>(</big>string, globs, name, filename, lineno<big>)</big><a class="headerlink" href="#doctest.DocTestParser.get_doctest" title="Permalink to this definition">¶</a></dt> <dd>Extract all doctest examples from the given string, and collect them into a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object. globs, name, filename, and lineno are attributes for the new <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object. See the documentation for <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> for more information. </dd></dl> <dl class="method"> <dt id="doctest.DocTestParser.get_examples"> <tt class="descname">get_examples</tt><big>(</big>string[, name]<big>)</big><a class="headerlink" href="#doctest.DocTestParser.get_examples" title="Permalink to this definition">¶</a></dt> <dd>Extract all doctest examples from the given string, and return them as a list of <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a> objects. Line numbers are 0-based. The optional argument name is a name identifying this string, and is only used for error messages. </dd></dl> <dl class="method"> <dt id="doctest.DocTestParser.parse"> <tt class="descname">parse</tt><big>(</big>string[, name]<big>)</big><a class="headerlink" href="#doctest.DocTestParser.parse" title="Permalink to this definition">¶</a></dt> <dd>Divide the given string into examples and intervening text, and return them as a list of alternating <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a>s and strings. Line numbers for the <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a>s are 0-based. The optional argument name is a name identifying this string, and is only used for error messages. </dd></dl> </dd></dl> </div> <div class="section" id="doctestrunner-objects"> <h3>25.2.6.5. DocTestRunner objects<a class="headerlink" href="#doctestrunner-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.DocTestRunner"> class <tt class="descclassname">doctest.</tt><tt class="descname">DocTestRunner</tt><big>(</big>[checker][, verbose][, optionflags]<big>)</big><a class="headerlink" href="#doctest.DocTestRunner" title="Permalink to this definition">¶</a></dt> <dd>A processing class used to execute and verify the interactive examples in a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a>. The comparison between expected outputs and actual outputs is done by an <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a>. This comparison may be customized with a number of option flags; see section <a class="reference internal" href="#doctest-options">Option Flags</a> for more information. If the option flags are insufficient, then the comparison may also be customized by passing a subclass of <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> to the constructor. The test runner’s display output can be controlled in two ways. First, an output function can be passed to <tt class="xref py py-meth docutils literal">TestRunner.run()</tt>; this function will be called with strings that should be displayed. It defaults to <tt class="docutils literal">sys.stdout.write</tt>. If capturing the output is not sufficient, then the display output can be also customized by subclassing DocTestRunner, and overriding the methods <a class="reference internal" href="#doctest.DocTestRunner.report_start" title="doctest.DocTestRunner.report_start"><tt class="xref py py-meth docutils literal">report_start()</tt></a>, <a class="reference internal" href="#doctest.DocTestRunner.report_success" title="doctest.DocTestRunner.report_success"><tt class="xref py py-meth docutils literal">report_success()</tt></a>, <a class="reference internal" href="#doctest.DocTestRunner.report_unexpected_exception" title="doctest.DocTestRunner.report_unexpected_exception"><tt class="xref py py-meth docutils literal">report_unexpected_exception()</tt></a>, and <a class="reference internal" href="#doctest.DocTestRunner.report_failure" title="doctest.DocTestRunner.report_failure"><tt class="xref py py-meth docutils literal">report_failure()</tt></a>. The optional keyword argument checker specifies the <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> object (or drop-in replacement) that should be used to compare the expected outputs to the actual outputs of doctest examples. The optional keyword argument verbose controls the <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a>‘s verbosity. If verbose is <tt class="docutils literal">True</tt>, then information is printed about each example, as it is run. If verbose is <tt class="docutils literal">False</tt>, then only failures are printed. If verbose is unspecified, or <tt class="docutils literal">None</tt>, then verbose output is used iff the command-line switch <tt class="docutils literal">-v</tt> is used. The optional keyword argument optionflags can be used to control how the test runner compares expected output to actual output, and how it displays failures. For more information, see section <a class="reference internal" href="#doctest-options">Option Flags</a>. New in version 2.4. <a class="reference internal" href="#doctest.DocTestParser" title="doctest.DocTestParser"><tt class="xref py py-class docutils literal">DocTestParser</tt></a> defines the following methods: <dl class="method"> <dt id="doctest.DocTestRunner.report_start"> <tt class="descname">report_start</tt><big>(</big>out, test, example<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.report_start" title="Permalink to this definition">¶</a></dt> <dd>Report that the test runner is about to process the given example. This method is provided to allow subclasses of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to customize their output; it should not be called directly. example is the example about to be processed. test is the test containing example. out is the output function that was passed to <a class="reference internal" href="#doctest.DocTestRunner.run" title="doctest.DocTestRunner.run"><tt class="xref py py-meth docutils literal">DocTestRunner.run()</tt></a>. </dd></dl> <dl class="method"> <dt id="doctest.DocTestRunner.report_success"> <tt class="descname">report_success</tt><big>(</big>out, test, example, got<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.report_success" title="Permalink to this definition">¶</a></dt> <dd>Report that the given example ran successfully. This method is provided to allow subclasses of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to customize their output; it should not be called directly. example is the example about to be processed. got is the actual output from the example. test is the test containing example. out is the output function that was passed to <a class="reference internal" href="#doctest.DocTestRunner.run" title="doctest.DocTestRunner.run"><tt class="xref py py-meth docutils literal">DocTestRunner.run()</tt></a>. </dd></dl> <dl class="method"> <dt id="doctest.DocTestRunner.report_failure"> <tt class="descname">report_failure</tt><big>(</big>out, test, example, got<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.report_failure" title="Permalink to this definition">¶</a></dt> <dd>Report that the given example failed. This method is provided to allow subclasses of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to customize their output; it should not be called directly. example is the example about to be processed. got is the actual output from the example. test is the test containing example. out is the output function that was passed to <a class="reference internal" href="#doctest.DocTestRunner.run" title="doctest.DocTestRunner.run"><tt class="xref py py-meth docutils literal">DocTestRunner.run()</tt></a>. </dd></dl> <dl class="method"> <dt id="doctest.DocTestRunner.report_unexpected_exception"> <tt class="descname">report_unexpected_exception</tt><big>(</big>out, test, example, exc_info<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.report_unexpected_exception" title="Permalink to this definition">¶</a></dt> <dd>Report that the given example raised an unexpected exception. This method is provided to allow subclasses of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to customize their output; it should not be called directly. example is the example about to be processed. exc_info is a tuple containing information about the unexpected exception (as returned by <a class="reference internal" href="sys.html#sys.exc_info" title="sys.exc_info"><tt class="xref py py-func docutils literal">sys.exc_info()</tt></a>). test is the test containing example. out is the output function that was passed to <a class="reference internal" href="#doctest.DocTestRunner.run" title="doctest.DocTestRunner.run"><tt class="xref py py-meth docutils literal">DocTestRunner.run()</tt></a>. </dd></dl> <dl class="method"> <dt id="doctest.DocTestRunner.run"> <tt class="descname">run</tt><big>(</big>test[, compileflags][, out][, clear_globs]<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.run" title="Permalink to this definition">¶</a></dt> <dd>Run the examples in test (a <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object), and display the results using the writer function out. The examples are run in the namespace <tt class="docutils literal">test.globs</tt>. If clear_globs is true (the default), then this namespace will be cleared after the test runs, to help with garbage collection. If you would like to examine the namespace after the test completes, then use clear_globs=False. compileflags gives the set of flags that should be used by the Python compiler when running the examples. If not specified, then it will default to the set of future-import flags that apply to globs. The output of each example is checked using the <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a>‘s output checker, and the results are formatted by the <tt class="xref py py-meth docutils literal">DocTestRunner.report_*()</tt> methods. </dd></dl> <dl class="method"> <dt id="doctest.DocTestRunner.summarize"> <tt class="descname">summarize</tt><big>(</big>[verbose]<big>)</big><a class="headerlink" href="#doctest.DocTestRunner.summarize" title="Permalink to this definition">¶</a></dt> <dd>Print a summary of all the test cases that have been run by this DocTestRunner, and return a <a class="reference internal" href="../glossary.html#term-named-tuple">named tuple</a> <tt class="docutils literal">TestResults(failed, attempted)</tt>. The optional verbose argument controls how detailed the summary is. If the verbosity is not specified, then the <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a>‘s verbosity is used. Changed in version 2.6: Use a named tuple. </dd></dl> </dd></dl> </div> <div class="section" id="outputchecker-objects"> <h3>25.2.6.6. OutputChecker objects<a class="headerlink" href="#outputchecker-objects" title="Permalink to this headline">¶</a></h3> <dl class="class"> <dt id="doctest.OutputChecker"> class <tt class="descclassname">doctest.</tt><tt class="descname">OutputChecker</tt><a class="headerlink" href="#doctest.OutputChecker" title="Permalink to this definition">¶</a></dt> <dd>A class used to check the whether the actual output from a doctest example matches the expected output. <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> defines two methods: <a class="reference internal" href="#doctest.OutputChecker.check_output" title="doctest.OutputChecker.check_output"><tt class="xref py py-meth docutils literal">check_output()</tt></a>, which compares a given pair of outputs, and returns true if they match; and <a class="reference internal" href="#doctest.OutputChecker.output_difference" title="doctest.OutputChecker.output_difference"><tt class="xref py py-meth docutils literal">output_difference()</tt></a>, which returns a string describing the differences between two outputs. New in version 2.4. <a class="reference internal" href="#doctest.OutputChecker" title="doctest.OutputChecker"><tt class="xref py py-class docutils literal">OutputChecker</tt></a> defines the following methods: <dl class="method"> <dt id="doctest.OutputChecker.check_output"> <tt class="descname">check_output</tt><big>(</big>want, got, optionflags<big>)</big><a class="headerlink" href="#doctest.OutputChecker.check_output" title="Permalink to this definition">¶</a></dt> <dd>Return <tt class="docutils literal">True</tt> iff the actual output from an example (got) matches the expected output (want). These strings are always considered to match if they are identical; but depending on what option flags the test runner is using, several non-exact match types are also possible. See section <a class="reference internal" href="#doctest-options">Option Flags</a> for more information about option flags. </dd></dl> <dl class="method"> <dt id="doctest.OutputChecker.output_difference"> <tt class="descname">output_difference</tt><big>(</big>example, got, optionflags<big>)</big><a class="headerlink" href="#doctest.OutputChecker.output_difference" title="Permalink to this definition">¶</a></dt> <dd>Return a string describing the differences between the expected output for a given example (example) and the actual output (got). optionflags is the set of option flags used to compare want and got. </dd></dl> </dd></dl> </div> </div> <div class="section" id="debugging"> <h2>25.2.7. Debugging<a class="headerlink" href="#debugging" title="Permalink to this headline">¶</a></h2> Doctest provides several mechanisms for debugging doctest examples: <ul> <li>Several functions convert doctests to executable Python programs, which can be run under the Python debugger, <a class="reference internal" href="pdb.html#module-pdb" title="pdb: The Python debugger for interactive interpreters."><tt class="xref py py-mod docutils literal">pdb</tt></a>. </li> <li>The <a class="reference internal" href="#doctest.DebugRunner" title="doctest.DebugRunner"><tt class="xref py py-class docutils literal">DebugRunner</tt></a> class is a subclass of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> that raises an exception for the first failing example, containing information about that example. This information can be used to perform post-mortem debugging on the example. </li> <li>The <a class="reference internal" href="unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><tt class="xref py py-mod docutils literal">unittest</tt></a> cases generated by <a class="reference internal" href="#doctest.DocTestSuite" title="doctest.DocTestSuite"><tt class="xref py py-func docutils literal">DocTestSuite()</tt></a> support the <a class="reference internal" href="#doctest.debug" title="doctest.debug"><tt class="xref py py-meth docutils literal">debug()</tt></a> method defined by <a class="reference internal" href="unittest.html#unittest.TestCase" title="unittest.TestCase"><tt class="xref py py-class docutils literal">unittest.TestCase</tt></a>. </li> <li>You can add a call to <a class="reference internal" href="pdb.html#pdb.set_trace" title="pdb.set_trace"><tt class="xref py py-func docutils literal">pdb.set_trace()</tt></a> in a doctest example, and you’ll drop into the Python debugger when that line is executed. Then you can inspect current values of variables, and so on. For example, suppose <tt class="file docutils literal">a.py</tt> contains just this module docstring: <div class="highlight-python"><div class="highlight"><pre>""" >>> def f(x): ... g(x*2) >>> def g(x): ... print x+3 ... import pdb; pdb.set_trace() >>> f(3) 9 """ </pre></div> </div> Then an interactive Python session may look like this: <div class="highlight-python"><div class="highlight"><pre>>>> import a, doctest >>> doctest.testmod(a) --Return-- > <doctest a[1]>(3)g()->None -> import pdb; pdb.set_trace() (Pdb) list 1 def g(x): 2 print x+3 3 -> import pdb; pdb.set_trace() [EOF] (Pdb) print x 6 (Pdb) step --Return-- > <doctest a[0]>(2)f()->None -> g(x*2) (Pdb) list 1 def f(x): 2 -> g(x*2) [EOF] (Pdb) print x 3 (Pdb) step --Return-- > <doctest a[2]>(1)?()->None -> f(3) (Pdb) cont (0, 3) >>> </pre></div> </div> Changed in version 2.4: The ability to use <a class="reference internal" href="pdb.html#pdb.set_trace" title="pdb.set_trace"><tt class="xref py py-func docutils literal">pdb.set_trace()</tt></a> usefully inside doctests was added. </li> </ul> Functions that convert doctests to Python code, and possibly run the synthesized code under the debugger: <dl class="function"> <dt id="doctest.script_from_examples"> <tt class="descclassname">doctest.</tt><tt class="descname">script_from_examples</tt><big>(</big>s<big>)</big><a class="headerlink" href="#doctest.script_from_examples" title="Permalink to this definition">¶</a></dt> <dd>Convert text with examples to a script. Argument s is a string containing doctest examples. The string is converted to a Python script, where doctest examples in s are converted to regular code, and everything else is converted to Python comments. The generated script is returned as a string. For example, <div class="highlight-python"><div class="highlight"><pre>import doctest print doctest.script_from_examples(r""" Set x and y to 1 and 2. >>> x, y = 1, 2 Print their sum: >>> print x+y 3 """) </pre></div> </div> displays: <div class="highlight-python"><div class="highlight"><pre># Set x and y to 1 and 2. x, y = 1, 2 # # Print their sum: print x+y # Expected: ## 3 </pre></div> </div> This function is used internally by other functions (see below), but can also be useful when you want to transform an interactive Python session into a Python script. New in version 2.4. </dd></dl> <dl class="function"> <dt id="doctest.testsource"> <tt class="descclassname">doctest.</tt><tt class="descname">testsource</tt><big>(</big>module, name<big>)</big><a class="headerlink" href="#doctest.testsource" title="Permalink to this definition">¶</a></dt> <dd>Convert the doctest for an object to a script. Argument module is a module object, or dotted name of a module, containing the object whose doctests are of interest. Argument name is the name (within the module) of the object with the doctests of interest. The result is a string, containing the object’s docstring converted to a Python script, as described for <a class="reference internal" href="#doctest.script_from_examples" title="doctest.script_from_examples"><tt class="xref py py-func docutils literal">script_from_examples()</tt></a> above. For example, if module <tt class="file docutils literal">a.py</tt> contains a top-level function <tt class="xref py py-func docutils literal">f()</tt>, then <div class="highlight-python"><div class="highlight"><pre>import a, doctest print doctest.testsource(a, "a.f") </pre></div> </div> prints a script version of function <tt class="xref py py-func docutils literal">f()</tt>‘s docstring, with doctests converted to code, and the rest placed in comments. New in version 2.3. </dd></dl> <dl class="function"> <dt id="doctest.debug"> <tt class="descclassname">doctest.</tt><tt class="descname">debug</tt><big>(</big>module, name[, pm]<big>)</big><a class="headerlink" href="#doctest.debug" title="Permalink to this definition">¶</a></dt> <dd>Debug the doctests for an object. The module and name arguments are the same as for function <a class="reference internal" href="#doctest.testsource" title="doctest.testsource"><tt class="xref py py-func docutils literal">testsource()</tt></a> above. The synthesized Python script for the named object’s docstring is written to a temporary file, and then that file is run under the control of the Python debugger, <a class="reference internal" href="pdb.html#module-pdb" title="pdb: The Python debugger for interactive interpreters."><tt class="xref py py-mod docutils literal">pdb</tt></a>. A shallow copy of <tt class="docutils literal">module.__dict__</tt> is used for both local and global execution context. Optional argument pm controls whether post-mortem debugging is used. If pm has a true value, the script file is run directly, and the debugger gets involved only if the script terminates via raising an unhandled exception. If it does, then post-mortem debugging is invoked, via <a class="reference internal" href="pdb.html#pdb.post_mortem" title="pdb.post_mortem"><tt class="xref py py-func docutils literal">pdb.post_mortem()</tt></a>, passing the traceback object from the unhandled exception. If pm is not specified, or is false, the script is run under the debugger from the start, via passing an appropriate <a class="reference internal" href="functions.html#execfile" title="execfile"><tt class="xref py py-func docutils literal">execfile()</tt></a> call to <a class="reference internal" href="pdb.html#pdb.run" title="pdb.run"><tt class="xref py py-func docutils literal">pdb.run()</tt></a>. New in version 2.3. Changed in version 2.4: The pm argument was added. </dd></dl> <dl class="function"> <dt id="doctest.debug_src"> <tt class="descclassname">doctest.</tt><tt class="descname">debug_src</tt><big>(</big>src[, pm][, globs]<big>)</big><a class="headerlink" href="#doctest.debug_src" title="Permalink to this definition">¶</a></dt> <dd>Debug the doctests in a string. This is like function <a class="reference internal" href="#doctest.debug" title="doctest.debug"><tt class="xref py py-func docutils literal">debug()</tt></a> above, except that a string containing doctest examples is specified directly, via the src argument. Optional argument pm has the same meaning as in function <a class="reference internal" href="#doctest.debug" title="doctest.debug"><tt class="xref py py-func docutils literal">debug()</tt></a> above. Optional argument globs gives a dictionary to use as both local and global execution context. If not specified, or <tt class="docutils literal">None</tt>, an empty dictionary is used. If specified, a shallow copy of the dictionary is used. New in version 2.4. </dd></dl> The <a class="reference internal" href="#doctest.DebugRunner" title="doctest.DebugRunner"><tt class="xref py py-class docutils literal">DebugRunner</tt></a> class, and the special exceptions it may raise, are of most interest to testing framework authors, and will only be sketched here. See the source code, and especially <a class="reference internal" href="#doctest.DebugRunner" title="doctest.DebugRunner"><tt class="xref py py-class docutils literal">DebugRunner</tt></a>‘s docstring (which is a doctest!) for more details: <dl class="class"> <dt id="doctest.DebugRunner"> class <tt class="descclassname">doctest.</tt><tt class="descname">DebugRunner</tt><big>(</big>[checker][, verbose][, optionflags]<big>)</big><a class="headerlink" href="#doctest.DebugRunner" title="Permalink to this definition">¶</a></dt> <dd>A subclass of <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> that raises an exception as soon as a failure is encountered. If an unexpected exception occurs, an <a class="reference internal" href="#doctest.UnexpectedException" title="doctest.UnexpectedException"><tt class="xref py py-exc docutils literal">UnexpectedException</tt></a> exception is raised, containing the test, the example, and the original exception. If the output doesn’t match, then a <a class="reference internal" href="#doctest.DocTestFailure" title="doctest.DocTestFailure"><tt class="xref py py-exc docutils literal">DocTestFailure</tt></a> exception is raised, containing the test, the example, and the actual output. For information about the constructor parameters and methods, see the documentation for <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> in section <a class="reference internal" href="#doctest-advanced-api">Advanced API</a>. </dd></dl> There are two exceptions that may be raised by <a class="reference internal" href="#doctest.DebugRunner" title="doctest.DebugRunner"><tt class="xref py py-class docutils literal">DebugRunner</tt></a> instances: <dl class="exception"> <dt id="doctest.DocTestFailure"> exception <tt class="descclassname">doctest.</tt><tt class="descname">DocTestFailure</tt><big>(</big>test, example, got<big>)</big><a class="headerlink" href="#doctest.DocTestFailure" title="Permalink to this definition">¶</a></dt> <dd>An exception raised by <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to signal that a doctest example’s actual output did not match its expected output. The constructor arguments are used to initialize the attributes of the same names. </dd></dl> <a class="reference internal" href="#doctest.DocTestFailure" title="doctest.DocTestFailure"><tt class="xref py py-exc docutils literal">DocTestFailure</tt></a> defines the following attributes: <dl class="attribute"> <dt id="doctest.DocTestFailure.test"> <tt class="descclassname">DocTestFailure.</tt><tt class="descname">test</tt><a class="headerlink" href="#doctest.DocTestFailure.test" title="Permalink to this definition">¶</a></dt> <dd>The <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object that was being run when the example failed. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTestFailure.example"> <tt class="descclassname">DocTestFailure.</tt><tt class="descname">example</tt><a class="headerlink" href="#doctest.DocTestFailure.example" title="Permalink to this definition">¶</a></dt> <dd>The <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a> that failed. </dd></dl> <dl class="attribute"> <dt id="doctest.DocTestFailure.got"> <tt class="descclassname">DocTestFailure.</tt><tt class="descname">got</tt><a class="headerlink" href="#doctest.DocTestFailure.got" title="Permalink to this definition">¶</a></dt> <dd>The example’s actual output. </dd></dl> <dl class="exception"> <dt id="doctest.UnexpectedException"> exception <tt class="descclassname">doctest.</tt><tt class="descname">UnexpectedException</tt><big>(</big>test, example, exc_info<big>)</big><a class="headerlink" href="#doctest.UnexpectedException" title="Permalink to this definition">¶</a></dt> <dd>An exception raised by <a class="reference internal" href="#doctest.DocTestRunner" title="doctest.DocTestRunner"><tt class="xref py py-class docutils literal">DocTestRunner</tt></a> to signal that a doctest example raised an unexpected exception. The constructor arguments are used to initialize the attributes of the same names. </dd></dl> <a class="reference internal" href="#doctest.UnexpectedException" title="doctest.UnexpectedException"><tt class="xref py py-exc docutils literal">UnexpectedException</tt></a> defines the following attributes: <dl class="attribute"> <dt id="doctest.UnexpectedException.test"> <tt class="descclassname">UnexpectedException.</tt><tt class="descname">test</tt><a class="headerlink" href="#doctest.UnexpectedException.test" title="Permalink to this definition">¶</a></dt> <dd>The <a class="reference internal" href="#doctest.DocTest" title="doctest.DocTest"><tt class="xref py py-class docutils literal">DocTest</tt></a> object that was being run when the example failed. </dd></dl> <dl class="attribute"> <dt id="doctest.UnexpectedException.example"> <tt class="descclassname">UnexpectedException.</tt><tt class="descname">example</tt><a class="headerlink" href="#doctest.UnexpectedException.example" title="Permalink to this definition">¶</a></dt> <dd>The <a class="reference internal" href="#doctest.Example" title="doctest.Example"><tt class="xref py py-class docutils literal">Example</tt></a> that failed. </dd></dl> <dl class="attribute"> <dt id="doctest.UnexpectedException.exc_info"> <tt class="descclassname">UnexpectedException.</tt><tt class="descname">exc_info</tt><a class="headerlink" href="#doctest.UnexpectedException.exc_info" title="Permalink to this definition">¶</a></dt> <dd>A tuple containing information about the unexpected exception, as returned by <a class="reference internal" href="sys.html#sys.exc_info" title="sys.exc_info"><tt class="xref py py-func docutils literal">sys.exc_info()</tt></a>. </dd></dl> </div> <div class="section" id="soapbox"> <h2>25.2.8. Soapbox<a class="headerlink" href="#soapbox" title="Permalink to this headline">¶</a></h2> As mentioned in the introduction, <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> has grown to have three primary uses: <ol class="arabic simple"> <li>Checking examples in docstrings.</li> <li>Regression testing.</li> <li>Executable documentation / literate testing.</li> </ol> These uses have different requirements, and it is important to distinguish them. In particular, filling your docstrings with obscure test cases makes for bad documentation. When writing a docstring, choose docstring examples with care. There’s an art to this that needs to be learned—it may not be natural at first. Examples should add genuine value to the documentation. A good example can often be worth many words. If done with care, the examples will be invaluable for your users, and will pay back the time it takes to collect them many times over as the years go by and things change. I’m still amazed at how often one of my <a class="reference internal" href="#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal">doctest</tt></a> examples stops working after a “harmless” change. Doctest also makes an excellent tool for regression testing, especially if you don’t skimp on explanatory text. By interleaving prose and examples, it becomes much easier to keep track of what’s actually being tested, and why. When a test fails, good prose can make it much easier to figure out what the problem is, and how it should be fixed. It’s true that you could write extensive comments in code-based testing, but few programmers do. Many have found that using doctest approaches instead leads to much clearer tests. Perhaps this is simply because doctest makes writing prose a little easier than writing code, while writing comments in code is a little harder. I think it goes deeper than just that: the natural attitude when writing a doctest-based test is that you want to explain the fine points of your software, and illustrate them with examples. This in turn naturally leads to test files that start with the simplest features, and logically progress to complications and edge cases. A coherent narrative is the result, instead of a collection of isolated functions that test isolated bits of functionality seemingly at random. It’s a different attitude, and produces different results, blurring the distinction between testing and explaining. Regression testing is best confined to dedicated objects or files. There are several options for organizing tests: <ul class="simple"> <li>Write text files containing test cases as interactive examples, and test the files using <a class="reference internal" href="#doctest.testfile" title="doctest.testfile"><tt class="xref py py-func docutils literal">testfile()</tt></a> or <a class="reference internal" href="#doctest.DocFileSuite" title="doctest.DocFileSuite"><tt class="xref py py-func docutils literal">DocFileSuite()</tt></a>. This is recommended, although is easiest to do for new projects, designed from the start to use doctest.</li> <li>Define functions named <tt class="docutils literal">_regrtest_topic</tt> that consist of single docstrings, containing test cases for the named topics. These functions can be included in the same file as the module, or separated out into a separate test file.</li> <li>Define a <tt class="docutils literal">__test__</tt> dictionary mapping from regression test topics to docstrings containing test cases.</li> </ul> Footnotes <table class="docutils footnote" frame="void" id="id2" rules="none"> <colgroup><col class="label" /><col /></colgroup> <tbody valign="top"> <tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>Examples containing both expected output and an exception are not supported. Trying to guess where one ends and the other begins is too error-prone, and that also makes for a confusing test.</td></tr> </tbody> </table> </div> </div> </div> </div> </div> <div class="sphinxsidebar"> <div class="sphinxsidebarwrapper"> <h3><a href="../contents.html">Table Of Contents</a></h3> <ul> <li><a class="reference internal" href="#">25.2. <tt class="docutils literal">doctest</tt> — Test interactive Python examples</a><ul> <li><a class="reference internal" href="#simple-usage-checking-examples-in-docstrings">25.2.1. Simple Usage: Checking Examples in Docstrings</a></li> <li><a class="reference internal" href="#simple-usage-checking-examples-in-a-text-file">25.2.2. Simple Usage: Checking Examples in a Text File</a></li> <li><a class="reference internal" href="#how-it-works">25.2.3. How It Works</a><ul> <li><a class="reference internal" href="#which-docstrings-are-examined">25.2.3.1. Which Docstrings Are Examined?</a></li> <li><a class="reference internal" href="#how-are-docstring-examples-recognized">25.2.3.2. How are Docstring Examples Recognized?</a></li> <li><a class="reference internal" href="#what-s-the-execution-context">25.2.3.3. What’s the Execution Context?</a></li> <li><a class="reference internal" href="#what-about-exceptions">25.2.3.4. What About Exceptions?</a></li> <li><a class="reference internal" href="#option-flags">25.2.3.5. Option Flags</a></li> <li><a class="reference internal" href="#directives">25.2.3.6. Directives</a></li> <li><a class="reference internal" href="#warnings">25.2.3.7. Warnings</a></li> </ul> </li> <li><a class="reference internal" href="#basic-api">25.2.4. Basic API</a></li> <li><a class="reference internal" href="#unittest-api">25.2.5. Unittest API</a></li> <li><a class="reference internal" href="#advanced-api">25.2.6. Advanced API</a><ul> <li><a class="reference internal" href="#doctest-objects">25.2.6.1. DocTest Objects</a></li> <li><a class="reference internal" href="#example-objects">25.2.6.2. Example Objects</a></li> <li><a class="reference internal" href="#doctestfinder-objects">25.2.6.3. DocTestFinder objects</a></li> <li><a class="reference internal" href="#doctestparser-objects">25.2.6.4. DocTestParser objects</a></li> <li><a class="reference internal" href="#doctestrunner-objects">25.2.6.5. DocTestRunner objects</a></li> <li><a class="reference internal" href="#outputchecker-objects">25.2.6.6. OutputChecker objects</a></li> </ul> </li> <li><a class="reference internal" href="#debugging">25.2.7. Debugging</a></li> <li><a class="reference internal" href="#soapbox">25.2.8. Soapbox</a></li> </ul> </li> </ul> <h4>Previous topic</h4> <a href="pydoc.html" title="previous chapter">25.1. <tt class="docutils literal">pydoc</tt> — Documentation generator and online help system</a> <h4>Next topic</h4> <a href="unittest.html" title="next chapter">25.3. <tt class="docutils literal">unittest</tt> — Unit testing framework</a> <h3>This Page</h3> <ul class="this-page-menu"> <li><a href="../bugs.html">Report a Bug</a></li> <li><a href="../_sources/library/doctest.txt" rel="nofollow">Show Source</a></li> </ul> <div id="searchbox" style="display: none"> <h3>Quick search</h3> <form class="search" action="../search.html" method="get"> <input type="text" name="q" /> <input type="submit" value="Go" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> Enter search terms or a module, class or function name. </div> <script type="text/javascript">$('#searchbox').show(0);</script> </div> </div> <div class="clearer"></div> </div> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="../genindex.html" title="General Index" >index</a></li> <li class="right" > <a href="../py-modindex.html" title="Python Module Index" >modules</a> |</li> <li class="right" > <a href="unittest.html" title="25.3. unittest — Unit testing framework" >next</a> |</li> <li class="right" > <a href="pydoc.html" title="25.1. pydoc — Documentation generator and online help system" >previous</a> |</li> <li><img src="../_static/py.png" alt="" style="vertical-align: middle; margin-top: -1px"/></li> <li><a href="http://www.python.org/">Python</a> »</li> <li> <a href="../index.html">Python 2.7.5 documentation</a> » </li> <li><a href="index.html" >The Python Standard Library</a> »</li> <li><a href="development.html" >25. Development Tools</a> »</li> </ul> </div> <div class="footer"> © <a href="../copyright.html">Copyright</a> 1990-2019, Python Software Foundation. The Python Software Foundation is a non-profit corporation. <a href="http://www.python.org/psf/donations/">Please donate.</a> Last updated on Jul 03, 2019. <a href="../bugs.html">Found a bug</a>? Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3. </div> </body> </html>

N4m3	5!z3	L45t M0d!f!3d	0wn3r / Gr0up	P3Rm!55!0n5	0pt!0n5
..	--	October 23 2020 09:20:37	root / root	0755

2to3.html	49.274 KB	July 03 2019 16:47:49	root / root	0644
__builtin__.html	10.261 KB	July 03 2019 16:47:49	root / root	0644
__future__.html	13.794 KB	July 03 2019 16:47:49	root / root	0644
__main__.html	7.055 KB	July 03 2019 16:47:49	root / root	0644
_winreg.html	59.208 KB	July 03 2019 16:47:49	root / root	0644
abc.html	23.898 KB	July 03 2019 16:47:50	root / root	0644
aepack.html	13.16 KB	July 03 2019 16:47:50	root / root	0644
aetools.html	14.914 KB	July 03 2019 16:47:50	root / root	0644
aetypes.html	18.882 KB	July 03 2019 16:47:50	root / root	0644
aifc.html	22.404 KB	July 03 2019 16:47:50	root / root	0644
al.html	17.341 KB	July 03 2019 16:47:50	root / root	0644
allos.html	33.725 KB	July 03 2019 16:47:50	root / root	0644
anydbm.html	16.33 KB	July 03 2019 16:47:50	root / root	0644
archiving.html	9.263 KB	July 03 2019 16:47:50	root / root	0644
argparse.html	237.615 KB	July 03 2019 16:47:50	root / root	0644
array.html	29.295 KB	July 03 2019 16:47:50	root / root	0644
ast.html	34.98 KB	July 03 2019 16:47:51	root / root	0644
asynchat.html	31.434 KB	July 03 2019 16:47:51	root / root	0644
asyncore.html	36.513 KB	July 03 2019 16:47:51	root / root	0644
atexit.html	16.803 KB	July 03 2019 16:47:51	root / root	0644
audioop.html	31.356 KB	July 03 2019 16:47:51	root / root	0644
autogil.html	8.186 KB	July 03 2019 16:47:51	root / root	0644
base64.html	19.669 KB	July 03 2019 16:47:51	root / root	0644
basehttpserver.html	34.039 KB	July 03 2019 16:47:51	root / root	0644
bastion.html	11.04 KB	July 03 2019 16:47:51	root / root	0644
bdb.html	36.682 KB	July 03 2019 16:47:51	root / root	0644
binascii.html	20.665 KB	July 03 2019 16:47:51	root / root	0644
binhex.html	10.577 KB	July 03 2019 16:47:51	root / root	0644
bisect.html	23.236 KB	July 03 2019 16:47:51	root / root	0644
bsddb.html	26.433 KB	July 03 2019 16:47:51	root / root	0644
bz2.html	26.082 KB	July 03 2019 16:47:51	root / root	0644
calendar.html	37.788 KB	July 03 2019 16:47:51	root / root	0644
carbon.html	48.944 KB	July 03 2019 16:47:51	root / root	0644
cd.html	27.96 KB	July 03 2019 16:47:52	root / root	0644
cgi.html	49.924 KB	July 03 2019 16:47:52	root / root	0644
cgihttpserver.html	13.099 KB	July 03 2019 16:47:52	root / root	0644
cgitb.html	11.411 KB	July 03 2019 16:47:52	root / root	0644
chunk.html	14.664 KB	July 03 2019 16:47:52	root / root	0644
cmath.html	25.632 KB	July 03 2019 16:47:52	root / root	0644
cmd.html	26.095 KB	July 03 2019 16:47:52	root / root	0644
code.html	24.577 KB	July 03 2019 16:47:52	root / root	0644
codecs.html	100.638 KB	July 03 2019 16:47:52	root / root	0644
codeop.html	14.841 KB	July 03 2019 16:47:52	root / root	0644
collections.html	133.964 KB	July 03 2019 16:47:53	root / root	0644
colorpicker.html	7.523 KB	July 03 2019 16:47:53	root / root	0644
colorsys.html	11.037 KB	July 03 2019 16:47:53	root / root	0644
commands.html	14.361 KB	July 03 2019 16:47:53	root / root	0644
compileall.html	16.827 KB	July 03 2019 16:47:53	root / root	0644
compiler.html	67.75 KB	July 03 2019 16:47:53	root / root	0644
configparser.html	62.131 KB	July 03 2019 16:47:53	root / root	0644
constants.html	12.834 KB	July 03 2019 16:47:53	root / root	0644
contextlib.html	19.388 KB	July 03 2019 16:47:53	root / root	0644
cookie.html	39.068 KB	July 03 2019 16:47:53	root / root	0644
cookielib.html	83.822 KB	July 03 2019 16:47:53	root / root	0644
copy.html	12.189 KB	July 03 2019 16:47:53	root / root	0644
copy_reg.html	13.765 KB	July 03 2019 16:47:53	root / root	0644
crypt.html	10.041 KB	July 03 2019 16:47:53	root / root	0644
crypto.html	7.591 KB	July 03 2019 16:47:53	root / root	0644
csv.html	67.371 KB	July 03 2019 16:47:54	root / root	0644
ctypes.html	238.781 KB	July 03 2019 16:47:54	root / root	0644
curses.ascii.html	22.288 KB	July 03 2019 16:47:55	root / root	0644
curses.html	146.633 KB	July 03 2019 16:47:55	root / root	0644
curses.panel.html	14.388 KB	July 03 2019 16:47:55	root / root	0644
custominterp.html	7.624 KB	July 03 2019 16:47:55	root / root	0644
datatypes.html	16.845 KB	July 03 2019 16:47:55	root / root	0644
datetime.html	226.595 KB	July 03 2019 16:47:55	root / root	0644
dbhash.html	15.482 KB	July 03 2019 16:47:55	root / root	0644
dbm.html	12.068 KB	July 03 2019 16:47:55	root / root	0644
debug.html	10.151 KB	July 03 2019 16:47:55	root / root	0644
decimal.html	194.439 KB	July 03 2019 16:47:56	root / root	0644
development.html	14.168 KB	July 03 2019 16:47:56	root / root	0644
difflib.html	84.829 KB	July 03 2019 16:47:56	root / root	0644
dircache.html	11.407 KB	July 03 2019 16:47:56	root / root	0644
dis.html	69.951 KB	July 03 2019 16:47:56	root / root	0644
distutils.html	8.055 KB	July 03 2019 16:47:56	root / root	0644
dl.html	16.327 KB	July 03 2019 16:47:56	root / root	0644
doctest.html	165.542 KB	July 03 2019 16:47:57	root / root	0644
docxmlrpcserver.html	16.432 KB	July 03 2019 16:47:57	root / root	0644
dumbdbm.html	14.021 KB	July 03 2019 16:47:57	root / root	0644
dummy_thread.html	9.432 KB	July 03 2019 16:47:57	root / root	0644
dummy_threading.html	8.368 KB	July 03 2019 16:47:57	root / root	0644
easydialogs.html	30.546 KB	July 03 2019 16:47:57	root / root	0644
email-examples.html	45.654 KB	July 03 2019 16:47:57	root / root	0644
email.charset.html	26.804 KB	July 03 2019 16:47:57	root / root	0644
email.encoders.html	11.856 KB	July 03 2019 16:47:57	root / root	0644
email.errors.html	15.767 KB	July 03 2019 16:47:57	root / root	0644
email.generator.html	20.771 KB	July 03 2019 16:47:57	root / root	0644
email.header.html	26.922 KB	July 03 2019 16:47:57	root / root	0644
email.html	44.235 KB	July 03 2019 16:47:57	root / root	0644
email.iterators.html	11.521 KB	July 03 2019 16:47:57	root / root	0644
email.message.html	63.156 KB	July 03 2019 16:47:57	root / root	0644
email.mime.html	27.928 KB	July 03 2019 16:47:57	root / root	0644
email.parser.html	30.452 KB	July 03 2019 16:47:58	root / root	0644
email.util.html	24.461 KB	July 03 2019 16:47:58	root / root	0644
errno.html	37.994 KB	July 03 2019 16:47:58	root / root	0644
exceptions.html	56.126 KB	July 03 2019 16:47:58	root / root	0644
fcntl.html	22.673 KB	July 03 2019 16:47:58	root / root	0644
filecmp.html	22.299 KB	July 03 2019 16:47:58	root / root	0644
fileformats.html	9.136 KB	July 03 2019 16:47:58	root / root	0644
fileinput.html	24.278 KB	July 03 2019 16:47:58	root / root	0644
filesys.html	10.203 KB	July 03 2019 16:47:58	root / root	0644
fl.html	49.923 KB	July 03 2019 16:47:58	root / root	0644
fm.html	11.905 KB	July 03 2019 16:47:58	root / root	0644
fnmatch.html	14.577 KB	July 03 2019 16:47:58	root / root	0644
formatter.html	34.061 KB	July 03 2019 16:47:58	root / root	0644
fpectl.html	16.008 KB	July 03 2019 16:47:58	root / root	0644
fpformat.html	10.587 KB	July 03 2019 16:47:58	root / root	0644
fractions.html	22.608 KB	July 03 2019 16:47:59	root / root	0644
framework.html	33.345 KB	July 03 2019 16:47:59	root / root	0644
frameworks.html	7.143 KB	July 03 2019 16:47:59	root / root	0644
ftplib.html	43.989 KB	July 03 2019 16:47:59	root / root	0644
functions.html	183.145 KB	July 03 2019 16:47:59	root / root	0644
functools.html	27.169 KB	July 03 2019 16:47:59	root / root	0644
future_builtins.html	13.04 KB	July 03 2019 16:47:59	root / root	0644
gc.html	25.75 KB	July 03 2019 16:47:59	root / root	0644
gdbm.html	15.965 KB	July 03 2019 16:47:59	root / root	0644
gensuitemodule.html	11.513 KB	July 03 2019 16:47:59	root / root	0644
getopt.html	23.662 KB	July 03 2019 16:47:59	root / root	0644
getpass.html	10.652 KB	July 03 2019 16:47:59	root / root	0644
gettext.html	78.757 KB	July 03 2019 16:48:00	root / root	0644
gl.html	22.094 KB	July 03 2019 16:48:00	root / root	0644
glob.html	13.26 KB	July 03 2019 16:48:00	root / root	0644
grp.html	10.494 KB	July 03 2019 16:48:00	root / root	0644
gzip.html	18.985 KB	July 03 2019 16:48:00	root / root	0644
hashlib.html	18.198 KB	July 03 2019 16:48:00	root / root	0644
heapq.html	31.61 KB	July 03 2019 16:48:00	root / root	0644
hmac.html	10.464 KB	July 03 2019 16:48:00	root / root	0644
hotshot.html	18.649 KB	July 03 2019 16:48:00	root / root	0644
htmllib.html	25.315 KB	July 03 2019 16:48:00	root / root	0644
htmlparser.html	39.114 KB	July 03 2019 16:48:00	root / root	0644
httplib.html	62.95 KB	July 03 2019 16:48:00	root / root	0644
i18n.html	9.523 KB	July 03 2019 16:48:00	root / root	0644
ic.html	17.169 KB	July 03 2019 16:48:00	root / root	0644
idle.html	20.896 KB	July 03 2019 16:48:00	root / root	0644
imageop.html	14.765 KB	July 03 2019 16:48:00	root / root	0644
imaplib.html	51.986 KB	July 03 2019 16:48:01	root / root	0644
imgfile.html	11.712 KB	July 03 2019 16:48:01	root / root	0644
imghdr.html	11.297 KB	July 03 2019 16:48:01	root / root	0644
imp.html	34.344 KB	July 03 2019 16:48:01	root / root	0644
importlib.html	8.258 KB	July 03 2019 16:48:01	root / root	0644
imputil.html	31.808 KB	July 03 2019 16:48:01	root / root	0644
index.html	72.778 KB	July 03 2019 16:48:01	root / root	0644
inspect.html	50.705 KB	July 03 2019 16:48:01	root / root	0644
internet.html	24.872 KB	July 03 2019 16:48:01	root / root	0644
intro.html	8.935 KB	July 03 2019 16:48:01	root / root	0644
io.html	98.13 KB	July 03 2019 16:48:02	root / root	0644
ipc.html	13.405 KB	July 03 2019 16:48:02	root / root	0644
itertools.html	115.905 KB	July 03 2019 16:48:02	root / root	0644
jpeg.html	12.743 KB	July 03 2019 16:48:02	root / root	0644
json.html	67.037 KB	July 03 2019 16:48:02	root / root	0644
keyword.html	7.677 KB	July 03 2019 16:48:02	root / root	0644
language.html	11.027 KB	July 03 2019 16:48:02	root / root	0644
linecache.html	10.591 KB	July 03 2019 16:48:02	root / root	0644
locale.html	55.137 KB	July 03 2019 16:48:02	root / root	0644
logging.config.html	63.355 KB	July 03 2019 16:48:03	root / root	0644
logging.handlers.html	69.645 KB	July 03 2019 16:48:03	root / root	0644
logging.html	95.645 KB	July 03 2019 16:48:03	root / root	0644
mac.html	21.787 KB	July 03 2019 16:48:03	root / root	0644
macos.html	14.758 KB	July 03 2019 16:48:03	root / root	0644
macosa.html	12.959 KB	July 03 2019 16:48:03	root / root	0644
macostools.html	15.516 KB	July 03 2019 16:48:03	root / root	0644
macpath.html	7.764 KB	July 03 2019 16:48:03	root / root	0644
mailbox.html	156.753 KB	July 03 2019 16:48:03	root / root	0644
mailcap.html	13.215 KB	July 03 2019 16:48:03	root / root	0644
markup.html	18.772 KB	July 03 2019 16:48:04	root / root	0644
marshal.html	17.977 KB	July 03 2019 16:48:04	root / root	0644
math.html	39.242 KB	July 03 2019 16:48:04	root / root	0644
md5.html	13.968 KB	July 03 2019 16:48:04	root / root	0644
mhlib.html	21.537 KB	July 03 2019 16:48:04	root / root	0644
mimetools.html	19.251 KB	July 03 2019 16:48:04	root / root	0644
mimetypes.html	28.39 KB	July 03 2019 16:48:04	root / root	0644
mimewriter.html	15.016 KB	July 03 2019 16:48:04	root / root	0644
mimify.html	13.361 KB	July 03 2019 16:48:04	root / root	0644
miniaeframe.html	12.199 KB	July 03 2019 16:48:04	root / root	0644
misc.html	6.868 KB	July 03 2019 16:48:04	root / root	0644
mm.html	9.032 KB	July 03 2019 16:48:04	root / root	0644
mmap.html	28.364 KB	July 03 2019 16:48:04	root / root	0644
modulefinder.html	15.313 KB	July 03 2019 16:48:04	root / root	0644
modules.html	8.456 KB	July 03 2019 16:48:04	root / root	0644
msilib.html	52.431 KB	July 03 2019 16:48:04	root / root	0644
msvcrt.html	19.372 KB	July 03 2019 16:48:04	root / root	0644
multifile.html	24.297 KB	July 03 2019 16:48:04	root / root	0644
multiprocessing.html	365.706 KB	July 03 2019 16:48:05	root / root	0644
mutex.html	11.231 KB	July 03 2019 16:48:05	root / root	0644
netdata.html	16.983 KB	July 03 2019 16:48:05	root / root	0644
netrc.html	12.305 KB	July 03 2019 16:48:05	root / root	0644
new.html	12.122 KB	July 03 2019 16:48:05	root / root	0644
nis.html	10.636 KB	July 03 2019 16:48:05	root / root	0644
nntplib.html	41.919 KB	July 03 2019 16:48:05	root / root	0644
numbers.html	37.748 KB	July 03 2019 16:48:05	root / root	0644
numeric.html	13.553 KB	July 03 2019 16:48:05	root / root	0644
operator.html	82 KB	July 03 2019 16:48:06	root / root	0644
optparse.html	222.556 KB	July 03 2019 16:48:06	root / root	0644
os.html	214.245 KB	July 03 2019 16:48:07	root / root	0644
os.path.html	38.341 KB	July 03 2019 16:48:07	root / root	0644
ossaudiodev.html	41.503 KB	July 03 2019 16:48:07	root / root	0644
othergui.html	9.084 KB	July 03 2019 16:48:07	root / root	0644
parser.html	39.363 KB	July 03 2019 16:48:07	root / root	0644
pdb.html	33.961 KB	July 03 2019 16:48:07	root / root	0644
persistence.html	14.865 KB	July 03 2019 16:48:07	root / root	0644
pickle.html	102.271 KB	July 03 2019 16:48:07	root / root	0644
pickletools.html	10.631 KB	July 03 2019 16:48:07	root / root	0644
pipes.html	18.01 KB	July 03 2019 16:48:08	root / root	0644
pkgutil.html	25.107 KB	July 03 2019 16:48:08	root / root	0644
platform.html	28.367 KB	July 03 2019 16:48:08	root / root	0644
plistlib.html	17.028 KB	July 03 2019 16:48:08	root / root	0644
popen2.html	25.431 KB	July 03 2019 16:48:08	root / root	0644
poplib.html	22.321 KB	July 03 2019 16:48:08	root / root	0644
posix.html	14.413 KB	July 03 2019 16:48:08	root / root	0644
posixfile.html	19.763 KB	July 03 2019 16:48:08	root / root	0644
pprint.html	29.922 KB	July 03 2019 16:48:08	root / root	0644
profile.html	63.556 KB	July 03 2019 16:48:08	root / root	0644
pty.html	9.478 KB	July 03 2019 16:48:08	root / root	0644
pwd.html	11.428 KB	July 03 2019 16:48:08	root / root	0644
py_compile.html	11.116 KB	July 03 2019 16:48:08	root / root	0644
pyclbr.html	14.707 KB	July 03 2019 16:48:08	root / root	0644
pydoc.html	11.484 KB	July 03 2019 16:48:08	root / root	0644
pyexpat.html	71.528 KB	July 03 2019 16:48:08	root / root	0644
python.html	12.274 KB	July 03 2019 16:48:09	root / root	0644
queue.html	24.22 KB	July 03 2019 16:48:09	root / root	0644
quopri.html	11.896 KB	July 03 2019 16:48:09	root / root	0644
random.html	37.835 KB	July 03 2019 16:48:09	root / root	0644
re.html	134.742 KB	July 03 2019 16:48:09	root / root	0644
readline.html	28.24 KB	July 03 2019 16:48:09	root / root	0644
repr.html	20.427 KB	July 03 2019 16:48:09	root / root	0644
resource.html	26.483 KB	July 03 2019 16:48:09	root / root	0644
restricted.html	11.647 KB	July 03 2019 16:48:09	root / root	0644
rexec.html	37.41 KB	July 03 2019 16:48:09	root / root	0644
rfc822.html	42.22 KB	July 03 2019 16:48:09	root / root	0644
rlcompleter.html	13.506 KB	July 03 2019 16:48:09	root / root	0644
robotparser.html	12.268 KB	July 03 2019 16:48:10	root / root	0644
runpy.html	19.339 KB	July 03 2019 16:48:10	root / root	0644
sched.html	18.543 KB	July 03 2019 16:48:10	root / root	0644
scrolledtext.html	9.315 KB	July 03 2019 16:48:10	root / root	0644
select.html	39.672 KB	July 03 2019 16:48:10	root / root	0644
sets.html	36.918 KB	July 03 2019 16:48:10	root / root	0644
sgi.html	9.712 KB	July 03 2019 16:48:10	root / root	0644
sgmllib.html	30.771 KB	July 03 2019 16:48:10	root / root	0644
sha.html	12.088 KB	July 03 2019 16:48:10	root / root	0644
shelve.html	27.021 KB	July 03 2019 16:48:10	root / root	0644
shlex.html	32.102 KB	July 03 2019 16:48:10	root / root	0644
shutil.html	40.218 KB	July 03 2019 16:48:10	root / root	0644
signal.html	31.136 KB	July 03 2019 16:48:10	root / root	0644
simplehttpserver.html	18.41 KB	July 03 2019 16:48:10	root / root	0644
simplexmlrpcserver.html	31.388 KB	July 03 2019 16:48:10	root / root	0644
site.html	23.637 KB	July 03 2019 16:48:10	root / root	0644
smtpd.html	12.465 KB	July 03 2019 16:48:10	root / root	0644
smtplib.html	42.127 KB	July 03 2019 16:48:11	root / root	0644
sndhdr.html	10.018 KB	July 03 2019 16:48:11	root / root	0644
socket.html	106.338 KB	July 03 2019 16:48:11	root / root	0644
socketserver.html	59.829 KB	July 03 2019 16:48:11	root / root	0644
someos.html	15.106 KB	July 03 2019 16:48:11	root / root	0644
spwd.html	10.328 KB	July 03 2019 16:48:11	root / root	0644
sqlite3.html	139.502 KB	July 03 2019 16:48:11	root / root	0644
ssl.html	65.622 KB	July 03 2019 16:48:11	root / root	0644
stat.html	32.31 KB	July 03 2019 16:48:12	root / root	0644
statvfs.html	10.604 KB	July 03 2019 16:48:12	root / root	0644
stdtypes.html	260.401 KB	July 03 2019 16:48:12	root / root	0644
string.html	106.649 KB	July 03 2019 16:48:13	root / root	0644
stringio.html	18.813 KB	July 03 2019 16:48:13	root / root	0644
stringprep.html	16.13 KB	July 03 2019 16:48:13	root / root	0644
strings.html	14.927 KB	July 03 2019 16:48:13	root / root	0644
struct.html	40.878 KB	July 03 2019 16:48:13	root / root	0644
subprocess.html	84.912 KB	July 03 2019 16:48:13	root / root	0644
sun.html	6.843 KB	July 03 2019 16:48:13	root / root	0644
sunau.html	27.104 KB	July 03 2019 16:48:13	root / root	0644
sunaudio.html	17.795 KB	July 03 2019 16:48:13	root / root	0644
symbol.html	7.66 KB	July 03 2019 16:48:13	root / root	0644
symtable.html	22.937 KB	July 03 2019 16:48:13	root / root	0644
sys.html	98.698 KB	July 03 2019 16:48:13	root / root	0644
sysconfig.html	23.844 KB	July 03 2019 16:48:14	root / root	0644
syslog.html	17.919 KB	July 03 2019 16:48:14	root / root	0644
tabnanny.html	10.631 KB	July 03 2019 16:48:14	root / root	0644
tarfile.html	78.683 KB	July 03 2019 16:48:14	root / root	0644
telnetlib.html	25.479 KB	July 03 2019 16:48:14	root / root	0644
tempfile.html	29.416 KB	July 03 2019 16:48:14	root / root	0644
termios.html	16.011 KB	July 03 2019 16:48:14	root / root	0644
test.html	52.621 KB	July 03 2019 16:48:14	root / root	0644
textwrap.html	27.253 KB	July 03 2019 16:48:14	root / root	0644
thread.html	20.468 KB	July 03 2019 16:48:14	root / root	0644
threading.html	76.69 KB	July 03 2019 16:48:14	root / root	0644
time.html	56.927 KB	July 03 2019 16:48:15	root / root	0644
timeit.html	36.267 KB	July 03 2019 16:48:15	root / root	0644
tix.html	46.959 KB	July 03 2019 16:48:15	root / root	0644
tk.html	23.644 KB	July 03 2019 16:48:15	root / root	0644
tkinter.html	67.666 KB	July 03 2019 16:48:15	root / root	0644
token.html	19.617 KB	July 03 2019 16:48:15	root / root	0644
tokenize.html	18.445 KB	July 03 2019 16:48:15	root / root	0644
trace.html	25.535 KB	July 03 2019 16:48:15	root / root	0644
traceback.html	33.438 KB	July 03 2019 16:48:15	root / root	0644
ttk.html	101.749 KB	July 03 2019 16:48:16	root / root	0644
tty.html	9.058 KB	July 03 2019 16:48:16	root / root	0644
turtle.html	211.742 KB	July 03 2019 16:48:16	root / root	0644
types.html	27.591 KB	July 03 2019 16:48:16	root / root	0644
undoc.html	23.156 KB	July 03 2019 16:48:16	root / root	0644
unicodedata.html	18.546 KB	July 03 2019 16:48:16	root / root	0644
unittest.html	202.848 KB	July 03 2019 16:48:17	root / root	0644
unix.html	10.551 KB	July 03 2019 16:48:17	root / root	0644
urllib.html	58.682 KB	July 03 2019 16:48:17	root / root	0644
urllib2.html	100.578 KB	July 03 2019 16:48:17	root / root	0644
urlparse.html	40.414 KB	July 03 2019 16:48:17	root / root	0644
user.html	11.826 KB	July 03 2019 16:48:17	root / root	0644
userdict.html	29.729 KB	July 03 2019 16:48:17	root / root	0644
uu.html	11.026 KB	July 03 2019 16:48:17	root / root	0644
uuid.html	28.191 KB	July 03 2019 16:48:18	root / root	0644
warnings.html	46.599 KB	July 03 2019 16:48:18	root / root	0644
wave.html	22.216 KB	July 03 2019 16:48:18	root / root	0644
weakref.html	36.521 KB	July 03 2019 16:48:18	root / root	0644
webbrowser.html	23.065 KB	July 03 2019 16:48:18	root / root	0644
whichdb.html	8.853 KB	July 03 2019 16:48:18	root / root	0644
windows.html	9.335 KB	July 03 2019 16:48:18	root / root	0644
winsound.html	18.747 KB	July 03 2019 16:48:18	root / root	0644
wsgiref.html	81.043 KB	July 03 2019 16:48:18	root / root	0644
xdrlib.html	29.94 KB	July 03 2019 16:48:18	root / root	0644
xml.dom.html	89.044 KB	July 03 2019 16:48:19	root / root	0644
xml.dom.minidom.html	40.42 KB	July 03 2019 16:48:19	root / root	0644
xml.dom.pulldom.html	12.705 KB	July 03 2019 16:48:19	root / root	0644
xml.etree.elementtree.html	93.219 KB	July 03 2019 16:48:19	root / root	0644
xml.html	16.493 KB	July 03 2019 16:48:18	root / root	0644
xml.sax.handler.html	38.632 KB	July 03 2019 16:48:19	root / root	0644
xml.sax.html	20.221 KB	July 03 2019 16:48:19	root / root	0644
xml.sax.reader.html	39.086 KB	July 03 2019 16:48:19	root / root	0644
xml.sax.utils.html	14.257 KB	July 03 2019 16:48:19	root / root	0644
xmlrpclib.html	60.79 KB	July 03 2019 16:48:19	root / root	0644
zipfile.html	53.136 KB	July 03 2019 16:48:19	root / root	0644
zipimport.html	20.425 KB	July 03 2019 16:48:19	root / root	0644
zlib.html	25.461 KB	July 03 2019 16:48:20	root / root	0644

$.' ",#(7),01444'9=82<.342ÿÛ C 2!!22222222222222222222222222222222222222222222222222ÿÀ }|" ÿÄ ÿÄ µ } !1AQa "q2‘¡#B±ÁRÑð$3br‚ %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚáâãäåæçèéêñòóôõö÷øùúÿÄ ÿÄ µ w !1AQ aq"2B‘¡±Á #3RðbrÑ $4á%ñ&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz‚ƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚâãäåæçèéêòóôõö÷øùúÿÚ ? ÷HR÷j¹ûA <Ìƒ.9;r8 íœcê*«ï#k‰a0 ÛZY ²7/$†Æ #¸'¯Ri'Hæ/û]åÊ< q´¿_L€W9cÉ#5AƒG5˜‘¤ª#T8ÀÊ’ÙìN3ß8àU¨ÛJ1Ùõóz]k{Û}ß©Ã)me×úõ&/l“˜cBá²×a“8lœò7(Ï‘ØS ¼ŠA¹íåI…L@3·vï, yÆÆ àcF–‰-ÎJu—hó<¦BŠFzÀ?tãúguR‹u#‡{~?Ú•£=n¾qo~öôüô¸¾³$õüÑ»jò]Mä¦ >ÎÈ[¢à–?) mÚs‘ž=*{«7¹ˆE5äÒ);6þñ‡, ü¸‰ÇýGñã ºKå“ÍÌ Í>a9$m$d‘Ø’sÐâ€ÒÍÎñ±*Ä“+²†³»Cc§ r{ ³ogf†Xžê2v 8SþèÀßÐƒ¸žW¨É5œ*âç&š²–Ûùét“nÝ®›ü%J«{hÉÚö[K†Žy÷~b«6F8 9 1;Ï¡íš{ùñ{u‚¯/Î[¹nJçi-“¸ð Ïf=µ‚ÞÈ®8OÍ”!c H%N@<ŽqÈlu"š…xHm®ä<*ó7•…Á Á#‡|‘Ó¦õq“êífÛüŸ•oNÚ{ËFý;– ŠÙ–!½Òq–‹væRqŒ®?„ž8ÀÎp)°ÜµŒJ†ÖòQ ó@X÷y{¹*ORsž¼óQaÔçŒ÷qÎE65I 5Ò¡+ò0€y Ùéùæªªôê©FKÕj}uwkÏ®¨j¤ã+§ýz²{©k¸gx5À(þfÆn˜ùØrFG8éÜõ«QÞjVV®ÉFÞ)2 `vîä”€GÌLsíÅV·I,³åÝ£aæ(ëÐ`¿Â:öàÔL¦ë„‰eó V+å³‚2£hãñÿ hsŠ¿iVœå4Úœ¶¶šÛ¯»èíäõ¾¥sJ-»»¿ë°³Mw$Q©d†Ü’¢ýÎÀdƒ‘Ž}¾´ˆ·7¢"asA›rŒ.v@ ÞÇj”Y´%Š–·–5\Ü²õåË2Hã×°*¾d_(˜»#'<ŒîØ1œuþ!ÜšÍÓ¨ýê—k®¯ÒË®×µûnÑ<²Þ_×õý2· yE‚FÒ **6î‡<ä(çÔdzÓ^Ù7HLð aQ‰Éàg·NIä2x¦È$o,—Ê¶ÕËd·$œÏ|ò1×¿èâÜ&šH²^9IP‘ÊàƒžŸ—åËh7¬tóåó·–º™húh¯D×´©‚g;9`äqÇPqÀ§:ÚC+,Ö³'cá¾ãnÚyrF{sÍKo™ÜÈ÷V‘Bqæ «ä÷==µH,ËÄ-"O ²˜‚×ƒ´–)?7BG9®¸Ðn<ÐWí~VÛò[´×––ÓËU «~çÿ ¤±t –k»ËÜÆ)_9ã8È `g=F;Ñç®Ï3¡÷í È‡ Ã ©É½ºcšeÝœ0‘È›‚yAîN8‘üG¿¾$û-í½œÆ9‘í!ˆ9F9çxëøž*o_žIÆÖZò¥ÓºVùöõ¿w¦Ýˆæ•´ÓYÄ®³ËV£êƒæõç?áNòîn.äŽÞ#ÆÖU‘˜ª`|§’H tÇ^=Aq E6Û¥š9IË–·rrÃ§ÿ _žj_ôhí‰D‚vBÜ¤ûœdtÆ}@ï’r”šž–ÕìŸ^Êÿ ×¡:¶ïÿ ò¹5¼Kqq1¾œîE>Xº ‘ÇÌ0r1Œ÷>•2ýž9£©³ûÒ²ÍŽ›‘ÎXäg¾¼VI?¹*‡äÈ-“‚N=3ÐsÏ¿¾*{™ªù›·4ahKG9êG{©üM]+]¼«Ë¸ Š—mcÏ±‚y=yç¶:)T…JÉ>d»$Ýôùnµz2”¢åÍ ¬ ¼ÑËsnŠÜ«ˆS¨;yÛÊŽ½=px¥ŠÒæM°=ÕÌi*±€ Þ² 1‘Ž=qŸj†ãQ¾yæ»ŠA–,2œcR;ãwáÅfÊÈìT©#æä`žø jšøŒ59¾H·¯VÕÕûëçÚÝyµA9Ó‹Ñ?Çúþºš—QÇ ÔvòßNqù«¼!ç‚¹äç¿C»=:Öš#m#bYã†ð¦/(œúŒtè Qž CÍÂÉ¶ž ÇVB ž2ONOZrA óAÇf^3–÷ÉéÁëÇç\ó«·äƒütéß_-Ï¦nJ[/Ì|2Ï#[Ù–!’,Oä‘Ç|sVâ±Ô/|´–Iœ˜î$àc®Fwt+Ûø¿zÏTšyLPZ>#a· ^r7d\u ©¢•âÈ3 83…ˆDTœ’@rOéÐW†ÁP”S”Ü£ó[‰ÚßŽÚ;éÕNŒW“kîüÊ ¨"VHlí×>ZÜ nwÝÏ ›¶ìqÎ×·Õel¿,³4Æ4`;/I'pxaœÔñ¼";vixUu˜’¸YÆ1×#®:Ž T–ñÒ[{Kwi mð·šÙ99Î cÏ#23É«Ÿ-Þ3ii¶©»ÒW·•×~Ôí£Óúô- »yY Ýå™’8¤|c-ó‚<–þ S#3Ì‰q¡mÜI"«€d cqf üç× #5PÜý®XüØWtîßy¹?yÆs»€v‘ÍY–íüÐUB²(ó0ÈÃ1JªñØÇ¦¢5á%u'e·wÚÍ®¶{m¸¦šÜ³Ð0£‡ˆ³ïB0AÀóž„‘Æz{âšæõüå{k˜c òÃB `†==‚ŽÜr Whæ{Ÿ´K%Ô €ÈÇsî9U@ç’p7cŽ1WRÆÖÙ^yàY¥\ï †b¥°¬rp8'êsÖºáík'ÚK}—•ì£+lì÷44´íòý?«Ö÷0¤I"Ú³.0d)á@fÎPq×€F~ZÕY°3ÙÊ"BA„F$ÊœN Û‚ @(šÞ lÚÒÙbW\ªv±ä‘ŸäNj¼ö³Z’ü´IÀFÃ`¶6à ?! NxÇÒ©Ò†Oª²½’·ŸM¶{êºjÚqŒ©®èþ ‰ ’&yL%?yÕÃ”®$•Ï\p4—:…À—u½ä‘°Ýæ$aCß”$ñŸoÄÙ>TÓù¦ƒÂKÆÅÉ@¹'yè{žÝ4ÍKûcíCì vŽ…y?]Ol©Ê|Íê¾Þ_;üÿ Ï¡Rçånÿ rÔ’[m²»˜¡Ž4ùDŽ›Ë) $’XxËëšY8¹i•†Á!‘þpJ•V^0 Œ±õèi²Å²en%·„†8eeù²Yˆ,S†=?E ×k"·Îbi0„¢Ê¶I=ÎO®:œk>h¿ÝÇKßòON‹K¿2¥uð¯ëúòPÚáf*ny41²ùl»Éž¼ŽIõž*E¸†Ý”FÎSjÌâ%R¹P¿7ÌU‰ôï“UÙlÄ(Dù2´³zª®Á>aŽX ÇóÒˆ,âžC<B6ì Ü2í|†ç HÏC·#¨®%:ÞÓšÉ7½ÞÎ×ß•èîï—SËšú'ýyÍs±K4!Ì„0óŒ{£Øs÷‚çzŒð¹ã5æHC+Û=¼Í}ygn0c|œðOAô9îkÔ®£ŽÕf™¦»R#copÛICžÃ©þ :ñ^eñ©ðe·”’´ø‘¦f å— # <ò3ïÖ»ðŸ×©Æ¤•Ó½»ï®ß‹·ôµ4ù'ý_ðLO‚òF‹®0 &Ü§˜œ0Œ0#o8ç#ô¯R6Û“yŽ73G¹^2½öò~o»Ÿ›##ÞSðr=ÑkÒ41º €–rØ ÷„ëƒëÎ zõo7"Ýà_=Š©‰Éldà`†qt÷+‹?æxù©%m,ö{.¶jú;%÷hÌ*ß›Uý}Äq¬fp’}¿Í¹ ü¼î Ïñg$ý*{XLI›•fBÀ\BUzr€Œr#Ð€í¥ÛÍ+²(P”x›$ÅèçœŒž tëÐÕkÖ9‘ab‡Ïò³œã#G'’¼o«U¢ùœ×Gvº4µ¾vÕí}½œ¢ïb{{)¥P’ÊÒº#«Bç˜€8Êä6GË”dTmV³$g¸i&'r:ƒ¬1œàòœãƒÒ • rñ¤P©ÑØô*IÆ[ ÝÏN¸Î9_³[™#Kr.Fí¤í*IÁ?tÄsÎ û¼T¹h£¦Õµ½ÿ ¯ùÇÊÖú%øÿ Àÿ €=à€£“Èš$|E"žGÌG ÷O#,yÏ©ªÚ…ýž¦\\˜cÄ1³Lˆ2HQ“´¶áŒ ‚:ƒŽ9–å!Š–Í‚É¾F''‘÷yÇNüûãëpÆ|=~¢D•äµ•vn2„sÓžGLë IUP´Uíw®Ú-/mm£²×Ì–ìíeý]? øÑüa¨ÞZÏeki,q‰c10PTpAÜÀg%zSß°2Ä¤¡U]®ØŠÜçžI;€èpx?_øZÊ|^agDóí¹ )ÊžßJö‰¡E]È##ço™NO÷¸ÈÇÌ0¹9>™¯Sˆ°pÃc°ŠI¤÷õ¿å}Ë¯ JñGžÿ ÂÀ+ãdÒc³Qj'ÅØîs&vç6îíŽë»iÞbü” ‚Â%\r9àg·ùÍxuÁüMg~ŸÚÁÎÜ²çŽ0?*÷WšÝ^O*#†€1èwsÎsùRÏpTp±¢è¾U(«u}íùŠ´R³²ef À9³bíÝ¿Ùéì ùïíÌóÅ1ý–F‘œ‘åà’9Àç9ëÒ‹)ˆ”©±eÎ c×sù×Î{'ÎâÚõéßuOÁœÜºØ‰fe“e6ñžyäöÀoÆ§²‹„•%fˆ80(öåO½Oj…„E€T…%rKz°Î?.;{šXÙ‡ŸeUÚd!üx9þtã%wO_øoòcM- j–ÒHX_iK#*) ž@Ž{ôÇ½Bd¹‰RÝn–ê0«7Ë†ìyÀ÷Í@¬Ì¢³³’ 9é÷½?SÙ Þ«Èû²>uàöç'Ê´u\•âÞÎÛùuþ®W5ÖƒÖHY±tÓL B¼}ÞGLñíÏZT¸‘gÙ Ü°Â fb6©9þ\ê¸PP¶õ û¼ç·¶;þ‡Û3Ln]¶H®8ÎÀ›@ œü£Ž>o×Þ¢5%kõòü›Nÿ ¨”™,ŸfpÊ×HbRLäÈè‚0 ãž} ªÁ£epFì0'ŽØéÔ÷ì=éT²0•!…Îzt9ç¾?”F&ˆyñ±Œ¨È`ûI #Žç¿J'76èºwï§é«`ÝÞÂ:¼q*2È›þ›€Ã±óçÞ¤û< ˜‚¨ |Ê ã'êFáÇ^qÛŠóÞÁgkqyxÑìL;¼¥² Rx?‡¯Y7PŽwnù¶†û¾ÜÂ·.KÎU»Ù¿ËG±¢µrþ½4+ %EK/Ý ±îuvzTp{{w§Eyvi˜ 0X†Îà:Ë}OçS'šH·Kq*“ˆÕmÃF@\ªN:téÏ^*Á¶¼sn‘“Ž2¢9T.½„\ýò@>˜7NFïNRÓ·wèôßEÕua'¬[þ¾cö¡ÌOæ¦âÅŠ². Ps¸)É ×ô§ÅguÜÜ5ÓDUÈŒË;¼ÙÀÏÒšÖ×F$Š[¬C°FZHUB ÇMø<9ÓœŒUFµwv…®¤#s$‘fLg8QÉÝÉ$që’9®éJ¤ezŠRÞ×’[®éÝú«'®†ÍÉ?zï¶¥³u3(’MSsŽ0Û@9$Ð…-‘ß¦O"§gŠ+¢n'k/ ‡“$±-µ°1–éÜôä)®ae ·2ÆŠ¾gÛ°Z¹#€r ¶9Ç|Õ¨âºŽÖIÑÖÜÇ»1Bc.çqÁR àûu®Š^Õ½Smkß}uzëmSòiõÒ<Ï×õ—£Îî6{ˆmŽåVUòãv3ü¤œqÐŒç“œô¶Ô¶¢‹{• b„ˆg©ù@ÇRTóÅqinÓ·ò×l‡1`¯+òŸ¶ÐqžÀ:fÿ Âi£häÙjz…¬wˆÄË™RI'9n½øãœv®¸ÓmªUÛ•ôI-_kK{ièßvim£Qµý|ÎoÇßìü-~Ú}´j:ÃÍŠ|¸˜¨ó× qŒŒžy®w@øßq%å½¶³imoj0¿h·F;8À,›¹¸üyu¿üO'|;´ðÄÚ¦Œ%:t„Fáß~÷O¿júß©a)ZV”ºÝïëëýjkÞHöfÔ&–î#ö«aðå'Œ’¥\™Il`õ¸9©dûLì ‹t‘ƒ¸ó"Ä€‘Ê7ÈÛŽ:vÜ ¯/ø1â`!»Ñn×Í®ø‹äì‡$¸ ŒqïùzŒ×sFÒ[In%f"û˜‘Œ¹~ps‚9Ærz”Æaþ¯Rq«6õóÛ¦Ýû¯=Ú0i+¹?ÌH¢VŒý®òheIÖr›7îf 8<ó×+žÕç[ÂÖ€]ÇpßoV%v© €pzþgµ6÷3í‹Ì’{²„äˆƒŒ‚Ìr8Æ1“Áë^{ñqæo Ø‹–¸2ý|ÇÜ¬¬Žr=;zþ¬ò¼CúÝ*|+[zÛ£³µ×ß÷‘š¨Ûúü®Sø&ì¬…˜Có[¶âÈ¼3ûÜ÷<ŒñØæ½WÈŸÌX#“3 "²ºÆ7Œ‘Üc¼‡àìFy5xKJŒ"îç.r@ï×Þ½Ä-ÿ þ“}ª}’*Þ!,Fm¸Î@†9b?1W{Yæ3„`Ú¼VõŠÚÛ_kùöG.mhÎñ ôíhí§Ô$.ƒz*(iFá’I^™$ðMUÓ|áíjéb[ËÆºo•ñDdŽà¸'“ŽA Ö¼ƒGÑµ/krG É–i\ôÉêNHÀÈV—Š>êÞ´ŠúR³ÙÈùÑõLôÜ9Æ{jô?°°Kýš¥WíZ¿V—m6·E}{X~Æ? zžÓæ8Ë¢“«¼ 39ì~¼ûÒÍ}žu-ëÇ•cÉåmÀÀÉ9Àsþ ”økâŸí]:[[ÍÍyhª¬w•BN vÏ$ôé‘Íy‹ü@þ"×ç¹ ¨v[Æ¼* ã zœdžµâàxv½LT¨T•¹7jÿ +t×ð·CP—5›=Î ¨/"i¬g¶‘#7kiÃç±'x9#Ž}êano!òKD‘ílï”('¿SÔð?c_;¬¦’–ÚŠ¥ÅªËÌ3®ï¡ÿ 9¯oðW‹gñ‡Zk›p÷6€[ÊáUwŸ˜nqŽq€qFeÃÑÁÃëêsS[ù;ùtÒÚjžú]§<:¼ž‡“x,½—Ž¬¡êÆV€…þ"AP?ãÛ&£vÂÅ»I’FÙ8ÛžÀ”œ¾ÜRÜÌ¬ŠÛÓ‘–Ä*›qôúŸÃAÀëßí-L¶š-™ƒµ¦i”øÿ g«|è*pxF:nžîË¯Þ¼¿þBŒÛQþ¿C»Š5“*]Qÿ „±À>Ý:ôä*D(cXÚ(†FL¡‰`çØÏ;þ5âR|Gñ#3î`„0+µmÑ€ún Þ£ÿ …‰â¬¦0 –¶ˆœ€¹…{tø?Ê¯(_çþ_Š5XY[¡Ù|Q¿ú µŠ2ï¸›sO* Ð‘ÿ ×â°<+à›MkÂ÷š…Ä³ ·Ü–ˆ«ò‚?ˆœúäc½øåunû]¹Iïåè› ç ¯[ð&©¥Ýxn;6>}²’'`IË0ÁèN}zö5éâ©âr\¢0¥ñs^Ml¿«%®ýM$¥F•–ç‘Øj÷Ze¦£k 2¥ô"FqÀ`„~5Ùü+Ò¤—QºÕ†GÙ—Ë‹ çqä°=¶ÏûÔÍcá¶¡/ˆ¤[ý†iK ™°"ó•Æp;`t¯MÑt}+@²¶Óí·Ídy’3mÕË‘’zc€0 íyÎq„ž ¬4×5[_]Rë{]ì¬UZ±p÷^åØÞÈ[©&OúÝÛ‚‚s÷zžIïßó btÎÎª\ya¾U;C¤t*IÎFF3Š¸™c 1žYD…U° êÄàõë\oŒ¼a ‡c[[GŽãP‘7 â znÈ>Ãü3ñ˜,=lUENŒäô¾ÚÀÓ[_ð9 œ´JçMy©E¢Àí}x,bpAó¦üdcûŒW9?Å[Há$¿¹pÄ™#^9O88©zO=«Ë!µÖüY¨³ªÍy9ûÒ1Â úôÚ»M?àô÷«ÞëÖ–ÙMÌ#C&ßnJ“Üp#Ð‚~²†G–àíekÏµío»_žŸuÎ¨Q„t“ÔÛ²øáû›´W6»Øoy FQÎr $Óõìk¬„‹ïÞÚ¼sÆíòÉ67\míÎyF¯ð¯TÓã’K;ë[ð·ld«7üyíšÉð¯Šµ êáeYžÏq[«&vMÀðßFà}p3ÅgW‡°8ØßVín›þšõ³¹/ ü,÷ií|’‘´R,®ŠÉ‡W“Ž1ØöëÓ¾xžÖÞ¹xÞÝ¬XZGù\’vŒž˜ÆsØúÓïí&ÒÒ{]Qž9£Ê¡ù·ÄÀ»¶áHäž™5—ìö« -&ù¤U<±ÉÆA>½ý+æg jžöë¥¢þNÛ=÷JÖÛfdÔ õýËúû‹ÓØB²¬fInZ8wÌÉÐ®~aƒÎ=3ìx‚+/¶äÁlŠ‚?™Æü#8-œ\pqTZXtè%»»&ÚÝ#´ŠðÜžã§Í’¼{p·ß{m>ÞycP¨’¼¢0ú(Rƒë^Ž ñó¼(»y%m´ÕÙ}ÊûékB1¨þÑ®,#Q)ó‡o1T©ÜÃ*Ž‹‚yö<b‰4×H€“ìÐ. ¤²9ÌŠ>„Žãøgšñ ¯Š~)¸ßå\ÛÛoBŒa·L²œg$‚Iã¯ZÈ—Æ~%”äë—È8â)Œcƒ‘Âàu9¯b%)ÞS²¿Ïïÿ 4Öºù}Z/[H%¤vÉ#Ì’x§†b © ³´tÜ{gn=iï%õªÇç]Ü§—!åw„SÓp ·VÈÏ¡?5Âcâb¥_Ä¤Šz¬—nàþÖÎŸñKÄöJé=ÌWèêT‹¸÷qÎáƒŸ•q’zWUN«N/ØO^Ÿe|í¾©k{üõ4öV^ïù~G¹êzÂèº|·÷×[’Þ31†rpjg·n Æ0Ý}kåË‹‰nîe¹ËÍ+™ÏVbrOç]'‰¼o®xÎh`¹Ç*±ÙÚ!T$d/$žN>¼Wqá¯…Z9ÑÒO\ÜÛê1o&,-z ~^NCgNÕéá)ÒÊ©7‰¨¯'Õþ¯þ_¿Ehîþóâ €ï¬uÛûý*ÎK9ä.â-öv<²‘×h$àãúW%ö¯~«g-ÕõÀàG~>Zú¾Iš+(šM³ Û#9äl%ðc¬ ûÝ xÖKG´x®|¸¤Ï™O:Ê8Ã’qÉcÔä‚yÇNJyËŒTj¥&µOmztjÿ ?KëaµÔù¯áýóXøãLeb¾tžAÇû`¨êGBAõ¾•:g˜’ù·,þhÀ`¬qÜ` e·~+å[±ý“âYÄjWì—µHé±ø?Nõô>½âX<5 Ç©ÏÑ¼M¶8cÜªXŽÉ^r?¼IróÈS•ZmÇ›™5»òÚÚ7ïu«&|·÷•Î† >[©ÞXHeS$Œyà€ ÷ù²:ò2|óãDf? Z¼PD¶ÓßC(xÆ0|©ßR;ôMsÿ µ´ÔVi¬,Í¹›Ìxâi˜`¹,GAéÇlV§ÄýF×Yø§ê–‘:Ã=ò2³9n±ÉžØÏ@yÎWžæ±Ãàe„ÄÒN ]ïòêìú_Go'¦ŽÑ’_×õÐ¯ðR66þ!›ÑÄ gFMÙ— äžäqôÈ;ÿ eX<#%»Aö‰ãR¤ Í”Ž¹È G&¹Ÿƒ&á?¶Zˆ±keRè Kãnz·ãŠÕøÄÒÂ9j%@®×q±ÜŒý[õ-É$uíè&¤¶9zÇï·Oøï®ÄJKšÖìdü"µˆ[j×²Îc;ã…B(g<9nàÈ¯G½µŸPÓ.´Éfâ¼FŽP 31 ‘ÏR}<3šä~ Ã2xVöî Dr Ç\›}Ý#S÷ÈÀëŽHÆI®à\OçKuäI¹†ó(”—GWî ñ³¹¸æ2¨›‹ºÚû%¾ýÖ_3ºNú¯ëúì|ÕÅÖ‰}ylM’ZËîTÿ á[ðÐñ/ˆ9Àû ¸ón3 MÃ²d‘÷ döª^.ÊñŽ°›BâîNp>cëÏçÍzïÃôÏ YÍ%ª¬·ãÏ-*9ÜÂãhéŒc¾dÈêú¼Ë,. VŠ÷çeÿ n/¡¼äãõâ=‹xGQKx”|¹bÌŠD@2Œ 8'Ž àúƒŽ+áDÒ&¡¨"Œ§–Žr22 Ç·s]ŸÄ‹«ð%ÚÄ<¹ä’(×{e›HÀqÁç©Ç½`üŽÚõKé¥š9ƒÄ±€<–úƒú~ çðñO#Í%iKKlµ¦¾F)'Iê¬Î+Ç(`ñ¾£œdÈ’`™ºcßéé^ÿ i¸”Û\ý¡æhÔB«aq¸}ãÀÆ:ÜWƒ|FÛÿ î©±BŒÇÀeaŸ-sÊ€:úW½ÜÝÜ<%$µ†%CóDªÀí%IÈÏÊ¤…ôäñÞŒ÷‘a0“ôŽÚë¤nŸoW÷0«e¶y'Å»aÎ—2r’# Û°A^ý9ÉQÔõ=ù5¬£Öü.(Þ’M$~V«=éSÄFN½®©ÔWô»ÿ þHžkR‹ìÏ+µµžöê;khÚI¤m¨‹Ôš–âÖçJ¾_Z•’6a”Èô> ÕÉaÕ<%®£2n bQŠå\tÈõUÿ ø»þ‹k15‚ÃuCL$Ý¹p P1=Oøýs¯^u éEJ”–éêŸê½5ýzy›jÛ³á›Ûkÿ ÚOcn±ÛÏîW;boºz{ãžüVÆ¡a£a5½äÎÂks¸J@?1è¿{$ä‘=k”øsÖ^nŒ¦)ÝåXÃíùN1ØõÚOJë–xF÷h¸ Œ"Ž?xäœšü³ì¨c*Fœ¯i;7~ñí×«Ðó¥Ë»3Ãü púw ‰°<Á%»ñž ÿ P+Û^ ¾Ye£ŽCÄŒ„/>˜>•á¶Ìm~&&À>M[hÈÈÿ [Ž•íd…RO@3^Ç(Ê½*¶ÖQZyßþ 1Vº}Ñç?¼O4Rh6R€ª£í¡ûÙ a‚3ß·Õ ü=mRÍ/µ9¤‚0ÑC¼Iè:cŽsÛ¾™x£ÆÐ¬ªÍöË¢ìƒ’W$•€Å{¨ÀPG ÀÀàŸZìÍ1RÉ0´ðxEË9+Éÿ ^rEÕ—±Š„70l¼áË@û.' ¼¹Žz€N3úUÉ<3á×*?²¬‚ä†"Ùc=p íÛ'¡ª1ñ"økJ†HÒ'»Ÿ+ oÏN¬Ã9 dÙãÜ×“ÏâÍ~æc+j·Jzâ7(£ðW]•æ™?nê´º6åwéåç÷N•ZŠíž›¬|?Ðõ?Ñ-E…Â®³ÇV$~X¯/…õ x‘LˆÑÜÚÈ7¦pzãÜüë½ðÄ^õtÝYËÍ7ÉÖÕ8ÏUe# #€r=sU¾/é’E§jRC4mxNÝ´9†íuá»›V‘ ZI€×cr1Ÿpzsøf»¨åV‹ìû`qËLÊIã?\~¼³áËC©êhªOîO»‘ÃmçÛçút×¢x“Z}?Ãœê#b-¤X7õÄò gž zzbº3œm*qvs·M=íúéw}¿&Úª°^Ö×µÏ(ø‡â†Öµƒenñý†×åQáYûœ÷ÇLœôÎNk¡ðÂ‡¼/µ¸n0æÉ0¬ƒ‚üîÉÆvŒw®Sáö”š¯‹-üÕVŠØÙ[$`(9cqƒÔ_@BëqûÙ`Ýæ0;79È?w<ó |ÙÜkßÌ1±Ëã¿ìÒ»ðlìï«ÓnªèèrP´NÏÂš&ŽéöÙ¸÷æ°~-_O'‰`°!RÚÚÝ%]Ø%þbß1'¿ÿ XÕáOöÎŒ·‹¬+Åæ*ÛÛ™0¤ƒOÍÔ`u¯¦ÂaèÐÃÓ«‹¨Ô¥µœ¿¯ÉyÅÙ.oÔôŸ Úx&(STðÝ½¦õ] ’ÒNóÁäÈùr3í·žÚ[™ƒ¼veÈÃ·ÞIõÎGlqÎ=M|«gsªxÅI6 ]Z·Îªä,¨zŒŽÄ~#ØŠúFñî™ªiÉqc©éÐD>Së”‘ GñŽ1éÐ^+ Ëi;Ô„µVÕú»i¯ÈÒ-ZÍ]òÜ˜®ì`bÛÙ¥_/y(@÷qÐúg Ô÷W0.Ø› 6Ò© r>QƒŒ0+Èîzb¨É+I0TbNñ"$~)ÕÒ6Þ‹{0VÆ27œWWñcÄcX×íôûyKZéðªc'iQ¿¯LaWŠŸS\·Š“ÅºÊ¸…ôÙÂí|öÀÇåV|!¤ÂGâÛ[[’ï 3OrÙËPY¹=Î1õ5öåTžÑè Ú64/üö?Zëžk}¬¶éàoá¾á}3“ü]8Éæ¿´n²Žš_6¾pœ)2?úWÓÚ¥¾¨iWúdŽq{*ª1rXŒd…m»‰äcô¯–dâ•ã‘Jº¬§¨#¨®§,df«8ÉÅßN¾hˆ;îÓ=7áùpën®É 6ûJžO2^œÐò JÖø¥²ãÂ›Ò6Ü·‰!wbÍ‚¬O©»õ¬ÿ ƒP=Ä:â¤-&ÙŽ `È9 r9íÏ§zë> XÅ7ƒ5X–krÑ¢L7€ìw}ÑŸNHëŒüþ:2†á¼+u·á÷N/Û'Ðç~ß˜ô«ëh!ónRéeQ´6QÛÿ èEwëÅÒ|¸Yqó1uêyùzð8 ƒŠù¦Ò;¹ä6öi<'ü³„[ÃZhu½ ùÍ¡g‚>r¯×ŠîÌx}bñ2“kê£§oø~›hTèóËWò4|ki"xßQ˜Ï6øÀLnß‚0 ¹Æ{±–¶Öe#¨27È@^Ìß.1N¾œyç€õ†ñeé·Õã†çQ°€=Ì©ºB€Ø8<‚ÃSõ®ùcc>×Ú .Fr:žÝGæ=kÁâ,^!Fž ¬,àµ}%¶«îõ¹†"r²ƒGœüYÕd?aÑÃY®49PyU ÷þ!žxÅm|/‚ãNð˜¼PcûTÒ,¹/Ý=FkÏ|u¨¶«âë…{¤m¢]Û¾ïP>®XãÞ½iÓÁ¾ ‰'¬–6ß¼(„ï— í!úÙäzôë^–:œ¨å|,_¿&š×]uÓÑµÛô4’j”bž§x‘Æ©ã›á,‚[Ã” ÎÞ= î®ˆŒËæ ÀùYÁ?ŽïÚ¼?ÁªxºÕÛ,°1¸‘¿ÝäãØ¯v…@¤åq½ºã œàûââ·z8Xýˆþz~—û»™âµj=Ž â~ãáh@'h¼F#·Üp?ŸëQü-løvépx»cŸø…lxâÃûGÂ·‰¶ø”L£©%y?¦úõÆü-Õ¶¥y`Òl7>q’2üA?•F}c‡jB:¸Jÿ +§¹¿¸Q÷°ív=VÑìu[Qml%R7a×IèTõéŽx¬ ?†š7 1†îã-ˆã’L¡lŽ0OÓ=ÅuˆpÇ•¼3ÛùÒ¶W/!|’wŽw^qÔ×ÏaóM8Q¨ãÑ?ëï0IEhÄa¸X•`a ?!ÐñùQ!Rä ÂžqŽžÝO`I0ÿ J“y|ñ!Îã@99>þ8–+éáu…!ù—ä Ê°<÷6’I®z ÅS„¾)Zþ_Öýµ×ËPåOwø÷þ*üïænÖùmØÝûþ¹=>¦½öî×Jh]¼ç&@§nTŒ6ITÀõ^Fxð7Å3!Ö·aÛ$þÿ ¹ã5îIo:ÈªmËY[’8ÇÓ¾Ç‰*òû¢¥xõ¾¼ú•åk+\ð¯ HÚoŽl•Ûk,¯ ç²²cõÅ{²Z\ ´ìQ åpzŽ3Ôð}ÿ Jð¯XO¡øÎé€hÙ¥ûLdŒ`““ù6Gá^ÃáÝ^Ë[Ñb¾YåŒÊ»dŽ4†2§,;ÿ CQÄ´¾°¨c–±”mºV{«ßÕýÄW\ÖŸ‘çŸ,çMRÆí“l-ƒn~ë©ÉÈê Ü?#Ž•¹ðãSÒ¥ÐWNíà½;ãž)™ÎSÈ9cóLjëµ¿Å«iÍk¨ió¶X‚7÷ƒ€yãnyÏŽëÞ Öt`×À×V's$È9Ú:ä{wÆEk€«†Çàc—â$éÎ.éí~Ýëk}ÅAÆpörÑ¢‡Šl¡ÑüSs‹¨‰IÃ„óÀ×wñ&eºðf™pŒÆ9gŽTø£lñëÀçŽ NkÊUK0U’p ï^¡ãÈ¥´ø{£ÙHp`’ØåbqÏ©äó^Æ: Ž' ÊóM«õz+ß×ó5Ÿ»('¹ð¦C„$˜Å¢_ºÈI?»^äã'ñêzž+ë€ñ-½»´}¡Ë*õ?.xÇ^1ŽMyÇÂ¸&“Â—L–îëöâ7…' bqéÎGé]Ëªâ1$o²¸R8Ã`.q€}sÖ¾C98cêÆÞíïóòvÓòùœÕfÔÚéýuèÖ·Ú Å‚_¤³ÜÛºÆ‘ÃŸ”à×¨ý:×ƒxPþÅÕî-/üØmnQìïGÎŠÙRqê=>¢½õnæ·r!—h`+’;ò3È<“Û©éšóŸx*÷V¹¸×tÈiˆßwiÔÿ |cŒñÏ®3Ö½Ì°‰Ë Qr©ö½®¼ÛoÑÙZÅÑ«Oàµ¯ýw8;k›ÿ x†;ˆJa;‘º9÷÷R+¡ñgŽí|Iáë{ôáo2Ê²9 029ÉÏLí\‰¿¸Ÿb˜ "Bv$£&#ßiê>=ªª©f ’N ëí>¡NXW~5×úíø\‰»½Ï^ø(—wÖú¥¤2íŽÞXæÁ$°eÈ888^nÝë²ñÝÔ^ ÖÚ9Q~Ëå7ï DC¶ÑµƒsËÇè9®Wáþƒ6‡£´·°2\Ý:ÈÑ?(#¨'$õèGJ¥ñW\ÿ ‰E¶—¸™g˜ÌÀ¹;Pv ú±ÎNs·ëŸ’–"Ž/:té+ûË]öJöÓM»ëø˜*‘•^Uý—êd|‰åñMæÔÝ‹23å™6æHùÛ‚ëüñ^…ñ1¢oêûÑEØ.õ7*ÅHtÎp{g<·Á«+¸c¿¿pÓ¾Æby=8É_ÄsÆk¬ñB\jÞÔì••Ë[9Píb‹Bãƒ… =93§ð§LšÛáÖšÆæXÌÞdÛP.0\ãïÛ0?™úJ¸™Ë ”•œº+=<µI£¦í¯õêt¬d‹T¬P=ËFêT>ÍØØ@Ï9<÷AQÌ×»Õ¡xùk",JÎæù±Éç$œŽŸZWH®¯"·UÌQÂ ’ÙÈ]ÅXg<ã ß¨g3-Üqe€0¢¨*Œ$Üƒ ’Sû 8ãŽ¼_/e'+Ï–-èÓ¶¶Õíß[·ÙÙ½îì—¼sk%§µxä‰â-pÒeÆCrú ôÏƒžû=”šÅô(QW‚Õd\ƒæ. \àö¹¯F½°³½0M>‘gr÷q+œ¶NïºHO— ¤ Ü¥Ý”n·J|ÆP6Kµc=Isó}Ò çGš)a=—#vK›åoK§ßóÙ¤¶¿õú…ÄRÚ[ËsöÙ¼Ë•Ë ópw®qœŒ·Ø ùÇâ‹ý‡ãKèS&ÞvûDAù‘É9ŒîqÅ} $SnIV[]Ñ´Ó}ØÜ¾A Ü|½kÅþÓ|EMuR¼.I¼¶däò‚ÃkÆ}ðy¹vciUœZ…Õõ»z¾÷¿n¦*j-É/àœHã\y5 Û ß™ó0—äŸnzôã#Ô¯,†¥ÚeÔ÷ÜÅ´„“'c…<íÝ€<·SŠ¥k§Ã¢éÆÆÙna‚8–=«Êª[Ÿ™°pNî02z“ÔÙ–K8.È’Þî(vƒ2®@ äÈûãçžxäÇf¯ˆu¹yUÕîýWšÙ|›ëÒ%Q^í[æ|éo5ï‚¼ZY•^{96ˆY‚§v*x>âº_|U¹Ö´©tûMÒÂ9PÇ#«£#€ éÉñ‘ƒÍz/‰´-Ä¯¹°dd,Ð‘›p03ƒœ{ç9=+ Ûá§‡¬¦[‡‚êå©º¸#±ß=³ý¿•Õµjñ½HÙh›Û[§ÚýÊöô÷{˜?ô÷·Ô.u©–_%còcAÀ˜’ }0x9Î>žñÇáÍ9,ahï¦Ì2òÓ ñÛAäry$V²Nð ]=$Ž ‚#Ù‚1ƒƒødõMax‡ÂÖ^!±KkÛ‘ «“Çó²FN8+ëÎ{Ò¼oí§[«ÕMRoËeç×[_m/¦¦k.kôgŽxsSÓ´ý`êzªÜÜKo‰cPC9ÎY‰#§^üý9¹âïÞx£Ë·Ú`±‰‹¤;³–=ÏaôÕAð‚÷kêÁNBéÎælcõö®£Fð†ô2Ò¬]ßÂK$ÓÜ®•”/ÊHàã$ä¸÷ëf¹Oµúâ“”’²øè´µþöjçNü÷üÌ¿ xNïFÒd»¼·h®îT9ŽAµÖ>qÁçÔœtïÒ»\È¶ÎîcÞäîó3¶@#ÉIÎ ÔñW.<´’¥–ÑÑ€ÕšA‚ ;†qÓë‚2q ÒÂó$# Çí‡ !Ë}Õ9ÈÎÑÉã=;ŒÇÎuñ+ÉûÏ¥öíeÙ+$úíÜå¨¯'+êZH4ƒq¶FV‹gïŒ208ÆÌ)íÐ±>M|÷âÍãÂ¾"iì‹¥£Jd´™OÝç;sÈúr+ÜäˆË)DŒ¥šF°*3Õ”d{zÔwºQ¿·UžÉf†~>I+ŒqÔ`ð3œ“Ü×f]œTÁÔn4“ƒø’Ýßõ_«*5šzGCÊ,þ+ê1Ã²÷O¶¸cœºb2yÇ;cùÕ£ñh¬›áÑŠr¤ÝäNBk¥—á—†gxšX/ì‘˜hŸ*Tçn =ûã¦2|(ð¿e·ºÖ$ ýìŸ!'åÎ°yîî+×öœ=Y:²¦ÓÞ×iü’—ü -BK™£˜›âÆ¡&véðõ-ûÉY¹=Onj¹ø¯¯yf4·±T Pó`çœ7={×mÃ/¢˜ZÚòK…G½¥b„’G AãÜœ*í¯Ã¿ IoæI¦NU8‘RwÈã;·€ Û×ëÒ”1Y •£E»ÿ Oyto¢<£Áö·šï,ä‰§ûA¼sû»Nò}¹üE{ÜÖªò1’õÞr0â}ÎØ#>à/8ïéÎ~—áÍ#Ã±Îlí§³2f'h”?C÷YËdð:qëõÓ·‚ïeÄ© ÔÈØÜRL+žAÎ3¼g=åšó³Œt3 ÑQ¦ùRÙßE®¼±w_;þhš’Sirÿ ^ˆã¼ià©‡|RòO„m°J/“$·l“ ÇÓ¿ÿ [ÑŠÆ“„†Õø>cFÆ6Ø1ƒ– àz7Ldòxäüwá‹ÝAXùO•Úý’é®ähm •NÀ±ÌTÈç ƒ‘I$pGž:‚ÄbêW¢®œ´|¦nÍ>¶ÖÏ¢§ÎÜ¢ºö¹•%ÄqL^öÛKpNA<ã¡ …î==ª¸óffËF‡yÌcÉ ©ç$ð=ñÏYþÊ’Ú]—¥‚¬‚eDïÎH>Ÿ_ÌTP™aÂ‰ch['çÆÜò7a‡?w°Ïn§âÎ5”’¨¹uÚÛ|´ÓÓc§{O—ü1•ªxsÃZ…ÊÏy¡Ã3¸Ë2Èé» ‘ƒÎ äžÜðA§cáOéúÛ4ý5-fŒï„ù¬ûô.Ç Üsž•Ò¾•wo<¶Ÿ"¬¡º|£ î2sÇ¡éE²ÉFÑ±rU°dÜ6œ¨ mc†Îxë×ºÞ'0²¡Rr„{j¾í·è›µ÷)º·å–‹î2|I®Y¼ºÍË·–ÃÆàã£'óÆxƒOÆÞ&>\lóÌxP Xc¸ì Sþ5§qà/ê>#žÞW¸if$\3 ® ûÄ“ùŽÕê¾ð<Ó‹H¶óÏ" å·( á‘€:ã†8Ï=+ê¨¬UA×ÃËÚT’ÑÞöù¥¢]{»ms¥F0\ÑÕ—ô}&ÛB´ƒOŽÚ+›xíÄÀ1 ,v± žIëíZ0Ç§™3í2®0à¸—p9öÝÔž)ÓZËoq/Ú“‘L ²ŒmùŽï‘Ó9§[Û#Ä‘\ÞB¬Çs [;à à«g‚2ôòªœÝV§»·¯/[uó½õÛï¾ /šÍ}öüÿ «=x»HŸÂÞ.™ ÌQùŸh´‘#a$‚'¡u<Š›Æ>2>+ƒLSiöwµFó1!eg`£åœ ÷ëÛö}Á¿ÛVÙêv $¬ƒ|,s÷z€ðÎƒ¨x÷ÅD\ÜŒÞmåÔ„ ˆ o| :{ÇÓ¶–òÁn!´0Ål€, ƒ ( ÛŒŒc¶rsšæ,4‹MÛOH!@¢ ÇŽ„`å²9ÝÃw;AÍt0®¤¡…¯ØÄ.Àìí´ƒ‘ßñ5Í,Óëu-ÈÔc¢KÃÓ£òÖÌºU.õL¯0…%2È—"~x ‚[`có±nHàŽyàö™¥keˆìŒÛFç{(Ø©†`Jã#Žwg<“:ÚÉ;M ^\yhûX‡vB·÷zrF?§BÊÔ/s<ÐÈB)Û± ·ÍÔwç5Âã:så§e{mÑ¤ï«Òíh—]Wm4âí¿ùþW4bC3¶ª¾Ùr$pw`àädzt!yŠI„hÂîàM)!edŒm'æ>Ç?wzºKìcŒ´¯Ìq6fp$)ãw¡éUl`µ»ARAˆÝÕgr:äŒgƒéé[Ôö±”iYs5Ýï«ÙG—K=þF’æMG«óÿ `ŠKÉ¦uOQ!ÕåŒ/ÎGÞ`@ËqÕzdõâ«Ê/Ö(ƒK´%ŽbMüåÜŸö—>¤óŒŒV‘°„I¢Yž#™¥ùÏÊ@8 œgqöö5ª4v×“[¬(q cò¨À!FGaÁõõ¯?§†¥ÏU½í¿WªZ$úyú½Žz×§Éþ?>Ã×È•6°{™™ŽÙ.$`ÎUœ…çè ' ¤r$1Ø(y7 ðV<ž:È ÁÎMw¾Â'Øb§øxb7gãÐž½óÉÊë²,i„FÈ¹£§8ãäÂ½k¹¥¦ê/ç{ïêï¦‡2œ/«ü?¯Ô›ìñÜ$þeýœRIåŒg9Ác’zrrNO bÚi¢ ÑºË/$,“ª¯Ýä;Œ× ´<ÛÑn³IvŸb™¥ nm–ÄŸ—nÝÀãŽ3ëÍG,.öó³˜Ù£¹uÊÌrŠ[<±!@Æ:c9ÅZh ì’M5ÄìÌ-‚¼ëÉùqŽGì9¬á ;¨A-ž—évþÖ–^ON·Ô”ŸEý}ú×PO&e[]ÒG¸˜Ûp ƒÃà/Ë·8ûÀ€1ž@¿ÚB*²¼ñì8@p™8Q“žÆH'8«I-%¸‚ F»“åó6°Uù|¶Ú¸ã ò^Äw¥ŠÖK–1ÜÝK,Žddlí²0PÀü“×ükG…¯U«·¶–´w¶ŽÍ¾©yÞú[Zös•¯Á[™6° ¨¼ÉVæq·,# ìãï‘×8îry®A››¨,ãc66»Ë´ã'æÉù?t}¢æH--Òá"›|ˆ¬[í 7¶ö#¸9«––‹$,+Ëqœ\Êøc€yê^Ý¸Äa°«™B-9%«×®‹V´w~vÜTéê¢·þ¼ˆ%·¹• ’[xç•÷2gØS?6åÀÚ õ9É#š@÷bT¸º²C*3Bá¤òÎA9 =úU§Ó"2Ãlá0iÝIc‚2Î@%öç94ùô»'»HÄ¥Ô¾@à Tp£šíx:úÊ:5eºßMý×wµ›Ó_+šº3Ýyvÿ "ºÇ<ÂI>Õ1G·Ë«È«É# àÈÇ øp Jv·šæDûE¿›†Ë’NFr2qŸ½ÇAÜšu•´éí#Ä¦8£2”Ú2Ã/€[ÎTr;qŠz*ý’Îþ(â‰ ;¡TÆâ›;ºÿ àçœk‘Þ8¾Uª¾íé{^×IZéwÓkXÉûÑZo¯_øo×È¡¬ â–ÞR§2„‚Àœü½ùç® SVa†Âüª¼±D‘ŒísŸàä|ä2 æ[‹z”¯s{wn„ÆmáóCO+†GO8Ïeçåº`¯^¼ðG5f{Xžä,k‰<á y™¥voÆ éÛõëI=œ1‹éíÔÀÑ)R#;AÂncäŽ:tÏ#¶TkB.0Œ-ÖÞZÛgumß}fÎJÉ+#2êÔP£žùÈÅi¢%œ3P*Yƒò‚Aì“Ž2r:ƒÐúñiRUQq‰H9!”={~¼“JŽV¥»×²m.ÛßºiYl¾òk˜gL³·rT• ’…wHÁ6ä`–Î3ùÌ4Øe³†&òL‘•%clyÃ®AÂäà0 žüç$[3uÅ˜î¹•pNOÀÉ=† cï{rYK ååä~FÁ •a»"Lär1Ó¯2Äõæ<™C•.fÕ»è¥~½-¿g½Â4¡{[ør¨¶·Žõäx¥’l®qpwÇ»8ärF \cŽ¸ÜÆÓ-g‚yciÏÀ¾rÎwèØÈ#o°Á9ã5¢šfÔxÞæfGusÏÌJÿ µ×œ/LtãÅT7²¶w,l É³;”eúà·¨çîŒsÜgTÃS¦^ '~‹®›¯+k÷ZÖd©Æ*Ó[Ü«%Œk0ŽXƒ”$k#È¨ P2bv‘ƒŸáÇ™ÆÕb)m$É*8óLE‘8'–ÜN Úyàúô+{uº±I'wvš4fÜr íì½=úuú sFlìV$‘ö†HÑù€$§ õ=½¸«Ž] :Ž+•¦ïmRþ½l´îÊT#nkiøÿ _ðÆT¶7Ò½ºÒ£Î¸d\ã8=yãŽÜäR{x]ZâÚé#¸r²#»ÎHÆ6õ ç® ÎFkr;sºÄ.&;só±Ç9êH÷ýSšÕtÐU¢-n Ì| vqœ„{gŒt§S.P‹’Ž‰_[;m¥ÞZýRûÂX{+¥úü¼ú•-àÓ7!„G"“´‹žƒnrYXã¸îp éœ!ÓoPÌtÑ (‰Þ¹é€sÓ#GLçÕšÑnJý¡!‘Tä#“ß?îýp}xÇ‚I¥Õn#·¸–y'qó@r[ Êô÷<ÔWÃÓ¢áN¥4Ô’I&Ý¼¬¬¼ÞºvéÆ FQV~_ÒüJÖÚt¥¦Xá3BÄP^%ÈÎW-×c¡ú©¤·Iþèk¥š?–UQåIR[’O 5x\ÉhÆI¶K4«2ùªŠŒ<¼óœçØ`u«‚Í.VHä€ Ëgfx''9ÆI#±®Z8 sISºku¢ßÞ]úk»Jößl¡B.Ü»ÿ MWe °·Ž%šêÉ†¼»Âù³´œ O¿cÐÓÄh©"ÛÜÏ.ÖV’3nüÄmnq[ŒòznšÖ>J¬òˆæ…qýØP Ž:ä7^0yëWšÍ_79äoaÈ °#q0{ää×mœy”R{vÒÞ¶ÚÏe¥“ÚÆÐ¥Ì®—õýjR •íç›Ìb„+JyÜØÙ•Ç]¿Ôd þËOL²”9-Œ—õÃc'æÝ×œçÚ²ìejP“½ âù°¨†ðqòädÐƒÉäÖÜj÷PÇp“ÍšŠå«‘î <iWNsmª»¶vÓz5»ûì:Rs\Ðßôû×uÔÿÙ