-
-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
annotate: does not handle if False
properly / consistently
#659
Comments
Do people really use annotate? It seems really clumsy compared to the HTML report. You are right, this is a bug, but is it worth fixing? |
I find it useful to inspect a single file quickly, but that is currently often related to developing covimerage (which uses coveragepy internally). Therefore not a ocmmon use case. It's unfortunate that it is a bit fragile then, especially when using it for debugging. I've found another issue now, which might be related, where a line not being executable gets marked as uncovered. This simple check might also help here. |
I think factoring out the handling of Then I could also imagine to have a new command |
FWIW: the html reporter displays only line 3 as executed (correctly), and 1-2 as not executed (known limitation). I think it is better to keep the output of annotate and html in sync, so I've created #677. |
This is an interesting idea. Instead of "annotate_file", I'd call the command "show". One thing to note: coverage has no prerequisites. It would be tempting to use an existing library for terminal colors, etc, but I would rather not. Also, do we end up in the quagmire of "themes" for the coloring? Somehow it's never been requested for the HTML reports, but I know what color the background will be in the HTML reports. Terminals might not be so compliant. |
Originally reported by Anonymous
coverage annotate
considers lines afterif False
to be covered:I know that
if False
is a special case (optimization), butAnnotateReporter.annotate_file
should handle it properly.analysis.statements
is[3]
in this case, that's why thecovered
logic kicks in later only.Since
covered
gets not updated for theif False
, it will be considered to be uncovered in the following case, because the previous line setscovered=False
:The text was updated successfully, but these errors were encountered: