If you run the following script, and iconize the 
window before the after() timer, it'll restore and 
raise the window as it should, but then you can't 
exit.  You have to kill winoldap with ctrl+alt+del and 
wait.

I ran into this trying to write a portable jabber 
client using tkinter.

This is with 2.1.1 on Windows 98.  Does it every 
time.  May be related to bug #216289.

from Tkinter import *
import sys

def foo():
   print 'foo'
   sys.stdout.flush()
   root.deiconify()
   print 'bar'
   sys.stdout.flush()

root=Tk()
Button(root, text='Quit', command=root.quit).pack()
root.after(5000, foo)
root.mainloop()

Logged In: NO 

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

Logged In: YES 
user_id=6380

I agree that this is likely the same as #216289.

AFAIK it's a Tcl bug and we don't know what to do about it.

Logged In: YES 
user_id=66570

Since I was also looking at #216289:

Data using pythonw.exe (Taskinfo2000):
Handles while running (before quit)
4 :      Process   4  PID:FFF6F92D, C:\PYTHON20\PYTHONW.EXE
C :      Event     1
10 :     Event     1
1C :     Mutex    17  OLESCMLOCKMUTEX
20 :     Event     1
24 :     Event     1
--------------------------------------------------------
Handles while running Python.exe (before quit)

|Handle||Type|    |Refs||Name|

4 :     Process      7  PID:FFF50719, C:\PYTHON20\PYTHON.EXE
8 :     Console      3
C :     Screen Buff  3
10 :    Screen Buff  3
18 :    Event        1
1C :    Event        1
20 :    Event        1
24 :    Event        2
28 :    Mutex       19  OLESCMLOCKMUTEX
2C :    Event        1
30 :    Event        1
34 :    Thread       1  ThID:FFF79069, PID:FFF50719, 
C:\PYTHON20\PYTHON.EXE
38 :    Event        1
3C :    Event        2
40 :    Thread       1  ThID:FFF52B8D, PID:FFF50719, 
C:\PYTHON20\PYTHON.EXE
44 :    Event        1
48 :    Event        2
4C :    Thread       1  ThID:FFF53539, PID:FFF50719, 
C:\PYTHON20\PYTHON.EXE
----------------------------------------------------------
Handles AFTER trying to quit
|Handle||Type|    |Refs||Name|

4 :     Process      4  PID:FFF50719, C:\PYTHON20\PYTHON.EXE
8 :     Console      3
C :     Screen Buff  3
10 :    Screen Buff  3
18 :    Event        1
1C :    Event        1
20 :    Event        1
24 :    Event        1
28 :    Mutex       19  OLESCMLOCKMUTEX
2C :    Event        1
30 :    Event        1
34 :    Thread       1
38 :    Event        1
3C :    Event        1
40 :    Thread       2  ThID:FFF52B8D, PID:FFF50719, 
C:\PYTHON20\PYTHON.EXE

It appears that there is a thread NOT terminating.  I just 
don't know how to go about finding it.

Logged In: YES 
user_id=33229

See my comments in bug 231207:
    IMHO all Tkinter programs need a root.destroy() 
    after root.mainloop()

Your test case DOES NOT die whether or not you deiconify it,
if you run it under PythonWin.

Your test case DOES die whether or not you deiconify it,
whether or not you run it under PythonWin, if you add a
    root.destroy()
after the
    root.mainloop()

If you run it as a console script without the root.destroy()
then Python reaches the end of the script and exits, without 
having shut Tk down first. PythonWin of course is not exiting
at the end, and in the status line says the script 
returns with code 0.

I think this is a usage/documentation error and is 
IMHO unrelated to the very real bug 216289.

Logged In: YES 
user_id=6380

idiscovery, when you say "PythonWin" do you actually mean
Pythonwin (a Win32-specific Python IDE, part of Mark
Hammond's win32all)?  Or do you simple mean "Python under
Windows", as installed by the Python installer you get from
python.org? This difference is significant; I would not
expect Tkinter apps to work well using Pythonwin, because it
has its own Win32 event loop.

I don't understand why you'd need a root.destroy() after
root.mainloop() exits -- when Python exits, it destroys the
Tk windows anyway in my experience.

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.

Logged In: YES 
user_id=6380

It is very unpythonic to require that people destroy the
root explicitly before really exiting -- first of all, GC
should take care of this, second of all, when you exit
anyway, who cares.

If you want to take this on, find someone with commit
permission who cares about the issue enough to apply your
patch; or request commit permission yourself. I'm too busy
to care ATM. :-(

With Python 2.6 the support for Windows 95, 98, ME and NT4 has been
dropped. But it is not only that - I would advise closing as "won't fix"
for same reason as listed in aforementioned bug #216289 comment
http://bugs.python.org/msg1951

Closing as suggested