Feature Requests item #750423, was opened at 2003-06-07 04:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=750423&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 17: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=355470&aid=750423&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
