[IPython-user] IPython.fronend progress

Fernando Perez fperez.net@gmail....
Fri Jun 20 02:25:50 CDT 2008

Hey Barry,

sorry for the delay in replying, I've had a semi-drafted reply for days...

On Sun, Jun 15, 2008 at 3:32 PM, Barry Wark <barrywark@gmail.com> wrote:

> The purpose of IPython.frontend is to provide a base class
> (frontend.frontendbase.FrontEndBase) for frontend writers to use in
> developing GUI frontends for IPython. FrontendBase provides all of the
> basic functionality required by the front end (testing for block
> completeness, managing history, executing blocks on an
> IPython.kernel.engineservice.IEngineBasic-implementing engine, and
> rendering results and errors asynchronously (via Twisted deferreds)).
> GUI frontends will want to subclass FrontEndBase and override the
> render methods (render_result and render_error) to render results and
> errors respectively. Each execute request can be assigned a "blockID"
> to allow the frontend to identify the block corresponding to the
> result/error. The frontend can assign this blockID or a UUID will be
> assigned automatically. Frontends may also override update_prompt to
> update the input prompt for a block once it's number is known (it may
> not be known until the engine executes the block if more than one
> client is using the same engine). The subclass must also decide when
> to send a block to the engine. For this, FrontEndBase provides
> is_complete to test whether a block is a complete statement. Once a
> block is complete, the frontend can send it to the engine by passing
> it to FrontEndBase's execute method. The result of execute is a
> twisted.internet.deferred.Deferred result of the execution of that
> block.

I think I mostly agree with your approach so far, but there's a point
that I'd  like to clarify.  I just spoke with Brian and he mentioned
you'd discussed this already at length,  so perhaps I'm just
misunderstanding slightly your angle in the above pargraph.

It seems to me, from this description, that you intend the
FrontEndBase class itself to have a twisted core to it and to return
deferreds everywhere.  Am I reading that  correctly?  I don't think
this is the direction we want to go in,  since in the end there's a
use case for a non-twisted, pure terminal client that can be installed
just on top of the python stdlib and nothing more.  We have that
today and I think we can continue to maintain that.  (As for building
full-fledged GUI or network-aware clients, then  definitely I agree
that twisted is our first and foremost dependency,  no problem there).

I'm right now mostly working on teaching Nose about all of ipython's
peculiarities regarding testing, so that we can do this refactoring
you're headed towards on the existing codebase.  But I want to make
sure that we don't stall you out.



More information about the IPython-user mailing list