doctest module need to parse -h/--help parameters, and accept flags like ELLIPSIS from command line. Otherwise it very hard to debug tests like contained in the attached README.

It is also worth to make it parameter compatible with unittest.main()

Usage: tests.py [options] [test] [...]

Options:
  -h, --help       Show this message
  -v, --verbose    Verbose output
  -q, --quiet      Minimal output
  -f, --failfast   Stop on first failure
  -c, --catch      Catch control-C and display results
  -b, --buffer     Buffer stdout and stderr during test runs

Here is a patch that implements the ones I'm interested in (-o for any option, and -f as a shortcut for -o FAIL_FAST).  It's a good question whether doctest should support other unittest options, but doing so is more complicated than supporting -o and -f.

Adding a couple people to nosy who have an interest in testing and doctest, hoping for a patch review :)

Oh, a documentation update is still needed here, so I guess I'm not really ready for review yet :(

Patch updated with documentation.

I will probably commit this tomorrow if there are no objections.

Patch updated per Barry's review comments.

New changeset ae802dc4dcd4 by R David Murray in branch 'default':
#11390: convert doctest CLI to argparse and add -o and -f options.
http://hg.python.org/cpython/rev/ae802dc4dcd4

Committed.  Thanks for the review, Barry.

The new tests added in changeset ae802dc4dcd4 are failing on some buildbots. I can reproduce the issue on my Linux box (Fedora 18). First failure of "./python -m test test_doctest":

[1/1] test_doctest
**********************************************************************
File "/home/haypo/prog/python/default/Lib/test/test_doctest.py", line 2627, in test.test_doctest.test_CLI
Failed example:
    rc1, out1, err1
Expected:
    (0, b'', b'')
Got:
    (0, b'\x1b[?1034h', b'')

The b'\x1b[?1034h' sequence it written by the readline module when it is imported. The readline module is imported by pdb, which is used by doctest.

The following article proposes set to TERM environment variable to "linux" to workaround the issue:
http://reinout.vanrees.org/weblog/2009/08/14/readline-invisible-character-hack.html

It works:

$ echo $TERM  # yeah, Fedora supports 256 colors!
xterm-256color
$ ./python -c 'import readline'|hexdump -C
00000000  1b 5b 3f 31 30 33 34 68                           |.[?1034h|
00000008
$ TERM=linux ./python -c 'import readline'|hexdump -C

This issue was reported to OpenSuse in 2009:
http://lists.opensuse.org/opensuse-bugs/2009-05/msg01633.html

The issue is not specific to Python. Just one another example with Octave (issue closed as "not a bug"):
https://bugzilla.redhat.com/show_bug.cgi?id=304181

The issue was also reported upstream (bug-readline mailing list) a few days ago:
http://lists.gnu.org/archive/html/bug-readline/2013-06/msg00000.html

Attached doctest_term_dummy.patch: workaround the issue by setting TERM env var to "dummy".

Why is test_CLI() implemented using a doctest? Why not reusing the unittest module to benefit from test.support and test.regrtest? (Hint: I don't like doctests :-))

test_doctest.test_CLI() is also failing on Windows:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1078/steps/test/logs/stdio

It looks like an issue with Windows newline (\r\n) versus UNIX newline (\n). test_CLI() decodes the bytes output from UTF-8, but do not normalize newlines.

The universal_newlines=True option can be passed to subprocess, which is not possible currently using script_helper. Is there function somewhere else to normalize newlines?

It is implemented as a doctest because everything else in that test module is implemented as a doctest.  And clearly this reveals a bug of some sort.  Perhaps the dummy trick needs to be done by doctest itself?  (I will need to read your post over more carefully and understand the issue better.)

As for the windows failures, my apologies.  I knew I would need to check windows after the commit when I wrote the code, but I forgot to actually do it.

> As for the windows failures, my apologies.  I knew I would need to check windows after the commit when I wrote the code, but I forgot to actually do it.

No problem, it's so easy to forget Windows :-) And we have buildbots
for this task (detect regressions).

2013/6/25 R. David Murray <report@bugs.python.org>:
>
> R. David Murray added the comment:
>
> It is implemented as a doctest because everything else in that test module is implemented as a doctest.  And clearly this reveals a bug of some sort.  Perhaps the dummy trick needs to be done by doctest itself?  (I will need to read your post over more carefully and understand the issue better.)
>
> As for the windows failures, my apologies.  I knew I would need to check windows after the commit when I wrote the code, but I forgot to actually do it.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11390>
> _______________________________________

> Perhaps the dummy trick needs to be done by doctest itself?

The issue really comes from the readline module. The workaround is to set an environment variable, which affects the whole process (all threads).

Only setting TERM for test_CLI() is fine, because it's the only test running doctest in a subprocess.

Hum, we may set TERM=dummy in script_helper directly, because this module tries to run Python in a fresh environment. It uses "python -E" for example.

New changeset 8f22e03f5f07 by R David Murray in branch 'default':
#11390: fix test failures due to readline and windows lineneds.
http://hg.python.org/cpython/rev/8f22e03f5f07

Fixed for this test.  It would probably be worthwhile to improve script_helpers, I'll open a new issue for that.