[TIP] branch coverage

[Jean-Paul Calderone]

On Fri, 25 Jan 2008 11:42:25 -0500, Benji York <benji at benjiyork.com> wrote:
>Titus Brown wrote:
>> Can you just generate .pyc files in the normal place, i.e. same
>> directory?
>
>I'd worry about the possibility that a bug in the .pyc generation would
>  cause bad byte code to be created that would bite the user at some
>point in the future when they'd forgotten all about their "normal" .pycs
>being overwritten by the trace tool.

These seem to be really good points to me.  Having a bunch of .pycs with
may be instrumented for coverage measurement or which may not be sounds
like a pretty bad situation to be able to get into.  Even if the bytecode
is always flawless, it'd still be terrible to have to dig around inside a
.pyc file to figure out that you're accidentally using the coverage version
and that's why all your code is so slow.

Isolate the code generation from anything that writes to the filesystem.
In fact, isolate the AST generation from anything that generates Python
source or Python bytecode.  These are separate tasks, they don't need to
be tangled together (I don't know what your code looks like now - maybe
there's no tangling and this is a redundant suggestion).

Ideally, there'd be an API that I could drive sort of like this:

    output = file('coverage_lib/foo.py', 'w')
    input = file('foo.py')
    output.write(astToSource(instrumentForCoverageMeasurement(input)))
    output.close()
    input.close()

Maybe a visitor API would be better than this monolithic thing, but the
idea ends up being the same.  It should be easy to customize what happens
with the instrumented code.  There are likely to be a lot of different
use-cases.  You won't be able to satisfy them with any single policy.

Jean-Paul