Repository navigation
Fix nondeterministic type checking caused by nonassociative of None joins - #19158
JukkaL merged 2 commits into
Conversation
Sorry, something went wrong.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Sorry, something went wrong.
JukkaL
left a comment
There was a problem hiding this comment.
Nice! Making join associative would be the ultimate fix, but it will be a heavy lift due to backward compat. Incrementally making things more deterministic is a good way to deal with this in the shorter term.
Sorry, something went wrong.
| colors3: A[str] | B[str] | C[int] | D[None], | ||
| ) -> None: | ||
| for c1, c2, c3 in zip2(colors1, colors2, colors3): | ||
| # TODO: can't do reveal type because the union order is not deterministic |
There was a problem hiding this comment.
I wonder if there is a way to avoid non-deterministic union order altogether, e.g. by not putting types into sets?
Sorry, something went wrong.
There was a problem hiding this comment.
Nvm, you mention this in the issue description.
Sorry, something went wrong.
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