Skip to content
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 incompatible overrides of overloaded methods in concrete subclasses #14017

Merged
merged 7 commits into from
Nov 10, 2022

Conversation

hauntsaninja
Copy link
Collaborator

Fixes #14002

for item in original_type.items
if not item.arg_types or is_subtype(active_self_type, item.arg_types[0])
]
if filtered_items:
Copy link
Member

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 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].

Copy link
Collaborator Author

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 a Callable[..., Any] ... I'll add a comment and if it ever comes up we can reconsider

@github-actions

This comment has been minimized.

@hauntsaninja
Copy link
Collaborator Author

I think the mypy_primer hits are from a different bug, will fix in another PR

hauntsaninja added a commit to hauntsaninja/mypy that referenced this pull request Nov 5, 2022
hauntsaninja added a commit that referenced this pull request Nov 6, 2022
@github-actions

This comment has been minimized.

@hauntsaninja
Copy link
Collaborator Author

Hmm, there are still some issues involving type variables:

from typing import overload, TypeVar, Union

ZAT = TypeVar("ZAT", bound="ZA")

class ZA:
    @overload
    def f(self: ZAT, x: int) -> ZAT: ...
    @overload
    def f(self, x: str) -> None: ...
    @overload
    def f(self: ZAT) -> bytes: ...
    def f(*a, **kw): ...

class ZB(ZA):
    @overload
    def f(self, x: int) -> ZB: ...
    @overload
    def f(self, x: str) -> None: ...
    def f(*a, **kw): ...

^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
Copy link
Collaborator Author

Okay I added the xfail test. The correct solution probably involves the bind_self code. I think some of the pandas errors might come back once it's fixed too

@github-actions
Copy link
Contributor

github-actions bot commented Nov 6, 2022

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

@hauntsaninja
Copy link
Collaborator Author

Let me know if you think the new false negative is not acceptable

Copy link
Member

@JelleZijlstra JelleZijlstra left a 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!

@hauntsaninja hauntsaninja merged commit a48dd5a into python:master Nov 10, 2022
@hauntsaninja hauntsaninja deleted the generic-self branch November 10, 2022 23:37
hauntsaninja added a commit to hauntsaninja/mypy that referenced this pull request Mar 11, 2023
Fixes python#14866

Basically does the potential todo I'd mentioned in python#14017
JelleZijlstra pushed a commit that referenced this pull request Mar 11, 2023
…4882)

Fixes #14866

Basically does the potential todo I'd mentioned in #14017
hauntsaninja added a commit to hauntsaninja/mypy that referenced this pull request Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect incompatible override report with self type + overload
2 participants