Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork3.1k
Fix incompatible overrides of overloaded methods in concrete subclasses#14017
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| foriteminoriginal_type.items | ||
| ifnotitem.arg_typesoris_subtype(active_self_type,item.arg_types[0]) | ||
| ] | ||
| iffiltered_items: |
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.
If there are no filtered_items, shouldn't we always treat the override as compatible? e.g. in yourF test below, I think the override is actually compatible: the base class says nothing about what the method should return if self is anA[bytes].
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.
Yeah, I wasn't sure about this, but it seemed like a weird situation so I chose to fail. Feels sketchy to introduce aCallable[..., 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.
hauntsaninja commentedNov 5, 2022
I think the mypy_primer hits are from a different bug, will fix in another PR |
Discovered as part ofpython#14017
This comment has been minimized.
This comment has been minimized.
hauntsaninja commentedNov 6, 2022
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 |
hauntsaninja commentedNov 6, 2022
Okay I added the xfail test. The correct solution probably involves the |
Diff frommypy_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" commentpandas (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 |
hauntsaninja commentedNov 10, 2022
Let me know if you think the new false negative is not acceptable |
JelleZijlstra left a comment
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.
The xfail case seems fairly contrived and false negatives are better than false positives, so I think this is an improvement. Thanks!
Fixespython#14866Basically does the potential todo I'd mentioned inpython#14017
Fixes#14002