<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Ah, the joys of code optimizers. The peephole optimizer recognizes
your code and optimizes away the continue, essentially turning your
if statement into a jump directly to the beginning of the loop. All
of your tests that change the continue into a different statement
break that optimization, and "prove" to you that the statement is
executed. Coverage.py can't measure the continue as being executed
because Python never reports that it is executed.<br>
<br>
When I first discovered this in my own code, I thought, "We've seen
this before: C compilers have switches to disable optimizations for
precisely this sort of reason." I wrote a bug against Python asking
for a way to disable optimizations in those cases where it's more
important to reason about the code than for the code to run
quickly. The bug is here: <a class="moz-txt-link-freetext" href="http://bugs.python.org/issue2506">http://bugs.python.org/issue2506</a> , it was
frustratingly closed as "won't fix". Raymond Hettinger has argued
against complicating the optimizer in other places, mostly, it seems
due to a lack of automated testing of the optimizer, and the fear
that comes from that realization. Ironically, the best way to test
an optimizer is to provide a way to completely disable it, and then
to run code twice, once with optimization and once without, and see
that they produce the same results.<br>
<br>
Any help you can provide to get people on board with a well-tested
optimizer that can be completely disabled, would be appreciated.
Until then, there's nothing to do except add a "#pragma: no cover"
comment to that line.<br>
<br>
--Ned.<br>
<br>
On 7/2/2011 5:22 PM, Laurens Van Houtven wrote:
<blockquote
cite="mid:CAE_Hg6auJZZTs5L+QgbL_rbH0VzQhjcAx8MykzBO8Nu6dHttVQ@mail.gmail.com"
type="cite">Hey.<br>
<br>
I'm experiencing some strange behavior. I have a loop, and when I
continue to the next element on some condition, it told me that
line wasn't covered. Then, I put a pdb.set_trace() in, and I saw
that it was, in fact, being run. I put a raise ValueError()
instead of that "continue", and it raised. I replaced "continue"
with "break", and now coverage.py thinks the line is covered.<br>
<br>
What could be going on? Here's the diff:<br>
<br>
=== modified file 'twisted/positioning/nmea.py'<br>
--- twisted/positioning/nmea.py 2011-07-02 18:40:44 +0000<br>
+++ twisted/positioning/nmea.py 2011-07-02 21:14:31 +0000<br>
@@ -552,7 +552,7 @@<br>
prn, azimuth, elevation, snr = values<br>
<br>
if prn is None or snr is None:<br>
- break<br>
+ continue<br>
<br>
satellite = base.Satellite(prn, azimuth, elevation,
snr)<br>
self._sentenceData['_partialBeaconInformation'].beacons.add(satellite)<br>
<br>
<br>
The code lives in lp:~lvh/twisted/positioning.<br>
<br clear="all">
The strange thing is even trial --coverage (which is unrelated to
coverage.py...) thinks it's not covered. How can that be?<br>
<br>
cheers
<div>lvh</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
testing-in-python mailing list
<a class="moz-txt-link-abbreviated" href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a>
<a class="moz-txt-link-freetext" href="http://lists.idyll.org/listinfo/testing-in-python">http://lists.idyll.org/listinfo/testing-in-python</a>
</pre>
</blockquote>
</body>
</html>