[Python-Dev] Conclusion: Event loops, PyOS_InputHook, and Tkinter

[Fernando Perez]

Michiel Jan Laurens de Hoon wrote:

> There are several other reasons why the alternative solutions that came
> up in this discussion are more attractive than IPython:
> 1) AFAICT, IPython is not intended to work with IDLE.

Not so far, but mostly by accident. The necessary changes are fairly easy
(mainly abstracting out assumptions about being in a tty).  I plan on making
ipython embeddable inside any GUI (including IDLE), as there is much demand for
that.

> 2) I didn't get the impression that the IPython developers understand
> why and how their event loop works very well (which made it hard to
> respond to their posts). I am primarily interested in understanding the
> problem first and then come up with a suitable mechanism for events.
> Without such understanding, IPython's event loop smells too much like a
> hack.

I said I did get that code off the ground by stumbling in the dark, but I tried
to explain to you what it does, which is pretty simple:

a. You find, for each toolkit, what its timer/idle mechanism is.  This requires
reading a little about each toolkit's API, as they all do it slightly
differently.  But the principle is always the same, only the implementation
details change.

b. You subclass threading.Thread, as you do for all threading code.  The run
method of this class manages a one-entry queue where code is put for execution
from stdin.

c. The timer you set up with the info from (a) calls the method which executes
the code object from the queue in (b), with suitable locking.

That's pretty much it.  Following this same idea, just this week I implemented
an ipython-for-OpenGL shell.  All I had to do was look up what OpenGL uses for
an idle callback.

> 3) IPython adds another layer on top of Python. For IPython's purpose,
> that's fine. But if we're just interested in event loops, I think it is
> hard to argue that another layer is absolutely necessary. So rather than
> setting up an event loop in a layer on top of Python, I'd prefer to find
> a solution within the context of Python itself (be it threads, an event
> loop, or PyOS_InputHook).

I gave you a link to a 200 line script which implements the core idea for GTK
without any ipython at all.  I explained that in my message.  I don't know how
to be more specific, ipython-independent or clear with you.

> 4) Call me a sentimental fool, but I just happen to like regular Python.

That's fine.  I'd argue that ipython is exceptionally useful in a scientific
computing workflow, but I'm obviously biased.  Many others in the scientific
community seem to agree with me, though, given the frequency of ipython prompts
in posts to the scientific computing lists.  

But this is free software in a free world: use whatever you like.  All I'm
interested in is in clarifying a technical issue, not in evangelizing ipython;
that's why I gave you a link to a non-ipython example which implements the key
idea using only the standard python library.

> My apologies in advance to the IPython developers if I misunderstood how
> it works.

No problem.  But your posts so far seem to indicate you hardly read what I said,
as I've had to repeat several key points over and over (the non-ipython
solutions, for example).

Cheers,

f