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
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.
The text was updated successfully, but these errors were encountered:
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.
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
.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.The text was updated successfully, but these errors were encountered: