idle BUG

Robin Becker robin at jessikat.fsnet.co.uk
Wed Jun 20 04:59:48 EDT 2001


In article <3b2fb646.442466 at 24.0.228.33>, Mike Clarkson <support at interne
tdiscovery.com> writes
...
really sorry, but my Win95 box has been declared dead and I am awaiting
a new Dell Win2k. I have 2k at work and the problem doesn't seem to
happen there.

Every year a new OS mumble whine.


>No, it's a vanilla ActiveState 2.1, but it's on Windows 98 which
>differs a little from Win95. The only change is this self.quit patch.
>
>Make sure you are not calling or binding self.tk.quit() - use the
>patched self.quit() instead. self.tk.quit() is the _tkinter quit,
>which just says bail out of the self.tk.mainloop(). It doesn't destroy
>any windows, delete any Tk intepreter or even delete any of the tcl
>commands declared in Python as callbacks. So it's not at all like a Tk
>[exit].
>
>If you take idle as an example, after the .mainloop() statement in
>PyShell, add the following in main() (NB: console application only):
>       root.tk.eval('puts [winfo child .]')
>after the 
>       root.mainloop()
>You'll see that after idle exists its mainloop, there are two Tk
>toplevel windows still alive: . and .123456 (some number).
>It's because root.tk.quit() does not destroy any windows.
>
>My patched root.quit() makes sure they're all destroyed.
>My theory was/is that the undestroyed windows might be
>stopping Python from unloading the Tk and exiting cleanly.
>
>Note that the next statement in idle main()
>       root.destroy()
>doesn't destroy any Tk windows or intepreter. It's an internal
>function that deletes the Python callback functions. It should
>probably be renamed to _deletetclcallbacks, and maybe even
>included in my patched self.quit() before the tk.evals.
>
>Mike.
>
>probably be renamed
>
>
>

-- 
Robin Becker



More information about the Python-list mailing list