On May 23, 2005, at 2:03 PM, David King wrote:
In the short run, I would be ok just using Tk alone on IPython or plain Python, although I'd be happiest having the whole picture. In the long run, our project will want to serve varied users, who will no doubt want to use python in their own way.
Note that Tkinter windows under the standard Python interpreter are only 'alive' when the intepreter prompt is active. If you invoke a function that takes a long time, the window will be unresponsive since the Tk events are only handled within the Python interpreter loop. In this respect IPython should have an advantage with threading.
I will continue to study what I have (that forum-thread link was helpful too--thanks). But I can't help feeling other python gui programmers must run up against this problem too, and wonder why practically all the standard Tkinter doc (including Grayson's book) just says "you gotta call mainloop() to make anything actually appear and respond in Tkinter" (manifestly untrue).
I think the problem is that, by and large, almost all uses of GUIs are centered on their being standalone applications and thus little thought is given to having a command line coexisting with the GUI. Our needs are pretty atypical in this regard. Perry Greenfield
Perry Greenfield wrote:
On May 23, 2005, at 2:03 PM, David King wrote:
In the short run, I would be ok just using Tk alone on IPython or plain Python, although I'd be happiest having the whole picture. In the long run, our project will want to serve varied users, who will no doubt want to use python in their own way.
Note that Tkinter windows under the standard Python interpreter are only 'alive' when the intepreter prompt is active. If you invoke a function that takes a long time, the window will be unresponsive since the Tk events are only handled within the Python interpreter loop. In this respect IPython should have an advantage with threading.
Well, the advantage provided by ipython is that, in addition to Tk (which you get 'for free' with plain python), you can have interactive WX, GTK, and as of current CVS, also QT GUIs controlled from a command line. The issues with the GIL are still there, so any long-running command which doesn't release the GIL will still block. But it does give some advantages. Regards, f
On May 23, 2005, at 2:58 PM, Fernando Perez wrote:
The issues with the GIL are still there, so any long-running command which doesn't release the GIL will still block. But it does give some advantages.
Isn't that mainly an issue as to whether things can run concurrently? As far as event handling, even when the GIL blocks, there still should be thread switches on a regular basis within Python code so that even though only one thread runs at a time, the events will be handled during most long-running functions (perhaps not long-running extension functions). But maybe I'm mixed up on that. Perry
Quoting Perry Greenfield <perry@stsci.edu>:
On May 23, 2005, at 2:58 PM, Fernando Perez wrote:
The issues with the GIL are still there, so any long-running command which doesn't release the GIL will still block. But it does give some advantages.
Isn't that mainly an issue as to whether things can run concurrently? As far as event handling, even when the GIL blocks, there still should be thread switches on a regular basis within Python code so that even though only one thread runs at a time, the events will be handled during most long-running functions (perhaps not long-running extension functions). But maybe I'm mixed up on that.
You are perfectly correct. What I had in mind (but I wasn't explicit enough) is the common (for scientific users) of calling a long-running C extension (say an eigenvalue calculation for a large matrix). This will block the GUI, since there are no thread switches happening at that point. Regards, f
participants (3)
-
Fernando Perez -
Fernando.Perez＠colorado.edu
-
Perry Greenfield