[Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt

Jim Jewett jimjjewett at gmail.com
Fri Nov 11 16:32:42 CET 2005


There has been enough misunderstanding in this thread
that the summarizers are going to have trouble.  So I'm
posting this draft in hopes of clarification; please correct
me.

(1)  There is some pre-discussion attached to patches
1049855 and 1252236.  Martin Loewis and Michiel
de Hoon agreed that the fixes were fragile, and that a
larger change should be discussed on python-dev.

(2)  Michiel writes visualization software; he (and
others, such as the writers of matplotlib) has trouble
creating a good event loop, because the GUI toolkit
(especially Tkinter?) wants its own event loop to be in
charge.

Note that this isn't the first time this sort of problem has
come up; usually it is phrased in terms of a problem with
Tix, or not being able to run turtle while in IDLE.

Event loops by their very nature are infinite loops;
once they start, everything else is out of luck unless it
gets triggered by an event or is already started.

(3)  Donovan Baarda suggested looking at Twisted for
state of the art in event loop integration.  Unfortunately,
as Phillip Eby notes, it works by not using the Tkinter
event loop.  It decides for itself when to call dooneevent.

(4)  Michiel doesn't actually need Tkinter (or any other GUI
framework?) for his own project, but he has to play nice
with it because his users expect to be able to use other
tools -- particularly IDLE -- while running his software.

(5)  It is possible to run Tkinter's dooneevent version
as part of your own event loop (as Twisted does), but
you can't really listen for its events, so you end up with
a busy loop polling, and stepping into lots of "I have
nothing to do" functions for every client eventloop.

You can use Tkinter's loop, but once it goes to sleep
waiting for input, everything sort of stalls out for a while,
and even non-Tkinter events get queued instead of
processed.

(6)  Mark Hammond suggests that it might be easier to
replace the interactive portions of python based on the
"code" module.  matplotlib suggests using ipython
instead of standard python for similar reasons.

If that is really the simplest answer (and telling users
which IDE to use is acceptable), then ... I think Michiel
has a point.

(7)  One option might be to always start Tk in a new
thread, rather than letting it take over the main thread.

There was some concern (see patch 1049855) that
Tkinter doesn't -- and shouldn't -- require threading.

My thoughts are that some of the biggest problems
with the event loop (waiting on a mutex) won't happen
in non-threaded python, and that even dummy_thread
would be an improvement over the current state (by
forcing the event loop to start last).  I may well be
missing something, but obviously I'm not sure what that is.

-jJ


More information about the Python-Dev mailing list