figleaf confused by python2.5

[warner]

I'm seeing some messed up code-coverage data coming out of 'make test-figleaf' runs when using python2.5 (since debian/sid recently upgraded). The results suggest that we don't have as good test coverage as we really do.

The main problem I've seen is with multi-line parenthesis-wrapped expressions, like this:

 323.         extra_lease_offset = (self.HEADER_SIZE
 324.                               + 4 * self.LEASE_SIZE
 325.                               + data_length)

When test-figleaf is run under python2.5, the report says that line 323 is unexecuted code, line 324 is not code, and line 325 is executed code. Under python2.4, the report says that line 323 is executed code, and both 324 and 325 are non-code.

The net results are annoying. With python2.4, figleaf reports 820 lines uncovered out of 12297 lines total (which I think is pretty accurate, with the exception of the code in allmydata/init.py that is just plain weird, see #109). But the python2.5 results claim 1104 lines uncovered out of 13175 total.

I suspect that a change in the python2.5 tracing output is confusing figleaf. We've hacked up figleaf in several ways.. perhaps there are some fixes upstream that we might be able to apply to our local copy.

[zooko]

What version of figleaf?

[zooko]

What local copy?

<Zooko goes to look in our source code for a copy of figleaf...>

[zooko]

​http://allmydata.org/trac/tahoe/browser/src/allmydata/util

I will see if I can make it so that we re-use figleaf as a package, submit any patches that we need to make to figleaf upstream, and so on...

[warner]

I'm also seeing multi-line method definitions having similar problems, like:

   def foo(arg1, arg2,
           arg3,
           arg4,
           arg5):

in which the first line appears as uncovered code, and the second appears as non-code.

There may be changes in both the tracing data and the parser (which figleaf uses to decide what counts as code and what doesn't).

[zooko]

If you like this ticket, you may also like #810 (where did figleaf_htmlizer.py come from?), #109 (current upstream figleaf doesn't do the right thing), and #623 (figleaf: compute+display differential coverage).

[warner]

FWIW, the upstream version of figleaf appears to be even more confused by py2.6 . I have not yet seen an up-to-date handles-current-python version of figleaf anywhere.

[zooko]

We no longer care about this ticket because #930 (switch from figleaf to coverage.py).