8000 Nondeterministic type checking on pytorch/vision · Issue #19121 · python/mypy · GitHub
[go: up one dir, main page]

Skip to content

Nondeterministic type checking on pytorch/vision #19121

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

Closed
hauntsaninja opened this issue May 20, 2025 · 5 comments · Fixed by #19147 or #19158
Closed

Nondeterministic type checking on pytorch/vision #19121

hauntsaninja opened this issue May 20, 2025 · 5 comments · Fixed by #19147 or #19158
Labels
bug mypy got something wrong

Comments

@hauntsaninja
Copy link
Collaborator

Repro with e.g. mypy_primer --new 'v1.15' --old 'v1.15' -k vision --debug:

diff --git a/mypy_primer/projects.py b/mypy_primer/projects.py
index 09c050c..0309cff 100644
--- a/mypy_primer/projects.py
+++ b/mypy_primer/projects.py
@@ -547,7 +547,7 @@ def get_projects() -> list[Project]:
         ),
         Project(
             location="https://github.com/pytorch/vision",
-            mypy_cmd=None,  # "{mypy}",
+            mypy_cmd="{mypy}",
             pyright_cmd="{pyright}",
             deps=["numpy", "pillow"],

Linking hauntsaninja/mypy_primer#161

@sterliakov
Copy link
Collaborator

One more example with random primer diffs on xarray, it only started appearing recently: #19102 (comment)

@hauntsaninja
Copy link
Collaborator Author

xarray might be a newer regression, since I can't repro with a few runs of mypy_primer --new 'v1.15' --old 'v1.15' -k pydata/xarray --debug --output concise. I'll try to bisect it later

@sterliakov
Copy link
Collaborator
sterliakov commented May 23, 2025 via email

@hauntsaninja
Copy link
Collaborator Author

Simple minimised version of torchvision:

printf '
def draw(
    colors1: list[str | tuple[int, int, int]] | str | tuple[int, int, int] | None,
    colors2: list[str | tuple[int, int, int]] | str | tuple[int, int, int] | None,
) -> None:
    for c1, c2 in zip(colors1, colors2):
        reveal_type(c1)
        reveal_type(c2)
' > test.py


first_output="$(mypy test.py)"
echo "$first_output"
echo "----------"
for run in {2..10}; do
  current_output="$(mypy test.py)"
  echo "$current_output"
  echo "----------"
  if [[ "$current_output" != "$first_output" ]]; then
    echo output mismatch
    exit 1
  fi
done

Also linking #16979 and #18125

@hauntsaninja
Copy link
Collaborator Author

The vision one will be fixed by #19147

I think something similar will fix xarray. Both of these look like nonassociative issue (not a noncommutative issue!). I will do it in a follow up PR

hauntsaninja added a commit that referenced this issue May 28, 2025
#19147)

I thought about doing this in `join_type_list`, but most callers look
like they do have some deterministic order.

Fixes #19121 (torchvision case only, haven't looked at xarray)

Fixes #16979 (OP case only, bzoracler case fixed by #18402)
JukkaL pushed a commit that referenced this issue May 28, 2025
…oins (#19158)

Fixes #19121 (xarray case)

See #19147 for context 

The ordering of the union is still nondeterministic. We could solve this
by change the solver to use `dict[Type, None` instead of `set[Type]`
since dicts are ordered. But doing so could paper over further bad
solving from nonassociativity or noncommutativity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong
Projects
None yet
2 participants
0