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

[Michiel Jan Laurens de Hoon]

I think this is an excellent summary of the discussion so far. Probably 
clearer than my own posts.
Thanks, Jim!

--Michiel.

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
>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
>_______________________________________________
>Python-Dev mailing list
>Python-Dev at python.org
>http://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe: http://mail.python.org/mailman/options/python-dev/mdehoon%40c2b2.columbia.edu
>  
>


-- 
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032