[Python-Dev] trace.py in std library?

Delaney, Timothy tdelaney@avaya.com
Thu, 12 Dec 2002 11:34:16 +1100


> From: barry@python.org [mailto:barry@python.org]
> 
> >>>>> "JH" == Jeremy Hylton <jeremy@alum.mit.edu> writes:
> 
>     JH> trace.py is Skip's tool.
> 
> So I guess that means they're similar.

I think it's premature to put it into the std library - not least because
I've got a version I've been working on for a while which I'd eventually
like to get in there if I can ;) Of course, part of that will rest on my
employer ...

The major problems I had with trace.py are that it is *slow* and that the
data it collects is very incomplete.

If we are going to have a standard tracing module, I think it needs to be
*fast* and the data it collects needs to be complete, and easily
transformable to many types of reports. My main use case is automated code
coverage reports. If my unit tests take 30 minutes to run with no coverage
tool, but 15 hours to run under a coverage tool, the coverage tool is
useless for my nightly builds and automated testing.

The one I've been working on is a *lot* faster (though still in pure
python), dropping from about 3000% performance overhead to about 50%. It
also collects pretty much all the data it can (calls, lines, which lines
belong to which classes/functions/methods), resolves modules down to a
single, most-qualified instance (for example, if import a and import b.a end
up importing the same module, both will be represented in the report as b.a)
and various other things. It also determines which source lines are
executable (for example, multi-line strings will only have one of the lines
as executable).

It also *almost* works with Jython (doesn't work out executable lines
properly).

It *also* allows outputting of tracing lines as they are executed (and damn
that slows things down).

But I don't think it's a candidate yet. Among other things, the tracing
functionality is not hooked into each new thread. Not an issue for my
current project (which must run single-threaded due to being invoked inside
something that must run in a single thread) but it is an issue for a version
in the standard library.

Tim Delaney