bruno said:
pythonic "debugging" in three steps:
1/ unit tests
2/ a bunch of print statements
3/ the interactive python shell
All this relying on well-decoupled, modular code.
FWIW, I've almost never used a debugger with Python.
Thats a good socket for Python.
Arduos step-in debugging, big tedious remote debugging sessions etc. are
not really Pythonic. For complex things like GUI's and application
servers its a weak practice.
logs, postmortem debugging and ad-hoc debugging are the things to go next.
so its good when you can do .pm() .set_trace() to call the debugger
from the nature of your program. (And not: "The the debugger now calls
the app, once my level of anger raised beyond a certain limit").
For example with callable debuggers like pdb and also Pythonwin
(Pythonwin debugger "pywin.debugger.pm()" e.g. can be raised as simple
from normal apps / shell ) I simply do this in apps regularly:
if debug: sys.excepthook = excepthook_my_debugger
As soon as stuff crashes down (even in GUI message handlers) during all
of the development cycle: you have your fingers and cursor automatically
& immediatly at the stack context. That does >99% of usual python code
cooking. The rest is maybe for a (slow) breakpoint "b"
Unfortunately such method is not encouraged and exposed (clearly) in the
big IDE's. Those' overall style is a lazy copy of C, Java "I do"-hacker
history. Im curious much about their value at all. Keep it simple and
let Python do.
Robert
