mirror of
https://github.com/python/cpython.git
synced 2025-08-01 23:53:15 +00:00
Merged revisions 81634 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk ........ r81634 | r.david.murray | 2010-05-31 21:42:41 -0400 (Mon, 31 May 2010) | 2 lines #7583: clarify discussion of hard tab expansion in doctests. ........
This commit is contained in:
parent
ab4fd61b60
commit
9691e59d77
1 changed files with 17 additions and 6 deletions
|
@ -282,11 +282,8 @@ their contained methods and nested classes.
|
||||||
How are Docstring Examples Recognized?
|
How are Docstring Examples Recognized?
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
In most cases a copy-and-paste of an interactive console session works fine, but
|
In most cases a copy-and-paste of an interactive console session works fine,
|
||||||
doctest isn't trying to do an exact emulation of any specific Python shell. All
|
but doctest isn't trying to do an exact emulation of any specific Python shell.
|
||||||
hard tab characters are expanded to spaces, using 8-column tab stops. If you
|
|
||||||
don't believe tabs should mean that, too bad: don't use hard tabs, or write
|
|
||||||
your own :class:`DocTestParser` class.
|
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
@ -317,6 +314,21 @@ The fine print:
|
||||||
blank line, put ``<BLANKLINE>`` in your doctest example each place a blank line
|
blank line, put ``<BLANKLINE>`` in your doctest example each place a blank line
|
||||||
is expected.
|
is expected.
|
||||||
|
|
||||||
|
* 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
|
||||||
|
:const:`NORMALIZE_WHITESPACE` option or directive 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 :class:`DocTestParser` class.
|
||||||
|
|
||||||
|
.. versionchanged:: 2.4
|
||||||
|
Expanding tabs to spaces is new; previous versions tried to preserve hard tabs,
|
||||||
|
with confusing results.
|
||||||
|
|
||||||
* Output to stdout is captured, but not output to stderr (exception tracebacks
|
* Output to stdout is captured, but not output to stderr (exception tracebacks
|
||||||
are captured via a different means).
|
are captured via a different means).
|
||||||
|
|
||||||
|
@ -1778,4 +1790,3 @@ several options for organizing tests:
|
||||||
.. [#] Examples containing both expected output and an exception are not supported.
|
.. [#] 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
|
Trying to guess where one ends and the other begins is too error-prone, and that
|
||||||
also makes for a confusing test.
|
also makes for a confusing test.
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue