[IPython-User] Doctest checker in IPython notebook

Fernando Perez fperez.net@gmail....
Fri Nov 2 16:13:42 CDT 2012

On Fri, Nov 2, 2012 at 3:29 AM, Catherine Devlin
<catherine.devlin@gmail.com> wrote:
> Thanks, everybody!  After a bunch of tweaking to get it to work as a
> decorator, I uploaded to PyPI:
> http://pypi.python.org/pypi/ipython_doctester
> I'd be happy to work toward inclusion in IPython itself, of course! - and
> I'm open to suggestions about what else should be done to make that
> possible.  I do want to let it take an argument so that you can decorate
> with @test(show_successes=True) to get each successful example reported even
> in an overall test success, or @test(show_successes=false) to never say
> anything about tests that succeed (like doctest itself).  But my first pass
> at implementing that failed, and I wanted to get this out there.

This is great, thanks!

My suggestion would be to keep it separate for a little while, until
you get some feedback from users and your APIs stabilize.  It's much
easier for you to manage a small project by itself than to integrate
into the much larger body of code that's IPython itself.

Once: (a) you are happy with the code and API and that it's reasonably
stable and robust, tested, etc;  (b) the project has a reasonable user

we can certainly look into the best way of making it available inside IPython.

But in general, what we are trying to do is find ways to make it as
easy as possible for third-party projects to integrate with the
IPython APIs and user experience without forcing everyone to bundle
their code with ours.  While it may appear attractive at first to have
your project bundled with IPython, in reality it may be more trouble
than it's worth: your release cycle inevitably slows down as it
becomes locked with ours and you will have to coordinate more of your
work with the rest of the core team.  This adds communication overhead
to everyone's life, without necessarily a net benefit.

In some cases it makes sense for tools to go into the core project, of
course.  nbconvert is a perfect example of a project that's currently
separate but that we want bundled in, as it touches the very core of
notebook management.

But for other tools, living outside of the core may actually be  the
better option in the long run.  What we do want to do is to find ways
to make it very easy for users to (a) become aware of these tools (b)
start using them.



More information about the IPython-User mailing list