-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Fix instance vs tuple subtyping edge case #18664
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
Fix instance vs tuple subtyping edge case #18664
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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).