[IPython-dev] prefilter reorg status

Fernando Perez fperez.net at gmail.com
Fri May 4 15:34:50 EDT 2007


On 5/4/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/3/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > At this point, it's probably worth starting to put this code into the
> > new work branch.  Here we've put the results of this weekend's sprint:
>
> If the code is already done for ipython trunk, why not put it there also?

In fact, if Dan already wrote the code, his patch will probabl apply
to trunk but not quite to ipython1/core1.  I modified the code quite a
bit, so it's likely that an as-is patch won't apply anymore.

> I have to admit that I'm totally out of the loop regarding ipython1 -
> I'd like to see a the advantages of cleaner codebase with the current
> single-process ipython.

It's important to note that we WILL have a single-process ipython
always, with no twisted dependencies.  It's just that it will be built
out of better separated (conceptually and code-wise) components, which
can then be reused to assemble multi-process ipythons, ones embedded
in GUIs or talking to their client over a network (in a web browser,
for example), etc.

One goal I'm after is that the actual engine will store the entire
session state, so that if you start it over a terminal but using 2
separate processes, you can disconnect a given terminal client and
reconnect from another terminal later, or from a network client,  and
continue working.  This ability to detach/reattach clients to an
engine will make a number of interesting use cases possible (remote
'live' collaboration, direct debugging of multiple engines when doing
distributed computing, etc.).

So having these abstractions will be very useful in the long run, even
if most users still end up with the single-terminal, single-process
client as their most common entry point.

Now the only challenge I see is for us to move quickly enough that our
trunk and dev efforts don't keep us spread too thin for too long.

Cheers,

f



More information about the IPython-dev mailing list