Python, Tkinter, and Threading

[Cameron Laird]

In article <4378fa6f.0302171221.11425cf8 at posting.google.com>,
Marc <mnations at airmail.net> 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 Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html