[IPython-dev] Refactoring prefilter and ipython1

Fernando Perez fperez.net at gmail.com
Tue Mar 6 13:34:06 EST 2007

On 3/6/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
> Dan has been looking at refactoring prefilter lately - this began with
> a very nice test suite for the existing one.  I have a question about
> this.
> Should Dan's target be to rework the prefilter that is in trunk?  Or
> should he focus on implementing something from scratch that may have a
> completely different architecture (than prefilter).  This approach
> would be more focused on moving the prefilter capabilities from trunk
> over to ipython1.  This second approach would allow us to start anew
> and really think about how ipython does input parsing.  For instance,
> it may make sense to build something that doesn't even have a
> "prefilter" method that resembles the current one.
> The current class (that prefilter is a part of) began as a subclass of
> code.InteractiveConsole.  But as we move forward with ipython1, there
> is no reason to hold to that tradition.  In fact, it may make more
> sense to move away from that - especially as the old version is
> inextricably tied to the terminal - a constraint which ipython1
> cant'/won't have.  Also, the configuration system that ipython1 uses
> is completely different that the hooks that are in trunk.
> I can see advantages of both options here.  What do people think?

Sorry I've been a bit quiet for the past few days, a combination of
super-busy and a cold hasn't helped.

Here's how I see things currently: we have a bunch of accumulated
things in the pipeline for trunk, patches people have sent, small bug
reports, etc.  I created a 0.7.4 milestone, tentatively setting the
date to April 1:


It would be great if the trunk guys could help us flush everything
they can on that front; I'll be doing my part as well with any patches
I can take care of myself.

Ville, if that date doesn't work for you, go ahead and edit the
milestone and reset it.

For this to happen, I'd encourage everyone who has something pending
that might fall through the cracks to make a ticket for it, and assign
it to this milestone.  It's the only way for us to ensure we won't

If we can release 0.7.4 early April, I would then make that release
the code that will become the core component in ipython1.  I (probably
will) have a course to teach using Python in mid-April, so I'd like to
have a stable release for that workshop, and after finishing I hope to
be able to make a quick transition.  At this point I'd make an effort
to make the transition as fast as possible, because code living in
limbo is /very bad/ for a project: people stall out, feel there's no
place to contribute, and lose interest.  I'm aware of that danger.

So my plan is not necessarily to make a grand, super-complicated
reorganization of the code right off the bat.  I simply would like to
move the current trunk code into ipython1, break up the bigger messes
into little more digestible ones (ipmaker, ipythonrc handling, Magic,
etc) and abstract out all console i/o assumptions.  That would give us
a codebase which would be very similar to the current one, but with
the key problems broken up into smaller chunks that hopefully can then
be tackled one at a time.

We have an ipython sprint planned in Boulder for April, and that
sprint would be a great opportunity to move ahead with this

To address Dan's questions about prefilter more specifically: my
biggest worry is not to stall a potential contributor.  It's a bit
late, I think, for a radical reorganization a few weeks before a
release.  But if you can keep that work in a private copy for a while
and move ahead, that would be great.  We can then try to merge the lot
in a few weeks.  If this proves to be a big hassle, we can look into
exposing SVN as a mercurial repo so any developer can have his own
tree.  I've thought about this before, it's just that I don't want to
add more process-related work at this point, else we won't get any
actual work done.

How does that sound for everyone?



More information about the IPython-dev mailing list