Traceback (most recent call last):
File "<pyshell#1>", line 1, in -toplevel-
As you see, with the IDLE 1.0 which comes with Python 2.3, the
exception raised by sys.exit is captured and displayed as such
[and similarly if sys.exit is called from a module run within
the IDLE session, rather than directly at the IDLE prompt].
Oh, that is interesting, my IDLE (python-2.2.2) exits on this.
One of the several good reasons to upgrade to 2.3, yes.
Does this happen with sys.exit(0) too?
Often one may want to do some kind of clean-up at that point, but you
may achieve that with a try/finally around the mainloop call (putting
the cleanup code in the finally clause, of course).
Seems like you mean something like:
Nope. There's no reason to have to bundle the cleanup as sub-functions
inside another function and so on. Rather, the concept is that cleanup
is generally best done at the same level in which (e.g.) a resource is
acquired. The try/finally-free approach would be structured like:
channel = channels_library.open_channel('blah', 'blah')
# here: set up the GUI; then:
mainwindow.mainloop() # start and run the GUI
# when the GUI is done (and exits with quit) we can do our cleanup
channel.flush_any_unsent_data() # initiate lenghty flush operation
channel.wait_up_to(10.0) # may take up to 10 seconds' wait here
channel.final_close() # and then we finally give up
This only works if the mainloop exits without exiting the whole
Python session, of course. If you want to ensure the flushing &c
happen in any case, including uncaught exceptions, then a more
solid structure, as I mentioned, is try/finally:
channel.flush... &c &c
If this is what you meant, what is the problem with:
Hard to say without knowing what do_this and do_that do, but in
general (unless you have full control on them and can guarantee
they're done very VERY fast) this is a disaster -- the GUI freezes
(for up to 10 seconds, or a minute, or... who can tell?) while
the program performs its potentially-lengthy cleanup operations.
When you do background clean-up operations AFTER terminating the
GUI, this is generally quite preferable. A clean-up operation
can be considered a "background" one if you're not going to give
the user feedback about what happens in it (you may e.g. log info
to a logfile, but aren't going to popup a message box or the like).
Of course, this doesn't matter if all cleanup operations can be
guaranteed to terminate within, say, a couple of seconds, but
e.g. when the ner is involved, that is quite rarely true.
Since there are no advantages in doing background clean-up while
still not closing the GUI, but there may be disadvantages, it
is best to choose the approach that never gives problems -- do
the background clean-up after closing the GUI.
I do not think that there is much difference in the behavior of these.
You may not have thought the issue through, then; for example, you
may never have needed to perform length background clean-ups.
May be if I launched the application from a menu and the do_that()
function does something really stupid that causes an endless loop, I
think with quitcmd() it might occur that the window is closed and I
think "Fine, the application is shut down" but the buggy do_that() is
still running in the background. With exitcmd() this won't happen, the
window will not close before do_that() comes to an end, so I will see
that there is something wrong.
But taking many seconds to finish handshaking with communication
partners, and other such background clean-up operations, does not
mean "there is something wrong" -- such delays can be perfectly
normal, yet there is no reason to keep the user staring at a frozen
GUI while the delays go on.