Fix incompatible overrides of overloaded methods in concrete subclasses#14017
Fix incompatible overrides of overloaded methods in concrete subclasses#14017hauntsaninja merged 7 commits intopython:masterfrom
Conversation
d986d87 to
5c90d1e
Compare
| for item in original_type.items | ||
| if not item.arg_types or is_subtype(active_self_type, item.arg_types[0]) | ||
| ] | ||
| if filtered_items: |
There was a problem hiding this comment.
If there are no filtered_items, shouldn't we always treat the override as compatible? e.g. in your F test below, I think the override is actually compatible: the base class says nothing about what the method should return if self is an A[bytes].
There was a problem hiding this comment.
Yeah, I wasn't sure about this, but it seemed like a weird situation so I chose to fail. Feels sketchy to introduce a Callable[..., Any] ... I'll add a comment and if it ever comes up we can reconsider
This comment has been minimized.
This comment has been minimized.
|
I think the mypy_primer hits are from a different bug, will fix in another PR |
Discovered as part of python#14017
Discovered as part of #14017
This comment has been minimized.
This comment has been minimized.
|
Hmm, there are still some issues involving type variables: ^this correctly gives an error on master, but this PR removes the error. Given that this fixes a real issue I might add an xfail test and merge anyway, but let me see if I can figure out a change to make this work as well |
|
Okay I added the xfail test. The correct solution probably involves the |
|
Diff from mypy_primer, showing the effect of this PR on open source code: pandas-stubs (https://github.com/pandas-dev/pandas-stubs)
+ pandas-stubs/core/series.pyi:1752: error: Unused "type: ignore" comment
pandas (https://github.com/pandas-dev/pandas)
+ pandas/core/series.py:3380: error: Unused "type: ignore" comment
+ pandas/core/series.py:5132: error: Unused "type: ignore" comment
+ pandas/core/frame.py:5531: error: Unused "type: ignore" comment
|
|
Let me know if you think the new false negative is not acceptable |
JelleZijlstra
left a comment
There was a problem hiding this comment.
The xfail case seems fairly contrived and false negatives are better than false positives, so I think this is an improvement. Thanks!
Fixes python#14866 Basically does the potential todo I'd mentioned in python#14017
Fixes #14002