Tracing the execution of scripts?

[Jean-Paul Calderone]

On Thu, 26 Oct 2006 21:52:42 -0400, "Michael B. Trausch" <mike$#at^&nospam!%trauschus at bag.python.org> wrote:
>Alright, I seem to be at a loss for what I am looking for, and I am not
>even really all that sure if it is possible or not.  I found the 'pdb'
>debugger, but I was wondering if there was something that would trace or
>log the order of line execution for a multi-module Python program.  I am
>having a little bit of a problem tracking down a problem that I
>mentioned earlier
>(http://groups.google.com/group/comp.lang.python/msg/9c759fc888b365be),
>and I am hoping that maybe seeing how the statements are executed will
>shed some light on the entire thing for me.
>
>The debugger isn't working, though, because I have a timer set up to
>fire off every 20ms to check for incoming network traffic from the
>server, and that timer firing off makes stepping through with the
>debugger seemingly impossible to get any useful data.
>
>Basically, is there something that will log every line of Python code
>executed, in its order of execution, to a text file so that I can see
>what is (or isn't) happening that I am expecting?  I know that the
>server is sending and receiving properly, because I can connect to it
>with a regular telnet client and it works -- but at the same time,
>everything I can think of to check my program's functionality checks out
>just fine (e.g., it reports that it is successfully sending what I am
>typing to the server, and it says that the server is not sending
>anything back to be read from the socket).
>
>If it makes any difference, I am using wxWidgets' Python bindings for
>the UI code (and the timer), and using Python's socket library for the
>network stuff.

In order of importance:

1) Write unit tests for your code.  Keep writing unit tests until you have
some that _don't pass_.  Then fix your code so that they do.  When you do
further development, write the tests first, then implement the code that
makes them pass.

2) Don't use threads.  At least have a way to not use threads while you're
debugging.  Debugging with threads is very difficult. (Actually I'm not sure
if you're using threads.  If you're not, feel free to ignore this point.)

3) Don't poll for network events every 20ms.  If you have a sensible event
loop you'll find debugging and testing much easier.

4) Use an existing library instead of developing a new one.

5) (Only included so I don't look like a _complete_ jerk.  If you get this
far and you haven't fixed the problem yet, consider this a booby prize.)
http://divmod.org/trac/browser/trunk/Epsilon/epsilon/spewer.py

Jean-Paul