Maybe this is crazy, but I’m looking for advice.
Conceptually, coverage.py is pretty simple. First, using the sys.settrace facility in Python, record every line that is executed. Then, after the program is done, report on those lines, and especially on lines that could have been executed but were not.
Of course, the reality is more difficult. During execution, to record the line, we have to find the file name, which we get from the stack frame. Later, we look for that file by name to create the report. Sometimes, the file isn’t a Python file!
One reason this can happen is if the file was actually created by a tool, and the tool provides the original source file as the reported name. For example, Jinja compiles .html files to Python code, and when the code is running, it claims to be “mytemplate.html”. When coverage.py tries to report on the file, it can’t parse it as Python, and things go wrong.
Originally, this error would be reported to the user. There’s a -i switch that shuts off all errors like this, but it seemed dumb for coverage.py to get confused by something like this. So I changed it to not trace files named “*.html”.
Of course, the world is more varied than that, so I got a report of someone with Jinja2 files named “*.jinja2” which now trip the error. So I need a more general solution.
I figure there are a couple of possibilities:
- Don’t measure files at all if they have an extension that isn’t “.py”. This will let us measure extension-less files, and .py files, and will ignore all the rest, on the theory that any other extension implies that we won’t be able to parse it later anyway.
- Measure all files, but during reporting, if a file can’t be parsed, ignore the error if it has an extenstion that isn’t “*.py”.
- (Shudder) Make a configuration option about what extensions to measure, or which to ignore.
- Some people want “ignore errors” to be the default, but if a file is missing for some reason, it’s important to know, because it will throw off the reporting, and that shouldn’t happen silently.
Do people ever name their Python source files something other than “*.py”? Are there weird ecosystems like this that I’ll only hear about if I make one of these changes?