Repository navigation
Description
Describe the bug
When running coverage run --branch --module pytest using v7.11.1 in a project that processes non-Python files (in my case, HTML templates), I get the following error.
coverage.exceptions.NotPython: Couldn't parse '/Users/tjkuson/workspace/repro/src/repro/templates/greet.html' as Python source: 'invalid syntax' at line 1`.
This does not happen when using v7.11.0, nor does it happen when I do not measure branch coverage.
To Reproduce
What version of Python are you using?
I am using 3.14, though I have managed to reproduce the error on 3.10 as well.
What version of coverage.py shows the problem? The output of
coverage debug sysis helpful.
I am using v7.11.1 (managed via uv).
$ uv run coverage debug sys
-- sys -------------------------------------------------------
coverage_version: 7.11.1
coverage_module: /Users/tjkuson/workspace/repro/.venv/lib/python3.14/site-packages/coverage/__init__.py
core: -none-
CTracer: available from /Users/tjkuson/workspace/repro/.venv/lib/python3.14/site-packages/coverage/tracer.cpython-314-darwin.so
plugins.file_tracers: -none-
plugins.configurers: -none-
plugins.context_switchers: -none-
configs_attempted: /Users/tjkuson/workspace/repro/.coveragerc
/Users/tjkuson/workspace/repro/setup.cfg
/Users/tjkuson/workspace/repro/tox.ini
/Users/tjkuson/workspace/repro/pyproject.toml
configs_read: /Users/tjkuson/workspace/repro/pyproject.toml
config_file: None
config_contents: -none-
data_file: -none-
python: 3.14.0 (main, Oct 7 2025, 09:34:52) [Clang 17.0.0 (clang-1700.3.19.1)]
platform: macOS-26.0.1-arm64-arm-64bit-Mach-O
implementation: CPython
build: main
Oct 7 2025 09:34:52
gil_enabled: True
executable: /Users/tjkuson/workspace/repro/.venv/bin/python3
def_encoding: utf-8
fs_encoding: utf-8
pid: 28295
cwd: /Users/tjkuson/workspace/repro
path: /Users/tjkuson/workspace/repro/.venv/bin
/opt/homebrew/Cellar/python@3.14/3.14.0_1/Frameworks/Python.framework/Versions/3.14/lib/python314.zip
/opt/homebrew/Cellar/python@3.14/3.14.0_1/Frameworks/Python.framework/Versions/3.14/lib/python3.14
/opt/homebrew/Cellar/python@3.14/3.14.0_1/Frameworks/Python.framework/Versions/3.14/lib/python3.14/lib-dynload
/Users/tjkuson/workspace/repro/.venv/lib/python3.14/site-packages
environment: HOME = /Users/tjkuson
PYTHONSTARTUP = /Users/tjkuson/.config/python/pythonrc.py
command_line: /Users/tjkuson/workspace/repro/.venv/bin/coverage debug sys
time: 2025-11-08 00:13:45What versions of what packages do you have installed? The output of
pip freezeis helpful.
annotated-doc==0.0.3
annotated-types==0.7.0
anyio==4.11.0
certifi==2025.10.5
click==8.3.0
coverage==7.11.1
dnspython==2.8.0
email-validator==2.3.0
fastapi==0.121.0
fastapi-cli==0.0.14
fastapi-cloud-cli==0.3.1
h11==0.16.0
httpcore==1.0.9
httptools==0.7.1
httpx==0.28.1
idna==3.11
iniconfig==2.3.0
jinja2==3.1.6
markdown-it-py==4.0.0
markupsafe==3.0.3
mdurl==0.1.2
packaging==25.0
pluggy==1.6.0
pydantic==2.12.4
pydantic-core==2.41.5
pygments==2.19.2
pytest==8.4.2
python-dotenv==1.2.1
python-multipart==0.0.20
pyyaml==6.0.3
rich==14.2.0
rich-toolkit==0.15.1
rignore==0.7.6
sentry-sdk==2.43.0
shellingham==1.5.4
sniffio==1.3.1
starlette==0.49.3
typer==0.20.0
typing-extensions==4.15.0
typing-inspection==0.4.2
urllib3==2.5.0
uvicorn==0.38.0
uvloop==0.22.1
watchfiles==1.1.1
websockets==15.0.1What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix.
https://github.com/tjkuson/coverage-repro
What commands should we run to reproduce the problem? Be specific. Include everything, even
git clone,pip install, and so on. Explain like we're five!
$ git clone git@github.com:tjkuson/coverage-repro
$ cd coverage-repro
$ uv run coverage run --branch --module pytestExpected behavior
There should be no error.
Additional context
Activity
tjkuson commentedon Nov 8, 2025
I've bisected the regression to 31f91f8
gaige commentedon Nov 8, 2025
I'm seeing the same problem with 7.1.1 (not 7.1.0) in a Django project using jinja2 also on 3.14.
devdanzin commentedon Nov 8, 2025
Seems to be caused by the inclusion of
PythonParser(filename=filename).parse_source():https://github.com/nedbat/coveragepy/blob/31f91f816244a89051b301f2e3536e5f7b951e3d/coverage/sysmon.py#L472-L473
I see two options to fix this:
parse_sourcewhich tells it whether to raiseNotPythonor not.NotPythoninget_multiline_map.I can work on a PR once a way to fix the issue is chosen. I favor the second option, but am not sure there isn't a better one I'm not seeing.
nedbat commentedon Nov 8, 2025
Sorry about this regression, I'll fix it today.
tjkuson commentedon Nov 8, 2025
Thank you! I really appreciate the work you do here.
eirkkr commentedon Nov 8, 2025
Just came across this bug as well, interestingly if I swap to
ctracecore then I don't get the error, but I'll wait for a fix :), thanks @nedbatfix: not-python files shouldn't stop measurement. #2077
nedbat commentedon Nov 8, 2025
Fixed in commit 9f0753b. I thought about issuing a warning when NotPython is caught, but 99% of the time, the measurement will be accurate. It's only a slight chance that lines will be missed, so there's no warning.
nedbat commentedon Nov 8, 2025
This is now released as part of coverage 7.11.2.