[IPython-user] Using doctest in IPython

Fernando Perez fperez.net@gmail....
Sun Aug 12 19:57:16 CDT 2007


On 6/21/07, Ethan Kennerly <kennerly@finegamedesign.com> wrote:
> I like the features that IPython has:
> http://www.onlamp.com/pub/a/python/2005/01/27/ipython.html?page=1
>
> I like how it reloads modules, and how it feels side-by-side with gVim for
> editing Python code.
>
> But there's two gotchas that have been frustrating my effort to use IPython,
> which made it more troublesome than beneficial to my work style.
>
> 1)  I don't know how to make IPython use a doctest.  When I try, the output
> becomes conflated with the interpreter's output.
> IDLE handles doctest correctly.  Is there a configuration option or
> workaround for IPython to handle a standard doctest?  (I'm not interested in
> discussing the virtues of unittest over doctest at this time.)

This should now be fixed, see my recent message.

> 2)  Related to the first, to troubleshoot code, I place a breakpoint in the
> doctest, which works with pdb in IDLE.  How would I go about this in
> IPython?

There may be more ways than this, but off the top of my head:

- Paste the doctest chunk that fails into ipython with %doctest_mode
enabled.  The failure will be at the top-level, and you can play with
the problem interactively to understand what's going on.

- The recently announced SnakeOil

http://lists.ipython.scipy.org/pipermail/ipython-dev/2007-August/003084.html

has a test runner (the main 'oiltest' script) whose -d flag will cause it to:

- Fire up IPython's ipdb debugger inside an uncaught exception in doctest code.
- Fire up an interactive IPython inside a doctest that fails, with the
locals as its current namespace.

Just to be clear, with -d you get: errors -> ipdb, failures->ipython.

That code is new and raw, so the user-facing interface isn't very
polished yet (for now, doctest files must be listed in a test_X.py
wrapper).  But the functionality is all there, it's just a matter of
getting some user feedback on exactly what the most convenient
high-level entry points would be, so that it meshes well with a
non-ipython doctest workflow.  Ideally using SnakeOil would only ADD
functionality and features, but be otherwise 100% compatible with
existing plain doctest setups.  Feedback welcome.

> I looked at the archives and found a suggestion:
> http://lists.ipython.scipy.org/pipermail/ipython-user/2007-January/004017.ht
> ml
>
> But that did not modify the error.  I noticed that I am using Windows and
> saw that pyreadline needed a workaround.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1708316&group_id=54
> 70&atid=105470
>
> I looked at the workaround for pyreadline, but I'm afraid I need a little
> more verbose help than that.  And it seems untenable to hack the sys module
> after the doctest is loaded.

I honestly don't know if the win32 problem remains, since I don't use
the platform myself.  Jorgen (our PyReadline lead) might have comments
on that front.  It would certainly be nice for the doctest fixes to
work under all OSes.

Note that hacking into sys is pretty commonplace, and ipython already
does a fair bit of it (as well as hacking into doctest, and probably a
few others).  So as long as you're using ipython, you're already using
that 'untenable' approach :)

Cheers,

f


More information about the IPython-user mailing list