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/archive%40mail-archive.com
