[IPython-dev] Status of pre-0.10 reviews and merges

Ville M. Vainio vivainio@gmail....
Wed Apr 1 01:04:19 CDT 2009


On Wed, Apr 1, 2009 at 1:23 AM, Fernando Perez <fperez.net@gmail.com> wrote:

> I know we've talked a bit about this, but before we get started on
> this major reorganization, let's make sure we do plan it carefully.
> For better or worse, while ipython is formally 'pre 1.0' and as such,
> all API changes are in principle fair game, we need to ensure we find
> a good balance of practicality vs purity.  Just like numpy kept some

My thought here would be that the right way to go is extending thi
IPApi, not replacing it. There is no need to remove hooks, for
example.

It should be possible to do everything via IPApi, including the stuff
that uses InteractiveShell directly now. One important facet it
providing a good api for completer (should be quite easy, actually,
but would benefit from refactoring of completer). If something seems
like it will break ipapi (incl. hooks), postpone it and fix something
else. Code that used an underlying InteractiveShell instance can be
refactored to use a (new) IPApi call, but blatant breakage of ipapi
just shouldn't be necessary.

> parts.  But now that with ipdoctest in place it is *trivial* to write
> tests against that functionality, it would be possible to protect the
> code better with tests *before* diving in, so that at least there's a
> safety net to catch us if we fall.

Last time I tried writing unit tests for user facing parts, the tests
caused garbage to appear on screen. I haven't bothered with the branch
since. Does ipdoctest solve this problem so that it can actually be
used to write unit tests for the interactive part of ipython (almost
none of which is currently covered)?

However, I do think that getting paid time to refactor ipython is so
precious an opportunity that nothing should hold it back. The damage
can be fixed later, but every delay in actually getting down to work
should be avoided at all cost.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


More information about the IPython-dev mailing list