You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cache causes mypy to fail every 2nd run for module importing from google.cloud #13085
This is very similar to #12232. However, I had to modify the minimum working example, because mypy==0.961 fixed the other one.
Bug Report
I have a project that imports things from google.cloud, which is a namespace package as far as I know. In a certain, very specific configuration mypy fails on every second run. This is very similar to #9852 and an almost duplicate of #12232. However, this bug affects the most recent mypy, 0.961. Since the reproducer of #9852 and #12232 are fixed, I open a new bug report.
To Reproduce
The following script does reproduce the problem on Debian Stable and inside the Docker image python:latest.
#!/usr/bin/env bash
VENV=$(mktemp -d)
rm -rf "$VENV"# The order of the imports matters. If one imports datastore first, the error# does not occur. Also, one must suppress the type error on the import of# `storage`, otherwise the error does not appear neither.
cat <<EOF >script.pyfrom google.cloud import storage # type: ignore[attr-defined]from google.cloud.exceptions import NotFoundEOF
python3 -m venv "$VENV"source"$VENV/bin/activate"
python3 -m pip install mypy==0.961 google-cloud-storage==2.0.0 google-cloud-datastore==2.4.0
mypy script.py
mypy script.py
mypy script.py
mypy script.py
Expected Behavior
Pass or fail every time. I am not sure what would be correct in this case.
Actual Behavior
Mypy accepts and rejects the code every 2nd run.
Your Environment
Debian Stable and python:latest. The reproducing script should cover all relevant details.
Thanks for reporting this, can reproduce. I'm sorry that mypy's been doing a such a shoddy job here. There's an element of mypy's module finding logic with respect to namespace packages that is stateful and is the root cause of all this repeated pain. In Guido's words, four years ago: #5016 (review). I'll see if there's yet another small patch that will fix, but I think this might be hard to make bulletproof and be confident about until we rip out that stateful logic. At least test suite will prevent regressions :-)
Okay, I have a patch that fixes this. I think I wrote the same patch last time, but can't remember why I didn't commit it. I think it changed module processing order or something.
I'm sorry that mypy's been doing a such a shoddy job here.
This particular case might work bad, but rest assured that mypy is one of the most important tools in my Python toolchain. Thank you all very much for providing such a great tool that does an incredible job almost all of the time.
Activity
hauntsaninja commentedon Jul 7, 2022
Thanks for reporting this, can reproduce. I'm sorry that mypy's been doing a such a shoddy job here. There's an element of mypy's module finding logic with respect to namespace packages that is stateful and is the root cause of all this repeated pain. In Guido's words, four years ago: #5016 (review). I'll see if there's yet another small patch that will fix, but I think this might be hard to make bulletproof and be confident about until we rip out that stateful logic. At least test suite will prevent regressions :-)
hauntsaninja commentedon Jul 7, 2022
Okay, I have a patch that fixes this. I think I wrote the same patch last time, but can't remember why I didn't commit it. I think it changed module processing order or something.
MaxG87 commentedon Jul 7, 2022
This particular case might work bad, but rest assured that
mypyis one of the most important tools in my Python toolchain. Thank you all very much for providing such a great tool that does an incredible job almost all of the time.Fix caching of PEP 561 namespace packages (#13124)