I recently released interlude which is available at pypi. See also my blog post.

In short: it allows to write…

>>> interact(locals())

… in your doctest and it jump into interactive mode. It feels like youre in the doctest and different from pdb. You can just copy paste from interactive mode into the test.

You can enable ELLIPSIS = True for every test automatically by passing optionflags=doctest.ELLIPSIS to testmod(), but it is ugly.

Thanks for the info, I’ll give a shot

I use IPython. It solves quite some problems:

• allows for pasting doctests and evaluating them (IPython.dtutils.idoctest), optionally

• raising a exception on the first failure

• doing a post-mortem pdb automatically

• executing the doctest in a separate namespace

• switching to a “normal” prompt (ipython normally has a fancy, colored, history-enabled prompt), so you can paste code from the interpreter to a doctest. One might consider this not a new feature, because the standard interpreter has this too :P

Btw, you can invoke a IPython-enabled pdb by using http://pypi.python.org/pypi/ipdb and:

from ipdb import settrace; settrace()

I like IPython :)

Stefan.

Me too, which is why I put them in setup.cfg and/or ~/.noserc:

[nosetests]
with-doctest=1
doctest-extension=.txt

“see http://www.gawel.org/weblog/2008/07/nose-doctest-plugin-sucks … I think Nose could be enhanced there.”

Unfortunately, I don’t speak French, so I’m only guessing that the post there is complaining about the lack of support in the doctest plugin for fixtures. If that’s the case, some support is scheduled for the next nose release:

http://code.google.com/p/python-nose/issues/detail?id=60

You can find the current state of fixture support in the ticket-93 branch in nose’s svn. If you find it still too sucky, patches are always welcome.

>>> import pdb; pdb.set_trace(); foo()

And once you step out of foo(), you can still step through the doctest, but stupidly you can’t see what line you’re on. This sucks.

• Stuff like pdb.set_trace() is good, but it’s better when you can do it when the test fails (what zope.testing and nose can do with options). Interaction isn’t part of the test, it’s part of the testing process.

• Something I forgot to mention: REPORT_UDIFF also has this problem. You have to put the option into the test to see the diff’d output, but it’s really part of the testing process, something you apply when you can’t quickly see the differences in output.

• REPORT_ONLY_FIRST doesn’t work: it still runs all the other examples, it just doesn’t report them. This is often fine, but sometimes I really want to abort the test. A common example would be a database-oriented set of tests, when I can’t open the database connection. Sometimes when testing destructive file operations it’s actually dangerous to continue the test if you can’t confirm that you are in a safe scratch area.

[1] https://launchpad.net/zope.testing