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

Jim Jewett jimjjewett at gmail.com
Fri Nov 11 21:44:34 CET 2005


>> (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.

Fredrik Lundh wrote:

> really?  Python comes with a module that makes it trivial to get
> a fully working interpreter console ...

Using an event loop (or an external GUI) should not require
forking the entire interactive mode, no matter how trivial that
fork is.

The subtle differences between interactive mode and IDLE
already cause occasional problems; the same would be true
of code.interact() if it were more widely used.

Part of Michiel's pain is that users want to make their own
decisions on whether to use IDLE or emacs or vt100, and
they want to mix and match toolkits.  They already run into
unexpected freezes because of the event loop conflicts.
If every extension writer also relied on their own subclasses
of the interactive mode, users would be in for far more
unpleasant surprises.

The right answer might be to run each event loop in a
separate thread.  The answer might be to have a python
event loop that re-dispatches single events to the other
frameworks.  The answer might be a way to chain
PyOS_InputHook functions like atexit does for shutdown
functions.  The answer might be something else
entirely.

But I'm pretty sure that the right answer does not involve
adding an additional layer of potential incompatibility.

-jJ


More information about the Python-Dev mailing list