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@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
