[TIP] branch coverage

Andrew Dalke dalke at dalkescientific.com
Thu Jan 24 16:02:31 PST 2008


  m h <sesquile at gmail.com> wrote:
> I think generate both if you could.  The python code may be ugly, but
> it does an excellent job of explaining how complicated code can
> actually get.  I also serves well to illustrate the differences
> between the different types of coverage (line, branch, path).


I've been trying to figure out how to handle more complicated  
situations, like

if (1 + (a or b) and (c if d else e) - 8):
   ...

It gets pretty hairy.  In essence

    AND(
        PLUS(1, OR(a, b)),
        MINUS(IF_EXPR(d, c, e), 8)
       )

which gets turned into

result_1 = 1
if a:
   test_is_true(1)
   result_2 = a
else:
   test_is_false(1)
   result_2 = b
result_1 = result_1 + result_2

if result_1:
   test_is_true(2)
   if d:
     test_is_true(3)
     result_3 = c
   else:
     test_is_false(3)
     result_3 = e
   result_4 = result_3 - 8

   if result_4:
     test_is_true(4)
     result_5 = True
   else:
     test_is_false(4)
     result_5 = False
else:
   test_is_false(2)
   result_5 = False

if result_5:
    ...

The byte compiler already does this so adding support for calling  
"test_is_true" and "test_is_false", and statement coverage, would be  
simple.  I think.

I don't think anyone's going to sit down and get anything more  
informative from this level of detail, when documentation (ha!  this  
is an idea for a lightning talk) would be as educational or more.

In addition, the line numbers will be wrong, the comments stripped,  
line continuations removed, and probably it'll be more messed up than  
that.


On Jan 24, 2008, at 9:16 PM, Titus Brown wrote:

> Can you just generate .pyc files in the normal place, i.e. same
> directory?  How would this affect 'execfile'd code -- presumably you'd
> need to treat scripts differently...

I'm worried about any confusion between instrumented .pyc vs.  
normal .pyc.  Eh, but I'll start out simple and see what confusion  
happens.

> IMO only, but I think people will want as much detail as possible.

I'm thinking that the instrumentation compiler could take an optional  
flag saying which module should be imported for event logging.   
People who want more details could easily do that.

But if you want more detail, there'll be a full Python parser so you  
can do whatever you want. :)


On Jan 24, 2008, at 10:11 PM, Kumar McMillan wrote:
> did you think about using the tokenize module?
> http://docs.python.org/lib/module-tokenize.html


I'm using some of the tokenize module.  I wanted everything to be in  
PLY, although it wouldn't be too hard to make an adapter between  
them.  I think that tokenize is a more concise module than my code,  
although mine also checks for the indentation level.

I'm basing it on work I did to understand how to parse indentation  
based languages.  See for examples my GardenSnake and LOLPython  
implementations.

http://www.dalkescientific.com/writings/diary/archive/2006/08/30/ 
gardensnake_language.html
http://www.dalkescientific.com/writings/diary/archive/2007/06/01/ 
lolpython.html



On Jan 24, 2008 1:54 PM, m h <sesquile at gmail.com> wrote:
> If I call a function, I want to
> know what parts of code were executed during that call.  And I want it
> to be separate from other invocations of that function.


Let me get the code into a shape where it makes sense to anyone else  
and then you can have fun.  :)

(And all the Lisp users are probably laughing, saying "Python needs  
macros - duh!" :)



				Andrew
				dalke at dalkescientific.com





More information about the testing-in-python mailing list