[IPython-dev] ipython1 and synchronous printing of stdout

[Gael Varoquaux]

On Mon, Aug 18, 2008 at 11:51:46AM +0200, Hans Meine wrote:
> Hi Gaël,

Sorry, this e-mail dropped out of my radar :).

> on Friday 08 August 2008 22:24:39 Gael Varoquaux wrote:
> > OK, I use this, but this by itself is not sufficient, because you want to
> > have trap to shell back out in the GUI mainloop to refresh the screen and
> > process events like "Ctrl-C" every once in a while

> If I understand you right, you process GUI events when something is output?  
> What about a long-running loop without any output?

If there is no output, only the use code is run. I run my own code on
print, but I cannot do more than that because the program is 
single-threaded.

> > (once again,
> > multi-threading is unacceptable, because the GUI toolkits that we have
> > are not thread-safe (none is), and it would lead to crashers when the
> > users would input code that interacted with the GUI toolkit.

> I don't remember if I have mentioned it in this thread or whether you
> have read an older thread about it, but we solved this by having two
> processes, one for the frontend and one for the backend, communicating
> over a socket.  In the backend, we would load a trivial "interrupt"
> extension module which would listen to a command sent by the frontend
> and call PyErr_SetInterrupt();

Yes, this would be a very good option. I am starting to consider this
option for an IDE more and more (and actually, this is how IDLE works).

> The main disadvantage is that if the backend wants to integrate into the 
> frontend GUI, an extra API for that becomes necessary.  Otherwise, it's 
> similar to a "real" terminal, which also runs in a separate process.

Yes, this is exactly the limitation. I am however wondering if the gain
here is not high-enough to justify the cost. If we go down this way, we
should ask ourselves why we are building this in a Wx (or QT, or GTK)
application. What does it give us that a terminal does not give us? More
control on the layout, for instance. But then we start seeing the limits
of the canvas API exposed by these toolkits. What about using a web
interface, then? The canvas is excellent, but the handling of events is
less so.

Anyhow, the reason Enthought is interested in this frontend, is to put it
inside GUIs, so this reflection is off-topic for what I am doing now. It
is still interesting to keep it in mind.

Thanks for sharing your thoughts,

Gaël