[Python-bugs-list] [ python-Bugs-750423 ] event handling support

Sun, 08 Jun 2003 08:44:36 -0700

Bugs item #750423, was opened at 2003-06-06 21:58
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750423&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Lila Chase (lchase)
Assigned to: Nobody/Anonymous (nobody)
Summary: event handling support

Initial Comment:
We are interested in a general solution to the problem
of getting
various Python packages that must deal with events to
cooperate.

Python currently provides a hook to readline
(PyOS_InputHook) that
packages use for event handling. However, we have found
so far that
the following Python packages conflict over use of
readline:

- Tkinter and PyGist
- PyMPI and PyGist

As Dave Munro explains below, the best solution to this
problem is
to add more general event handling capability to
Python.  We ask 
Python developers to seriously consider this important
change.

Thank you.
Lila Chase
lchase@llnl.gov
An explanation of the event handling problem is
provided in the 
following note from Dave Munro:

Date: Wed, 14 May 2003 12:11:16 -0700
From: "David H. Munro" <munro>
Reply-To: munro1@llnl.gov

Gist does not really care about readline, of course. 
There are only
two requirements:

(1) Gist must receive an idle event.  That is, whenever
all other events
have been processed (or during idle processing), gist
needs to be called
in order to process its own deferred tasks.  This is
where the apparent
readline dependence appears: When it has nothing left
to do, python calls
readline to wait for the next input line.  This is the
only hook I know
of in python for getting an idle event delivered. 
Unfortunately, it is
way overloaded (for example, tkinter steals the same
hook as well).  The
problem is that the python event loop is "inside out"
-- it needs to be
fixed such that readline is called only as the result
of input on stdin,
putting stdin on the same footing as any other input
source.

(2) The file descriptor for gist's X socket(s) must be
included in the
list of descriptors that will trigger python to "wake
up" when it is blocked
waiting for new input.  Technically, this means that
python must call
either poll() or select() when it goes idle, and that
gist's X socket must
be among the descriptors included in the list provided
for those routines.
Furthermore, when input actually arrives on that
socket, python must call
gist's event handler.  Python currently has no direct
support for asynchronous
input, which is why gist steals the readline hook. 
That approach will break
anyone else who needs such a callback, since the
current gist input hook only
wakes up for its own X socket(s) and stdin.  Gist does
have a full event model,
so other packages could register with gist if they
wanted to get event callbacks
of their own, but of course any package which did that
would itself become
dependent on gist.  The only correct place to do this
job is therefore in
python itself; it currently just does not support such
a notion.

Part of the technical problem with such support is that
things are quitedifferent under both Windows and MacOS
<=9.  It is quite challenging to find
an abstraction which covers all those cases.  For
example, (2) is not necessary
(for gist) at all under Windows, since the OS ensures
that events on gist window
s
generate gist event callbacks.

I hope this helps to clarify the problems gist has in
coexisting with python.
Neither of these problems is particularly difficult,
although the politics of
getting such changes into the python distribution is
probably very tricky.
The good news is that these are the only really serious
problems; everything
else is purely a pygist problem.  I don't know enough
about python to judge
the path of least resistance to get them implemented,
or to accomodate the
other packages that have gone after python's existing
input hooks, but I'm
sure there must be a fairly unobtrusive way to go about
it.

Dave

P.S.-There is a subtlety in the semantics of idle
events, which makes it impossible
for gist to rely on the Tcl/Tk model for handling
them.  If anyone undertakes
the addition of idle event machinery to python, they
should take care to avoid
the same pitfall: In Tcl/Tk, you can request an idle
event, and after this
request you will indeed get a callback just before
Tcl/Tk goes idle.  However,
with Tcl/Tk semantics, you only get one such callback,
and you need to renew
your request to get another idle callback.  This makes
the entire mechanism
worthless for gist, as it is currently implemented,
because gist does not
have hooks at the (many) points it might generate idle
tasks; it expects to
be able to permanently register an idle event handler,
and to have the caller
actually go idle when that returns.  Possibly gist
could be rewritten for the
Tcl/Tk semantics, but for a new implementation, it
would be better to support
the more inclusive semantics.  (The decision about
whether an idle callback is
necessary happens at a much higher level in the gist
design than its event
loop; I am not eager to mix the abstraction levels for
the sake of supporting
Tcl/Tk's idle event model.)

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-06-08 10:44

Message:
Logged In: YES 
user_id=2772

Please see http://python.org/peps/ for information on submitting a python enhancement proposal.  This is probably a large and complex enough issue that it will have to go through the PEP process before it would be considered.

Another non-PEP or pre-PEP approach would be to develop this event-handling support separately from the three packages mentioned (Tkinter, PyMPI, and PyGist).  Presumably this new package would hook PyOS_InputHook and/or provide a "mainloop"-type function, providing the abstractions needed by Tkinter, PyMPI, and PyGist.

(Of course, you mention the "X socket" for one of the packages---for the solution to be acceptable in Python, I predict that it would need to at least work on Win32 as well, where event handling is a whole different kettle of monkeys, or whatever mixed and disturbing metaphor you care to use)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750423&group_id=5470