[Python-Dev] Code coverage tool updated

Walter Dörwald walter at livinglogic.de
Wed Nov 10 12:38:26 CET 2004


Tim Peters wrote:
> [Walter Dörwald]
> 
>>I guess it's not worth it to try to fix doctest/trace to
>>provide sourcecode for doctest code, but IMHO trace should
>>be able to survive a doctest.
> 
> Sure!  The assert also triggers for "@test" on my box, BTW -- and also
> did in 2.3.4.

This seems to be fixed now.

> [...]
>>The trace call looked like this:
>>./python ../../../trace.py --count --summary --missing Lib/test/regrtest.py
>>with ../../../trace.py being the trace.py from current
>>CVS with the assert statement removed.
>>
>>So am I doing something wrong or is trace.py broken?
> 
> Sorry, I don't know.  trace.py is like voting to me -- I'm highly in
> favor of it, but never have time for it <0.5 wink>.  I only dropped in
> here to explain the source of the synthesized doctest "file name".
> 
> FWIW, doing what you did with current CVS Python on Windows, I get
> results similar to yours:  only 30-some modules reported at the end.
> 
> Under my 2.3.4 installation instead, the same thing reports on over
> 300 modules, so best guess is that trace.py is indeed suffering
> breakage introduced in 2.4.  No idea about specifics, though.

Using regrtest.py's tracing option instead of trace.py gives better
results (see http://styx.livinglogic.de/~walter/brokentrace2.txt):
656 covered modules (including a strange /tmp/tmp6ccfd4/t5/string.py)

There seems to be something wrong with the way trace.py starts
the script.

BTW, I'd like to have an option the specify the coverdir in regrtest.py,
as now finding the coverage file when you have the name of the Python
file is more complicated. But I guess this has to wait until 2.4 is
out the door.

Bye,
    Walter Dörwald



More information about the Python-Dev mailing list