RetroSearch Browse

Thu Nov 4 13:54:51 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/049770.html

Tim Peters wrote:
> [Walter Dörwald]
> 
>>This doesn't help. The following assert in trace.py raises
>>an AssertionError:
>>   assert filename.endswith('.py')
>>
>>[...]
>>
>>So what is <doctest _threading_local[7]>?
> 
> I haven't followed this thread, but can answer that question literally
> <wink>:  it's code synthesized for the seventh doctest example in
> Lib/_threading_local.py's module docstring.  The file name is
> constructed by this line in doctest.py:
> 
>             # Use a special filename for compile(), so we can retrieve
>             # the source code during interactive debugging (see
>             # __patched_linecache_getlines).
>             filename = '<doctest %s[%d]>' % (test.name, examplenum)

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.

Removing the assert statement, so that trace.py runs to
completion shows a different problem: There are only
32 files covered according to the trace output. The
complete test log can be found here:
    http://styx.livinglogic.de/~walter/brokentrace.txt

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?

Bye,
    Walter Dörwald

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/049770.html below:

[Python-Dev] Code coverage tool updated