Python GUI wrapper for a long operation

Jeff Epler jepler at unpythonic.net
Wed Apr 21 11:31:03 EDT 2004


Cameron is right.  In my other life, I frequently curse at places in
code where a programmer has added a call to "update" for the wrong
reason--usually, the code I run into needs to know the size of a newly
created widget, and "update" followed by "wm geometry" or "winfo" was
regarded as the way to get it.  It doesn't happen so much any more,
over the past few *years* I've rooted out most of the bad calls, or more
frequently converted them to "update idletasks" because it's easier than
completely fixing the code.

Using the word "simply" does a disservice to the potential subtleties
of this approach, which include race conditions (they're not just for
threaded programs!) or a growing stack. (where "update" calls a binding
which calls "update" to arbitrary levels of nesting).

In my example program, I made sure that the "start calculation" button
was always disabled after it was pressed and before a call to "update",
so there's no race condition there.  The "interrupt calculation" button is
only disabled during calculation (and it's the only thing enabled during
that time), and it doesn't call "update", so there's no arbitrary nesting.

For any non-trivial program, you'll get this thought process wrong.
Heck, I wouldn't be surprised to hear that I got it wrong in this case,
despite the apparent simplicity.  However, even if you make the
calculation run in an event-driven way, or using threads (or abusing
generators to act as coroutines), there's still something modal about
"a long-running calculation is happening now", and it takes care to
make sure the user can never do something inappropriate for the program
in its current state.

Jeff




More information about the Python-list mailing list