[Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
Michiel Jan Laurens de Hoon
mdehoon at c2b2.columbia.edu
Fri Nov 11 17:58:31 CET 2005
I think this is an excellent summary of the discussion so far. Probably
clearer than my own posts.
Jim Jewett wrote:
>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
>(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
>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
>(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.
>Python-Dev mailing list
>Python-Dev at python.org
Michiel de Hoon
Center for Computational Biology and Bioinformatics
1150 St Nicholas Avenue
New York, NY 10032
More information about the Python-Dev