Python, Tkinter, and Threading

Cameron Laird claird at
Mon Feb 17 22:49:20 CET 2003

In article <4378fa6f.0302171221.11425cf8 at>,
Marc <mnations at> wrote:
>Hello All,
>I have a couple of questions/issues of concern. I've done quite a few
>programs using Tkinter now and am wondering if anyone is working on an
>easier way to integrate the front end gui with the back end
>processing, aka easier threading.
>The problem of conflicts between Tkinter and calling Tkinter functions
>from other threads appears to be well known. There are several
>available solutions, some of which I've used, all of which I find
>bulky and contrary to what should be the ease of use of a scripting
>language. The ability to call functions from outside the main gui
>thread should be a given, since that's what it will mostly be used for
>anyway - to drive a back-end it should be able to interact with.
>Having to wrap everything up and put it in queues to pop back out
>causes problems with real-time execution and causes each program to
>have a pseudo-code on top of the normal calls. The time I spend
>wrapping everything up to pop back out again doubles the amount of
>time I spend programming.
>Are there any easier solutions on the horizon? Do any of the other
>programming interfaces (wxPython, Jython) offer advantages that I just
>won't be able to see with Tkinter? Are there other solutions I just
>haven't yet seen?
There are indeed issues in this area, even with such 
toolkits as wxPython and Jython.

I know of no idioms which encompass all situations; for
reasons whose technical justifications are both inter-
esting and tediously long, satisfaction seems to involve
a lot of customization.  Therefore, let's get concrete:
what are the examples of "back-end processing" of most 
importance to you?  Database retrievals?  Invocations of
external processes?  Long-running pure-Python methods?

Cameron Laird <Cameron at>

More information about the Python-list mailing list