Untangling pythonWin and IDLE Processes on XP Pro

[Scott David Daniels]

W. eWatson wrote:
> As with Diez, I simply ask, "How do I get around the problem?" Are you 
> two telling me that it is impossible?
> 
> OK, here's my offer to both of you. Do you have IDLE for Python 2.5 and 
> have  good familiarity with Tkinter? If so, I'll send you the code and 
> you can try it yourself. My guess is that it will work, and if not, and 
> you are sufficiently skilled with Tkinter and debugging, you may find 
> the problem in the code. The steps to create the problem are very easy.

They are telling you the truth, and you are replying, "I don't
want to understand, I just want it to work."  They have shown great
forbearance.  The only time I have debugged any Tkinter code in IDLE,
I have start with "python -m idlelib.idle -n" and accepted the fact
that I will see crashes.  The one advantage of my technique is that
I can hand-execute single Tkinter operations and see the results
immediately since I am running piggyback on IDLE's main loop.

Once more, though I'm sure you don't want to hear it:
     Normally IDLE starts as a program running that talks to the user
(idle.py). It starts a separate process that talks to the user interface
over a TCP/IP port and does the things inside the shell (for
example the expression evaluation).  When you use the command
"Shell / Restart Shell," the process that interacts with your program
is wiped out and new process is started (I think, perhaps they simply
flush almost everything and restart).  The reason only one IDLE session
can live at a time is that a TCP/IP communication port has only two
ends.  If you don't kill _all_ of the pythonw processes, something will
go wrong in the initial setting up the parent/child processes.

     Similarly, a GUI is not a library, but a framework.  The GUI itself
is the main program (run after you do some setup) that calls parts of
your program as subroutines.  You have a problem when you use a GUI to
debug another GUI (there can be only _one_ main program).  It does no
good to stomp your foot and proclaim that you want it to work.
Sometimes your code doesn't interfere too badly with IDLE's GUI, so it
looks as if you have gotten away with it.  For example, in-process IDLE
(the "-n" flag) fiddles with the Tkinter environment in an attempt to
reduce the conflict between IDLE's and your program's use of the GUI.

The only solutions I've seen for debugging GUIs involve separated
processes (even more so than IDLE), running on separate machines.
With those, you don't share a keyboard, mouse, or display between
the debugger and the program under test.  Such solutions are available
for a price.  ActiveState, for example, sells one.

The issue in each case is sharing things that the programs have
every right to expect that they "own."  To wit, Display refresh points,
the main program, the keyboard, tcp/ip ports, the mouse.

--Scott David Daniels
Scott.Daniels at Acm.Org