This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author idiscovery
Recipients
Date 2002-12-11.10:21:12
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=33229

When I say "PythonWin" I actually mean Pythonwin
(the Win32-specific Python IDE, part of Mark
Hammond's win32all). Running this under PythonWin
illustrates this nicely, as you can see the exit code,
and you can even load this into a file, ^R run,
and then issue a root.destroy() from the shell window.

I'm trying to get clear in my own mind  the root cause
of the more serious Win98 Tkinter hang on exit bug
that can stop Windows from shutting down. In looking
at the _tkinter code, I became suspicious of the
current Pythonic practice of not bothering to call
root.destroy ater the mainloop is exited.  The hint
here is in "nobody"'s followup that:

   Interestingly enough, if you add a print statement after 
   the mainloop(), it gets printed, showing the event loop 
   exits properly.

The other hint comes from the Tk world where one always calls 
[exit] to exit, but in Python, the Tcl exit command is removed
(and tkerror is made a no-op silencing all Tcl errors), so the 
Tcl finalization relies on the consequences of root.destroy. 
So I beseech you Guido to change the current Pythonic thinking 
to insist on always calling root.destoy in all sample programs to
make sure that that gets done - after all it can't hurt right? 
As well one should change the documentation for .quit() from:
"Quit the Tcl interpreter. All widgets will be destroyed."
to "Quit the main loop. You must still destroy() the root."

I find there is also confusion because people may not realize
that if in Tkinter you have 2 Toplevel windows,  your program
*should not* die if you <Destroy> one of the toplevel windows,
hence the importance of the change to the quit() documentation.
(I'm still trying to get clear on 2 Tk() instances, each with its own
interpreter...) To see and probe this kind of thing, it's very 
useful to have tkinspect or the equivalent, tixinspect.

There may be still a Tk bug above and beyond this, and I asked 
Jeff Hobbs to try and make sure Tk was as clean as possible 
in exiting, and  know they have done a lot over the last 6 months.
But that's above and beyond this usage issue.
History
Date User Action Args
2007-08-23 13:55:51adminlinkissue453489 messages
2007-08-23 13:55:51admincreate