Peter said:
Good, then what you are really looking for is to get away from the
print statement and learn to use "import pdb; pdb.set_trace()".
This will drop you into a convenient interpreter prompt right in
the frame where it executes (well, one level down, so just type "r"
to return from the set_trace() call to the calling level). From
this prompt you can inspect any variable in your program, execute
code by single-stepping, and so forth.
Very handy, and it completely obsoletes the "while 1: pass" idea.
-Peter
Thanks for the tip, I'll keep it in mind for next time, although
for this thing I'm doing, I might not be able to use pdb because
the event driven framework I'm doing (built on top of Fredrik
Lundh's console) has to do with a text user interface and I can't
have things messing up the screen which is what would happen if I
used the pdb technique.
To illustrate how careful I have to be about preserving what's on
the screen, I have a debugmsg() function which saves the current
cursor position, prints out variable values (or whatever I like)
to a small unused corner of the screen, then restores the cursor
position. Because it's an event driven framework, program flow
is hard to predict, so there are situations where I need the
program to effectively 'hang' at certain portions (a kind of breakpoint
if you will) so I can see the debug message as well as the current
state of the screen without it being overwritten immediately by
either pdb output or succeeding code that does a screen clear or
refresh.
I would be able to use pdb if Console allowed you to separate
the screen buffer for the program output with that of the command
line from which you invoked said program (where the error messages
and pdb output should go to), but there doesn't seem to be a way
to do that.