Fix instance vs tuple subtyping edge case#18664
Conversation
This comment has been minimized.
This comment has been minimized.
JukkaL
left a comment
JukkaL
left a comment
There was a problem hiding this comment.
Is it possible to write a test case for this? Even if the tests case was passing on master, could we have something to catch the original issue?
mypy/subtypes.py
Outdated
| """Is this an instance where all args are Any types?""" | ||
| if not t.args: | ||
| return False | ||
| for arg in map(get_proper_type, t.args): |
There was a problem hiding this comment.
I don't thin mypyc can optimize this properly. Putting the get_proper_type call in the loop body would probably be significantly faster, since this could plausibly be used in perf critical code path.
There was a problem hiding this comment.
OK, sure, I will change this now.
Do you mean like an "integration" test in |
This comment has been minimized.
This comment has been minimized.
JukkaL
left a comment
JukkaL
left a comment
There was a problem hiding this comment.
It's good if the unit test can be trusted.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Previously a code path was introduced that made fallback a subtype of its tuple type for non-generic tuples, while the intention was to cover `tuple[Any, ...]` and similar. I add a unit test + some refactoring to make this mistake much harder in future. This may need to wait for python#18663 to avoid "regressions" (the other fix needed to avoid "regressions" is already merged).
2 participants
Previously a code path was introduced that made fallback a subtype of its tuple type for non-generic tuples, while the intention was to cover
tuple[Any, ...]and similar. I add a unit test + some refactoring to make this mistake much harder in future.This may need to wait for #18663 to avoid "regressions" (the other fix needed to avoid "regressions" is already merged).