[Python-Dev] PyOS_InputHook enhancement proposal
PyOS_InputHook is a pointer to a function that is called periodically (ten times per second) while Python is idle, for example, when waiting for a user command. Python C extension modules can set this pointer to a hook function defined in the extension module. For example, _tkinter.c makes use of PyOS_InputHook to get messages delivered to its widgets. A problem arises when two or more extension modules want to set PyOS_InputHook. For example, the scientific plotting package pygist needs PyOS_InputHook to get messages delivered to its graphics windows, and may therefore conflict with the Python GUI IDLE, which uses Tkinter. Chaining won't work, as it will fail when an extension module wants to remove its hook function. My suggestion is therefore to replace PyOS_InputHook by two functions PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of which hooks are installed. This way, an extension module can add a hook function without having to worry about other extension modules trying to use the same hook. Any comments? Would I need to submit a PEP for this proposal? --Michiel, U Tokyo. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The other Py2.4 issue
E.g. if we need to compile libpython24.a it means we need to fetch the Python sources themselves first. Actually, no, you don't need the sources. See: http://mail.python.org/pipermail/python-dev/2004-January/041676.html for a script that builds libpython24.a from the python24.lib distributed with Python for Windows. Previously I built libpython24.a; it can be downloaded from my website. See http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/cygwin.html --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
Jack Jansen wrote: Also, could you point me to a readily available extension package that uses c++? The Bio.Affy and Bio.KDTree extensions in Biopython use c++. See www.biopython.org. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ 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
[Python-Dev] PyOS_InputHook and threads
I have started writing a patch that replaces PyOS_InputHook with PyOS_AddInputHook and PyOS_RemoveInputHook. I am a bit confused though on how hook functions are supposed to work with threads. PyOS_InputHook is a pointer to a hook function, which can be defined for example in a C extension module. When Python is running in a single thread, PyOS_InputHook is called ten times per second while Python is waiting for the user to type something. This is achieved by setting readline's rl_event_hook function to PyOS_InputHook. When Python uses multiple threads, each thread has its own PyOS_InputHook (I am not sure if this was intended). However, with IDLE I noticed that the subprocess thread doesn't call its PyOS_InputHook. In IDLE (if I understand correctly how it works), one thread takes care of the GUI and the interaction with the user, while another thread executes the user's commands. If an extension module sets PyOS_InputHook, the PyOS_InputHook belonging to this second thread is set. However, this PyOS_InputHook does not get called. Is this simply an oversight? What would be a suitable place to add the call to PyOS_InputHook? In other words, where does the second thread go idle? --Michiel. On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote: My suggestion is therefore to replace PyOS_InputHook by two functions PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of which hooks are installed. This way, an extension module can add a hook function without having to worry about other extension modules trying to use the same hook. Any comments? Would I need to submit a PEP for this proposal? Because this is only for the C API, your best bet is to write a patch and submit it to SF. If people whine or it gets rejected, then write a PEP. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ 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
[Python-Dev] Patch review [ 684500 ] extending readline functionality
Patch review [ 684500 ] (extending readline functionality) This patch is a duplicate of patch [ 675551 ] (extending readline functionality), which was first submitted against stable python version 2.2.2. After the resubmitted patch [ 684500 ] against Python 2.3a1 was accepted (Modules/readline.c revision 2.73 and Doc/lib/libreadline.tex revision 1.16), the original patch [ 675551 ] was closed but patch [ 684500 ] was not. I have added a comment to patch [ 684500 ] that it can be closed. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ 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
[Python-Dev] Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
The PyArg_ParseTuple function (PyObject *args, char *format, ...) parses the
arguments args and stores them in the variables specified following the format
argument. If format=="i", indicating an integer, but the corresponding Python
object in args is not a Python int or long, a TypeError is thrown:
TypeError: an integer is required
For the "L" format, indicating a long long, instead a SystemError is thrown:
SystemError: Objects/longobject.c:788: bad argument to internal function
The submitted patch fixes this, however I think it is not the best way to do it.
The original code (part of the convertsimple function in Python/getargs.c) is
case 'L': {/* PY_LONG_LONG */
PY_LONG_LONG *p = va_arg( *p_va, PY_LONG_LONG * );
PY_LONG_LONG ival = PyLong_AsLongLong( arg );
if( ival == (PY_LONG_LONG)-1 && PyErr_Occurred() ) {
return converterr("long", arg, msgbuf, bufsize);
} else {
*p = ival;
}
break;
}
In the patch, a PyLong_Check and a PyInt_Check are added:
case 'L': {/* PY_LONG_LONG */
PY_LONG_LONG *p = va_arg(*p_va, PY_LONG_LONG *);
PY_LONG_LONG ival;
/* ** patch starts here ** */
if (!PyLong_Check(arg) && !PyInt_Check(arg))
return converterr("long", arg, msgbuf, bufsize);
/* ** patch ends here ** */
ival = PyLong_AsLongLong(arg);
if (ival == (PY_LONG_LONG)-1 && PyErr_Occurred()) {
return converterr("long", arg, msgbuf, bufsize);
} else {
*p = ival;
}
break;
}
However, the PyLong_AsLongLong function (in Objects/longobject.c) also contains
a call to PyLong_Check and PyInt_Check, so there should be no need for another
such check here:
PY_LONG_LONG
PyLong_AsLongLong(PyObject *vv)
{
PY_LONG_LONG bytes;
int one = 1;
int res;
if (vv == NULL) {
PyErr_BadInternalCall();
return -1;
}
if (!PyLong_Check(vv)) {
if (PyInt_Check(vv))
return (PY_LONG_LONG)PyInt_AsLong(vv);
PyErr_BadInternalCall();
return -1;
}
A better solution would be to replace the PyErr_BadInternalCall() in the
PyLong_AsLongLong function by
PyErr_SetString(PyExc_TypeError, "an integer is required");
This would make it consistent with PyInt_AsLong in Objects/intobject.c:
long
PyInt_AsLong(register PyObject *op)
{
PyNumberMethods *nb;
PyIntObject *io;
long val;
if (op && PyInt_Check(op))
return PyInt_AS_LONG((PyIntObject*) op);
if (op == NULL || (nb = op->ob_type->tp_as_number) == NULL ||
nb->nb_int == NULL) {
PyErr_SetString(PyExc_TypeError, "an integer is required");
return -1;
}
By the way, I noticed that a Python float is converted to an int (with a
deprecation warning), while trying to convert a Python float into a long long
int results in a TypeError. Also, I'm not sure about the function of the calls
to converterr (in various places in the convertsimple function); none of the
argument type errors seem to lead to the warning messages created by converterr.
--Michiel.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
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
[Python-Dev] Patch review [ 1093585 ] sanity check for readline remove/replace
Patch review [ 1093585 ] sanity check for readline remove/replace The functions remove_history_item and replace_history_item in the readline module respectively remove and replace an item in the history of commands. As outlined in bug [ 1086603 ], both functions cause a segmentation fault if the item index is negative. This is actually a bug in the corresponding functions in readline, which return a NULL pointer if the item index is larger than the size of the history, but does not check for the item index being negative. I sent a patch to [EMAIL PROTECTED], so this will probably be fixed in future versions of readline. But for now, we need a workaround in Python. The patched code checks if the item index is negative, and issues an error message if so. I have run the test suite after applying this patch, and I found no problems with it. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end (same as lists and strings for exampe). So remove_history_item(-1) removes the last item added to the history etc. In that case, get_history_item should change as well. Right now get_history_item(-1) returns None, so the patch introduces a small (and probably insignificant) inconsistency: get_history_item(-1) returns None but remove_history_item(-1) raises an error. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ 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
[Python-Dev] Patch review [ 981773 ] crach link c++ extension by mingw
Patch review [ 981773 ] crach link c++ extension by mingw When building a C++ extension for Windows using MinGW, the linking would fail due to an incorrect link command. The patch contains a solution for this problem. I could reproduce this bug with Python 2.3.5c1, but in Python 2.4 it seems to have been fixed. Using this Python version: '2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]' a C++ extension compiled and linked correctly with MinGW. So I think this patch is no longer needed (except if we want to back-port it to 2.3.5, which I doubt). --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ 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
[Python-Dev] Patch review & request
This is my last patch review in a series of five; next time I'll send them in a
bunch of five as requested. I reviewed the following patches:
[ 684500 ] extending readline functionality
[ 723201 ] PyArg_ParseTuple problem with 'L' format
[ 981773 ] crach link c++ extension by mingw
[ 985713 ] bug skipping optional keyword arguments of type "w#"
[ 1093585 ] sanity check for readline remove/replace
I'd like to ask your attention for patch #1121234, which is a bug fix for a
reference count problem in Tkinter. Nothing complicated, don't worry.
Thanks!
--Michiel.
Patch [ 985713 ] bug skipping optional keyword arguments of type "w#"
-
The convertsimple function in Python/getargs.c converts arguments for
PyArg_Parse, PyArg_ParseTuple etc. The function skipitem takes care of skipping
optional keyword arguments. Some of the valid formats are included in
convertsimple but missing in skipitem. The patch shows the example of the "w#"
format. If the argument format is "s|w#H" with corresponding keywords "string",
"buffer", "ushort", you can skip the "ushort" keyword but not the "buffer"
keyword. So this works:
>>> my_dummy_func("text", buffer=my_buffer)
but this doesn't:
>>> my_dummy_func("text", ushort=my_ushort)
It results in the error message
Traceback (most recent call last):
File "", line 1, in ?
TypeError: argument 2 impossible
The patch fixes this by adding the appropriate formats to the skipitem function.
The patch was written for the "w#" format; other formats that are missing are
listed in the patch description.
It seems that the missing formats in the skipitem function are simply due to an
oversight. Running the test suite revealed no problems with this patch. So I
think it can be applied.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
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
[Python-Dev] A bunch of patch reviews
Below are a set of five patch reviews. I don't have any patch to push for at
this point, so these patch reviews are just for you to read and enjoy. Thanks
everybody for developing and maintaining Python. I wouldn't know what to do
without it.
--Michiel.
Patch [ 853890 ] Optional keyword unicode args not handled correctly
The skipitem function in Python/getargs.c misses code for several argument
formats. This patch solves one of them ('u' and 'u#'), patch 985713 solves
another one ('w'). There are several more that need to be solved. I've asked the
patch contributor to write a complete patch, including all missing formats. This
patch is rather straightforward and solves a serious problem, so I'd recommend
accepting it once it is complete.
Patch [ 1167316 ] a fix for doctest crash when it is ran on itself
doctest.py in Lib fails when it is run on itself. The error is due to missing
"import doctest" statements and similar small problems in the doctest
docstrings. Patch seems to work correctly.
Patch [ 1166780 ] Fix _tryorder in webbrowser.py
In webbrowser.py, a user can override the default list of web browsers to be
opened by setting the BROWSER variable. Currently, if BROWSER is set, the
default list is not used at all. The patch contributor notes that if BROWSER is
set incorrectly, this may result in no browser being opened at all. While this
is true, seeing a different browser open instead of the one specified in BROWSER
may lead to confusion, and may lead to future bug reports saying "webbrowser.py
ignores the BROWSER variable" if a user sets BROWSER incorrectly. So my
suggestion is to at least print a warning message if the browser specified in
BROWSER cannot be used, and then proceed by opening one of the default browsers.
Patch [ 764221 ] add set/getattr interface to tkFont.Font objects
This patch has already made it into Python2.4, so I think this patch can be
closed.
Patch [ 1163314 ] the quotes page on the Web site links to something broken
The patch writer is correct that the link is broken, but it's not a Python bug.
I've suggested him to write to the web master.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
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
[Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Dear Pythoneers, I use Python heavily for scientific computing, originally for computational physics and nowadays for computational biology. One of the extension modules I support is pygist, a module for scientific visualization. For this (and similar) packages to work, it is important to have an event loop in Python. Currently, event loops are available in Python via PyOS_InputHook, a pointer to a user-defined function that is called when Python is idle (waiting for user input). However, an event loop using PyOS_InputHook has some inherent limitations, so I am thinking about how to improve event loop support in Python. As an example, consider the current implementation of Tkinter. What's nice about it is that events as well as user-typed Python commands are handled without having to call mainloop() explicitly (except on some platforms): "import Tkinter; Tkinter.Tk()" causes a Tk window to pop up that remains responsive throughout. It works as follows (using Tkinter as an example; pygist works essentially the same): 1) Importing Tkinter causes PyOS_InputHook to be set to the EventHook function in _tkinter.c. 2) Before Python calls fgets to read the next Python command typed by the user, it checks PyOS_InputHook and calls it if it is not NULL. 3) The EventHook function in _tkinter runs the following loop: - Check if user input is present; if so, exit the loop - Handle a Tcl/Tk event, if present - Sleep for 20 milliseconds 4) Once the EventHook function returns, Python continues to read the next user command. After executing the command, return to 2). However, this implementation has the following problems: 1) Essentially, the event loop is a busy-wait loop with a 20 ms sleep in between. An event loop using select() (or equivalent on Windows) will give better performance. 2) Since this event loop runs inside Tkinter, there is no way for other extension modules to get their messages handled. Hence, we cannot have more than one extension module that needs an event loop. As an example, it would be nice to have a Tkinter GUI to steer a simulation and a (non-Tk) graphics output window to visualize the simulation. 3) Whereas PyOS_InputHook is called when Python is waiting for user input, it is not called when Python is waiting for anything else, for example one thread waiting for another. For example, IDLE uses two threads, one handling the GUI and one handling the user commands. When the second thread is waiting for the first thread (when waiting for user input to become available), PyOS_InputHook is not being called, and no Tkinter events are being handled. Hence, "import Tkinter; Tkinter.Tk()" does nothing when executed from an IDLE window. Which means that our scientific visualization software can only be run from Python started from the command line, whereas many users (especially on Windows) will want to use IDLE. Now the problem I'm facing is that because of its integration with Tcl, this cannot be fixed easily with Tkinter as the GUI toolkit for Python. If the events to be handled were purely graphical events (move a window, repaint a window, etc.), there would be no harm in handling these events when waiting for e.g. another thread. With Tkinter, however, we cannot enter EventHook while waiting for another thread: a) because EventHook only returns if user input is available (it doesn't wait for threads); b) because EventHook also runs Tcl/Tk commands, and we wouldn't want to run some Tcl commands in some thread while waiting for another thread. Therefore, as far as I can tell, there is no way to set up a true event loop in Python that works nicely with Tkinter, and there is no way to have an event loop function from IDLE. So I'd like to ask the following questions: 1) Did I miss something? Is there some way to get an event loop with Tkinter? 2) Will Tkinter always be the standard toolkit for Python, or are there plans to replace it at some point? I realize that Tkinter has been an important part of Python for some time now, and I don't expect it to be ditched just because of my event loop problems. At the same time, event loop support could use some improvement, so I'd like to call your attention to this issue. Tcl actually has event loops implemented quite nicely, and may serve as an example of how event loops may work in Python. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: > Michiel Jan Laurens de Hoon wrote: > >> 2) Will Tkinter always be the standard toolkit for Python, or are >> there plans to replace it at some point? > > > Python does not evolve along a grand master plan. Instead, individual > contributors propose specific modifications, e.g. through PEPs. At this point, I can't propose a specific modification yet because I don't know the reasoning that went behind the original choice of Tk as the default GUI toolkit for Python (and hence, I don't know if those reasons are still valid today). I can see one disadvantage (using Tk limits our options to run an event loop for other Python extensions), and I am trying to find out why Tk was deemed more appropriate than other GUI toolkits anyway. So let me rephrase the question: What is the advantage of Tk in comparison to other GUI toolkits? Is it Mac availability? More advanced widget set? Installation is easier? Portability? Switching to a different GUI toolkit would break too much existing code? I think that having the answer to this will stimulate further development of alternative GUI toolkits, which may give some future Python version a toolkit at least as good as Tk, and one that doesn't interfere with Python's event loop capabilities. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Greg Ewing wrote: >I'm not sure the event-loop situation would be >much different with another one, anyway. From what >I've seen of GUI toolkits, they all have their own >form of event loop, and they all provide some way >of hooking other things into it (as does Tkinter), >but whichever one you're using, it likes to be in >charge. > It's not because it likes to be in charge, it's because there's no other way to do it in Python. In our scientific visualization software, we also have our own event loop. I'd much rather let a Python event loop handle our messages. Not only would it save us time programming (setting up an event loop in an extension module that passes control back to Python when needed is tricky), it would also give better performance, it would work with IDLE (which an event loop in an extension module cannot as explained in my previous post), and it would let different extension modules live happily together all using the same event loop. Tkinter is a special case among GUI toolkits because it is married to Tcl. It doesn't just need to handle its GUI events, it also needs to run the Tcl interpreter in between. Which is why Tkinter needs to be in charge of the event loop. For other GUI toolkits, I don't see a reason why they'd need their own event loop. > Code which blocks reading from standard >input doesn't fit very well into any of them. > > Actually, this is not difficult to accomplish. For example, try Tcl's wish on Linux: It will pop up a (responsive) graphics window but continue to read Tcl commands from the terminal. This is done via a call to select (on Unix) or MsgWaitForMultipleObjects (on Windows). Both of these can listen for terminal input and GUI events at the same time. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Stephen J. Turnbull wrote: >Michiel> What is the advantage of Tk in comparison to other GUI >Michiel> toolkits? > >IMO, Tk's _advantage_ is that it's there already. As a standard >component, it works well for typical simple GUI applications (thus >satisfying "batteries included" IMO), and it's self-contained. So I >would say it's at _no disadvantage_ to other toolkits. > >Alternatives like PyGtk and wxWidgets are easily available and provide >some degree of cross-platform support for those who need something >more/different. > >Is there some reason why you can't require users to install a toolkit >more suited to your application's needs? > > My application doesn't need a toolkit at all. My problem is that because of Tkinter being the standard Python toolkit, we cannot have a decent event loop in Python. So this is the disadvantage I see in Tkinter. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: > Michiel Jan Laurens de Hoon wrote: > >> It's not because it likes to be in charge, it's because there's no >> other way to do it in Python. > > As I said: this is simply not true. You are right in the sense it is possible to get events handled using the solutions you proposed before (sorry for not responding to those earlier). But I don't believe that these are very good solutions: > You are missing multi-threading, which is the widely used > approach to doing things simultaneously in a single process. In one > thread, user interaction can occur; in another, computation. If you need > non-blocking interaction between the threads, use queues, or other > global variables. If you have other event sources, deal with them > in separate threads. The problem with threading (apart from potential portability problems) is that Python doesn't let us know when it's idle. This would cause excessive repainting (I can give you an explicit example if you're interested). But there is another solution with threads: Can we let Tkinter run in a separate thread instead? > Yes, it is possible to get event loops with Tkinter. Atleast on Unix, > you can install a file handler into the Tk event loop (through > createfilehandler), which gives you callbacks whenever there is some > activity on the files. This works, but only if Tkinter is installed, and even then it will give poor performance due to the busy-loop with 20 ms sleep in between in Tkinter. Furthermore, this will not work with IDLE, because the Python thread that handles user commands never enters the Tkinter event loop, even if we import Tkinter. AFAIK, there is no easy solution to this. > Furthermore, it is possible to turn the event loop around, by doing > dooneevent explicitly. Here, the problem is that we don't know *when* to call dooneevent, so we'd have to do a busy-loop and sleep in between. >> Tkinter is a special case among GUI toolkits because it is married to >> Tcl. It doesn't just need to handle its GUI events, it also needs to >> run the Tcl interpreter in between. > > That statement is somewhat deceiving: there isn't much interpreter to > run, really. I may be wrong here, but I'd think that it would be dangerous to run Tkinter's event loop when one thread is waiting for another (as happens in IDLE). >> Which is why Tkinter needs to be in charge of the event loop. For >> other GUI toolkits, I don't see a reason why they'd need their own >> event loop. > > They need to fetch events from the operating system level, and dispatch > them to the widgets. This is a perfect task for an event loop located in Python, instead of in an extension module. I could write a prototype event loop for Python to demonstrate how this would work. Sorry if I'm sounding negative, but we've actually considered many different things to get the event loop working for our scientific visualization software, and we were never able to come up with a satisfactory scheme within the current Python framework. Other packages have run into the same problem (e.g. matplotlib, which now recommends using the interactive ipython instead of regular python; the python extension for the Rasmol protein viewer is another). --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Guido van Rossum wrote: >On 11/9/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote: > > >>My application doesn't need a toolkit at all. My problem is that because >>of Tkinter being the standard Python toolkit, we cannot have a decent >>event loop in Python. So this is the disadvantage I see in Tkinter. >> >> > >That's a non-sequitur if I ever saw one. Who gave you that idea? There is no >connection. > I have come to this conclusion after several years of maintaining a scientific plotting package and trying to set up an event loop for it. Whereas there are some solutions that more or less work, none of them work very well, and the solutions that we found tend to break. Other visualization packages are struggling with the same problem. I'm trying the best I can to explain in my other posts why I feel that Tkinter is the underlying reason, and why it would be difficult to solve. >(If there's *any* reason for Python not having a standard event loop >it's probably because I've never needed one.) > It's probably because we have gotten away with piggy-backing on Tcl's event loop for so long. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: >Before trying to explain the reason, please try to explain the >problem first. What is it *really* that you want to do which >you feel you currently can't do? > > Probably I should have started the discussion with this; sorry if I confused everybody. But here it is: I have an extension module for scientific visualization. This extension module opens one or more windows, in which plots can be made. Something similar to the plotting capabilities of Matlab. For the graphics windows to remain responsive, I need to make sure that its events get handled. So I need an event loop. At the same time, the user can enter new Python commands, which also need to be handled. To achieve this, I make use of PyOS_InputHook, a pointer to a function which gets called just before going into fgets to read the next Python command. I use PyOS_InputHook to enter an event loop inside my extension module. This event loop handles the window events, and returns as soon as a new Python command is available at stdin, at which point we continue to fgets as usual. While this approach more or less works, there are two problems that I have run into: 1) What if the user decides to import Tkinter next? Tkinter notices that PyOS_InputHook is already set, and does not reset it to its own event loop. Hence, Tkinter's events are not handled. Similarly, if a user imports Tkinter before my extension module, I don't reset PyOS_InputHook, so Tkinter's events are handled but not mine. If I were to reset PyOS_InputHook to my extension module's event loop, then my events get handled but not Tkinter's. 2) On Windows, many users will use IDLE to run Python. IDLE uses two Python threads, one for the GUI and one for the user's Python commands. Each has its own PyOS_InputHook. If I import my extension module (or Tkinter, for that matter), the user-Python's PyOS_InputHook gets set to the corresponding event loop function. So far so good. However, PyOS_InputHook doesn't actually get called: Between Python commands, the GUI-Python is waiting for the user to type something, and the user-Python is waiting for the GUI-Python. While the user-Python is waiting for the GUI-Python thread, no call is made to PyOS_InputHook, therefore we don't enter an event loop, and no events get handled. Hence, neither my extension module nor Tkinter work when run from IDLE. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: >Michiel Jan Laurens de Hoon wrote: > > >>The problem with threading (apart from potential portability problems) >>is that Python doesn't let us know when it's idle. This would cause >>excessive repainting (I can give you an explicit example if you're >>interested). >> >> >I don't understand how these are connected: why do you need to know >when Python is idle for multi-threaded applications, and why does not >knowing that it is idle cause massive repainting? > >Not sure whether an explicit example would help, though; one would >probably need to understand a lot of details of your application. Giving >a simplified version of the example might help (which would do 'print >"Repainting"' instead of actually repainting). > > As an example, consider a function plot(y,x) that plots a graph of y as a function of x. If I use threading, and Python doesn't let us know when it's idle, then the plot function needs to invalidate the window to trigger repainting. Otherwise, the event loop doesn't realize that there is something new to plot. Now if I want to draw two graphs: def f(): x = arange(1000)*0.01 y = sin(x) plot(y,x) plot(2*y,x) and I execute f(), then after the first plot(y,x), I get a graph of y vs. x with x between 0 and 10 and y between -1 and 1. After the second plot, the y-axis runs from -2 to 2, and we need to draw (y,x) as well as (2*y,x). So the first repainting was in vain. If, however, Python contains an event loop that takes care of events as well as Python commands, redrawing won't happen until Python has executed all plot commands -- so no repainting in vain here. I agree with you though that threads are a good solution for extension modules for which a standard event loop is not suitable, and for which graphics performance is not essential -- such as Tkinter (see my next post). --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Greg Ewing wrote: >Michiel Jan Laurens de Hoon wrote: > > >>I have an extension module for scientific visualization. This extension >>module opens one or more windows, in which plots can be made. >> >> > >What sort of windows are these? Are you using an existing >GUI toolkit, or rolling your own? > > Rolling my own. There's not much GUI to my window, basically it's just a window where I draw stuff. >>For the graphics windows to remain responsive, I need to make sure that >>its events get handled. So I need an event loop. >> >> >How about running your event loop in a separate thread? > > I agree that this works for some extension modules, but not very well for extension modules for which graphical performance is critical (see my reply to Martin). Secondly, I think that by thinking this through, we can come up with a suitable event loop framework for Python (probably similar to what Skip is proposing) that works without having to resort to threads. So we give users a choice: use the event loop if possible or preferable, and use a thread otherwise. --Michiel.. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
[EMAIL PROTECTED] wrote: >If I have a Gtk app I have to feed other (socket, callback) pairs to it. It >takes care of adding it to the select() call. Python could dictate that the >way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to >feed Python the (socket, callback) pair. Then you have a uniform way to >control event-driven applications. Today, a package like Michiel's has no >idea what sort of event loop it will encounter. If Python provided the >event loop API it would be the same no matter what widget set happened to be >used. > > This is essentially how Tcl does it (and which, btw, is currently being used in Tkinter): Tcl has the functions *Tcl_CreateFileHandler/**Tcl_DeleteFileHandler*, which allow a user to add a file descriptor to the list of file descriptors to select() on, and to specify a callback function to the function to be called when the file descriptor is signaled. A similar API in Python would give users a clean way to hook into the event loop, independent of which other packages are hooked into the event loop. // >The sticking point is probably that a number of such packages presume they >will always provide the main event loop and have to way to feed their >sockets to another event loop controller. That might present some hurdles >for the various package writers/Python wrappers. > > This may not be such a serious problem. Being able to hook into Python's event loop is important only if users want to be able to use the extension module in interactive mode. For an extension module such as PyGtk, the developers may decide that PyGtk is likely to be run in non-interactive mode only, for which the PyGtk mainloop is sufficient. Having an event loop API in Python won't hurt them. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Noam Raphael wrote: >On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > >>Noam Raphael wrote: >> >> >>>All that is needed to make Tkinter and Michiels' >>>code run together is a way to say "add this callback to the input >>>hook" instead of the current "replace the current input hook with this >>>callback". Then, when the interpreter is idle, it will call all the >>>registered callbacks, one at a time, and everyone would be happy. >>> >>> >>Except for those who don't like busy waiting. >> >> >I'm not sure I understand what you meant. If you meant that it will >work slowly - a lot of people (including me) are using Tkinter without >a mainloop from the interactive shell, and don't feel the difference. >It uses exactly the method I described. > > This depends on what kind of extension module you run. I agree, for Tkinter you probably won't notice the difference -- although you are still wasting processor cycles. However, if graphics performance is important, busy-waiting is not ideal. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: >Michiel Jan Laurens de Hoon wrote: > > >>But there is another solution with threads: Can we let Tkinter run in a >>separate thread instead? >> >> > >Yes, you can. Actually, Tkinter *always* runs in a separate thread >(separate from all other threads). > > Are you sure? If Tkinter is running in a separate thread, then why does it need PyOS_InputHook? Maybe I'm misunderstanding the code in _tkinter.c, but it appears that the call to Tcl_DoOneEvent and the main interpreter (the one that reads the user commands from stdin) are in the same thread. Anyway, if we can run Tkinter's event loop in a thread separate from the main interpreter, then we can avoid all interference with other event loops, and also improve Tkinter's behavior itself: 1) Since this event loop doesn't need to check stdin any more, we can avoid the busy-wait-sleep loop by calling Tcl_DoOneEvent without the TCL_DONT_WAIT flag, and hence get better performance. 2) With the event loop in a separate thread, we can use Tkinter from IDLE also. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Greg Ewing wrote: >Michiel Jan Laurens de Hoon wrote: > > >>Greg Ewing wrote: >> >> >>>How about running your event loop in a separate thread? >>> >>> >>I agree that this works for some extension modules, but not very well >>for extension modules for which graphical performance is critical >> >> > >I don't understand. If the main thread is idle, your thread >should get all the time it wants. > >I'd actually expect this to give better interactive response, >since you aren't doing busy-wait pauses all the time -- the >thread can wake up as soon as an event arrives for it. > > This is exactly the problem. Drawing one picture may consist of many Python commands to draw the individual elements (for example, several graphs overlaying each other). We don't know where in the window each element will end up until we have the list of elements complete. For example, the axis may change (see my example to Martin). Or, if we're drawing a 3D picture, then one element may obscure another. Now, if we have our plotting extension module in a separate thread, the window will be repainted each time a new element is added. Imagine a picture of 1000 elements: we'd have to draw 1+2+...+1000 times. So this is tricky: we want repainting to start as soon as possible, but not sooner. Being able to hook into Python's event loop allows us to do so. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Fernando Perez wrote: >Michiel Jan Laurens de Hoon wrote: > > >>For an extension module such as >>PyGtk, the developers may decide that PyGtk is likely to be run in >>non-interactive mode only, for which the PyGtk mainloop is sufficient. >> >> > >Did you read my reply? ipython, based on code.py, implements a few simple >threading tricks (they _are_ simple, since I know next to nothing about >threading) and gives you interactive use of PyGTK, WXPython and PyQt >applications in a manner similar to Tkinter. > That may be, and I think that's a good thing, but it's not up to me to decide if PyGtk should support interactive use. The PyGtk developers decide whether they want to decide to spend time on that, and they may decide not to, no matter how simple it may be. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
[EMAIL PROTECTED] wrote: >Ronald> ... except when the GUI you're using doesn't expose (or even >Ronald> use) a file descriptor that you can use with select. Not all the >Ronald> world is Linux. > >Can you be more specific? Are you referring to Windows? I'm not suggesting >you'd be able to use the same exact implementation on Unix and non-Unix >platforms. You might well have to do different things across different >platforms. Hopefully it would look the same to the programmer though, both >across platforms and across toolkits. I can't imagine any of the X-based >widget toolkits on Unix systems would use anything other than select() on a >socket at the bottom. > >Skip > > As far as I know, that is correct (except that some systems use poll instead of select). For our extension module, we use select or poll to wait for events on Unix (using X). I have not run into problems with this on the Unix systems I have used, nor have I received complaints from users that this didn't work. On Windows, the situation is even easier. MsgWaitForMultipleObjects can wait for events on all windows created by the thread as well as stdin (the same function is used in Tcl's event loop). In contrast to Unix' select, we don't need to tell MsgWaitForMultipleObjects which callback function is associated with each window. --Michiel. -- 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Ronald Oussoren wrote: > I wonder why nobody has suggested a seperate thread for managing the > GUI and > using the hook in Python's event loop to issue the call to update_plot. > Ha. That's probably the best solution I've heard so far, short of adding a Tcl-like event loop API to Python. There are two remaining issues though: 1) Currently, there's only one PyOS_InputHook. So we're stuck if we find that some other extension module already set PyOS_InputHook. An easy solution would be to have an PyOS_AddInputHook/PyOS_RemoveInputHook API, and let Python maintain a list of input hooks to be called. 2) All extension modules have to agree to return immediately from a call to the hook function. Tkinter currently does not do this. --Michiel. -- 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
[Python-Dev] Conclusion: Event loops, PyOS_InputHook, and Tkinter
Thanks everybody for contributing to this discussion. I didn't expect it to become this extensive. I think that by now, everybody has had their chance to voice their opinion. It seems safe to conclude that there is no consensus on this topic. So what I'm planning to do is to write a small extension module that implements some of the ideas that came up in this discussion, and see how they perform in the wild. It will give us an idea of what works, what doesn't, and what the user demand is for such functionality, and will help us if this issue happens to turn up again at some point in the future. Thanks again, --Michiel. -- 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
Re: [Python-Dev] Conclusion: Event loops, PyOS_InputHook, and Tkinter
Phillip J. Eby wrote: > At 06:48 PM 11/15/2005 -0500, Michiel Jan Laurens de Hoon wrote: > >> Thanks everybody for contributing to this discussion. I didn't expect it >> to become this extensive. >> I think that by now, everybody has had their chance to voice their >> opinion. >> It seems safe to conclude that there is no consensus on this topic. > > > Just a question: did you ever try using IPython, and confirm whether > it does or does not address the issue you were having? As far as I > could tell, you never confirmed or denied that point. > Yes I did try IPython. First of all, IPython, being pure Python code, does not affect the underlying Python's loop (at the C level). So just running Python through IPython does not fix our event loop problem. On Windows, for example, after importing IPython into IDLE (which most of our users will want to use), our graphics window still freezes. This leaves us with the possibility of using IPython's event loop, which it runs on top of regular Python. But if we use that, we'd either have to convince all our users to switch to IPython (which is impossible) or we have to maintain two mechanisms to hook our extension module into the event loop: one for Python and one for IPython. There are several other reasons why the alternative solutions that came up in this discussion are more attractive than IPython: 1) AFAICT, IPython is not intended to work with IDLE. 2) I didn't get the impression that the IPython developers understand why and how their event loop works very well (which made it hard to respond to their posts). I am primarily interested in understanding the problem first and then come up with a suitable mechanism for events. Without such understanding, IPython's event loop smells too much like a hack. 3) IPython adds another layer on top of Python. For IPython's purpose, that's fine. But if we're just interested in event loops, I think it is hard to argue that another layer is absolutely necessary. So rather than setting up an event loop in a layer on top of Python, I'd prefer to find a solution within the context of Python itself (be it threads, an event loop, or PyOS_InputHook). 4) Call me a sentimental fool, but I just happen to like regular Python. My apologies in advance to the IPython developers if I misunderstood how it works. --Michiel. -- 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
