There, the problem was correctly identified: zip never exhausts the second iterator, because it stops as soon as the first iterator is done. So the second generator never got a chance to finish, so 3->-3 is missing.
I would like to do a better job here, especially because work is underway to make 3->-3 be expressed as, "The generator expression on line 3 never ran," which is not true.
The Python docs say explicitly that filter "Construct[s] an iterator", and next(iter(...)) is going to leave that iterator just as unfinished as it leaves an iterator comprehension expression, so if such a thing is an "un-covered branch", I would expect it to complain equally about both. Is there a reason it doesn't?
In terms of getting around it, # pragma: no branch works, but I'm curious: Do you have a recommendation for this? I suppose I could configure partial_branches to add something like # pragma unfinished iter but I figured I'd ask your opinion. This feels like something that would happen 'all the time', but maybe it's just my Python coding style. :)
@ipmcc The filter isn't getting flagged because the loop is hidden inside the filter implementation. This is the same issue as s.replace("foo", "bar") not knowing whether the implicit if "foo" in s: branch was taken inside replace().
In this code with branch coverage, "Line of interest" is marked as partial (3->-3)
Happens with 4.0.3 and 4.1b2+
The text was updated successfully, but these errors were encountered: