trace options

[Terry Reedy]

Edward Peschko wrote:
> All,
> 
> I've been looking at the trace module, and although it looks useful, I'm
> surprised that there aren't a couple of features that I would have thought
> would be fairly basic. So, does trace support (for the --trace option):

I have never used the trace module but decided to try it out, following 
the simple example in the docs with a simple function. It seems a bit 
underdocumented, so I presume help with that would be welcome. I also 
found deficiencies in the operation, though different from you.

>    - indentation tracking stacklevel (where each function is prefixed
>      by tabs equal to the number of stacklevels deep in the program)

Trace already does one space indents for modules after the first

  --- modulename: threading, funcname: settrace
   --- modulename: compare, funcname: lt_iw

and lines after the first

compare.py(47):     while m != 0 and n != 0:
  compare.py(48):         m, n = m-1, n-1

That would have to be eliminated, at least when stack indents were on.
Tabs are nasty when interpreted as 8 chars. If added, the user should 
specify the indent: indent = '  ', for instance, for 2 space indents.

>    - output to something other than sys.stdout (eg. output to a file
>      specified either by environmental variable or by parameter).

That seems reasonable.  It also seems reasonable that I be able to write 
counts *to* stdout (the screen) when running interactive. But
when I changed
   r.write_results(show_missing=True, coverdir="/tmp")
in the doc example to just
   r.write_results()
I got nothing, rather than the line-by-line count I expected.  A bug?

On the other hand,
   r.write_results(summary=True)
did give output - the coverage for the module, which was not helpful.
This was so with both run('func(args)') and runfunc(func, args)
Coverage should be by function, I think, especially with runfunc.

>    - mult-threaded programs going to multiple output handles,
>      especially in light of the above
> 
>    - fully qualified python modules in path: (eg:
> 
>          /path/to/module/my_module.py(1): print "HERE"
> 
>      instead of
> 
>        my_module.py(1): print "HERE".

I think a full name in the modulename line would be good, but full names 
in the trace lines would be awful.  In fact, I would prefer no name, 
and, especially when using runfunc, line numbers relative to the 
function rather than the module. Also remove the silly indent. So I 
would like

  --- modulename: compare, funcname: lt_iw
compare.py(47):     while m != 0 and n != 0:
  compare.py(48):         m, n = m-1, n-1

changed to

Modulename: path/compare, funcname: lt_iw
   1:     while m != 0 and n != 0:
   2:         m, n = m-1, n-1

> Ultimately, I'd like to be able to look at two runs of a program
> and be able to pinpoint the very first difference
> between thembased on the output of their trace runs. As it
> stands, I really can't do this.

When I trace a function mentally, to write or debug, I keep track of the 
values of the local names.  Perhaps trace was not meant for this. 
However, if I were modifying trace, the first thing I would add would be 
the ability to print variable values with each line executed.

> Of course I could implement the above, but I was
> hoping to avoid duplicated effort if someone has
> already implemented options like this..I posted the above to
> the python-dev list, they suggested I take it here, so any help
> would be appreciated.

I searched http://pypi.python.org/pypi for 'trace' and did not see 
anything obvious.  If you do modify trace and your changes are not 
immediately accepted, you could list your version on PyPI.  In fact, 
that might be the best way to get them in.  Of course, one problem you 
can see from the above is that different people will have different 
ideas on what constitutes 'better' ;-).

Terry Jan Reedy