[IPython-dev] Moving forward with the frontends
Mon Jun 23 15:26:18 CDT 2008
On Mon, Jun 23, 2008 at 11:16 AM, Gael Varoquaux
> Hi all,
> This is just a heads up to say that I have been allowed to devote some of
> my day work's time to working on a frontend for iPython. We want to
> integrate IPython in Mayavi and other similar projects. The requirements
> * We want something fast, not after three months of work
> * We do not want it multithreaded. The reason being that this shell will
> be used to manipulate existing Wx objects. As Wx is not multithreaded,
> we cannot execute the code the user enters in a separate thread. As we
> want to manipulate objects displayed by the GUI, we cannot run in a
> seperate process. In the long run we can think of a "%bg" like magic
> to execute in a seperate thread, but on the short term I will make my
> life easier and run everything in one thread.
I don't want to sound like a broken record and I don't have personal
pride staked on this solution so it's OK if you choose otherwise, but
I think going with a Twisted-based approach is the right plan. I would
look forward to working with you to make FrontEndBase work for your
use. There's a WX reactor for Twisted so we can guarantee that code
gets executed in the WX runloop thread. Using Twisted's deferToThread
(eg. via IPython.kernel.engineservice.ThreadedEngineService) makes it
possible for long-running code to not block the UI.
> * We are interested in wx. I am of course happy sharing the code with
> other frontends, but I will not be developping them.
> * The feature of ipython we are interested in are magics, "?" and "??",
> tab completion, history, and alike...
As soon as we can refactor the IPython 0.8 core so that it plays
nicely with the IPython.kernel.engineservice.IEngineBase interface,
all frontends could get this behavior for free. If you can't wait for
that refactoring, going with the existing Wx frontend is your only
option at this point.
> I am currently reviewing the existing code. I see three code bases for
> front end:
> * Laurent Dufrechou's WxIpython, living in the trunk, in
Like I said above, this is the only option if you can't wait for the
refactoring of the current core to work with I.k.e.IEngineBase 
> * Barry Wark's cocoa frontend, living in a separate branch;
As we discussed in a separate thread, this will hoepfully be merged
into trunk soon.
> * The code Fernando, Eric Jones and myself started a year ago, living
> * in the old ipython1 branch (in ipython1/frontend).
The frontend that I will merge into trunk does not include your
original code. I would like to revisit whether your line-oriented
approach could be incorporated into a FrontEndBase subclass
specifiically for line-oriented frontends.
> >From a first quick review, they all have there stength and their
> weakness. I am probably going to take from all three. I have not decided
> where my effort will live.
> I will keep on review the code, and exploring better the ipython
> codebase. I am interested in any pointers you have, or advice on how to
> move forward. I will keep the list posted as things move along.
> IPython-dev mailing list
More information about the IPython-dev