[IPython-dev] [IPython-user] IPython development news and prospects

[Fernando Perez]

On Jan 15, 2008 4:33 PM, Laurent Dufréchou <laurent.dufrechou at gmail.com> wrote:

> ***************** GUI integration ************************
> Just some thought on Ipython GUI integration:
>
> I've worked a little on one of the implementation of Ipython GUI integration
> inside WX.
> I've just discovered a big problem of my current implementation: I'm
> creating an Ipython instance inside a thread and send it some line to
> interpret.
> The good thing is that the thread class is GUI toolkit independent --> good
> The bad point is that prabhu asked me if it was possible to let say call
> ipython with -wthread or -qthread.
> (which is a good idea for example to develop a QTapp with wxIpython ^_^)
> It seems that it is not possible or hard to do.(not tried a lot but from
> I've seen...).
>
> So my question is:
>
> Many people seems to be interested in GUI frontend for ipython, don't you
> think it could be interesting to create a process whis a ipython instance
> inside (the same as the wxIpython thread class in fact) and The GUI
> wx,QT,everything else discuss with it via a network protocol like xml-rpc.
> (I'm not software programmer so sure you will have better idea for
> communication protocol:), I said xml-rpc because it's a base module of
> python)
>
> So the Gui part will only manage user interaction and will make ipython
> process core execute line, get history and so on.
> From what I've seen from now the interace only needs a few function to
> support ipython features (history,magic,tab_completion...)
> This also could be reused with ipython1 later as the GUI interface will not
> change only how we manage ipython1 inside the process
> (well perhaps it's more tricky :) )

What you're asking for/describing is more or less the model for the
code in the new ipython1 core.  The idea is to have an object that
implements all the ipython basic functionality (magics, system access,
object introspection and completion, fancy exceptions, etc) but does
so simply with a clean API.  This object can then be used in-process
by an interactor that is based on readline and assumes it's running in
a terminal, but it can also be used by a WX or Qt interactor,  and it
can also be exposed over the network for out-of-process use.  You can
then have an out of process interface (say in javascript in a browser,
or even a Wx or Qt one that wants to be out of process).

And by having this, the distributed/parallel computing functionality
we have today in ipython1 (the stuff that the recent MPI questions
were about, for example) can then make full use of all the ipython
functionality in the engines.  This opens great possibilities for
distributed interactive debugging, attaching control consoles to
remote engines, etc.

As you can see, the possibilities opened by a cleaner design are many,
while keeping the fact that a simple, single-process, terminal based
ipython will continue to work much like today's, as that's a very
common and important use case.

I hope this is clear and answers your questions, let me know if it
isn't the case.

Cheers,

f

> ********** OLPC *****************
> Hey for GTK question, I've recently tried PIDA under linux (too hard to
> install on windows).
> They've got a command shell in a process inside a gtk window, and if you
> type in: ipython -wthread, well you've an ipython shell inside a gui that
> support wx!(well no interaction with pida possible but well it's a good
> start!).
> That why I thought about the process thing...
> So, perhaps if you speak with pida guys you can have an ipython gui + python
> dev env for the olpc for nothing ;)

Thanks for the pointer.  The OLPC thing is probably more future work,
but if anyone wants to jump on it now, great!

Cheers,

f