-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Let overload item have a wider return type than implementation #12434
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
Labels
Comments
JukkaL
added a commit
that referenced
this issue
Mar 23, 2022
A wider return type can be useful if a decorator used for the overload implementation gets a more precise return type as part of a typeshed update. Closes #12434.
8000
This seems like the same issue as #11373. |
JukkaL
added a commit
that referenced
this issue
Mar 24, 2022
A wider return type can be useful if a decorator used for the overload implementation gets a more precise return type as part of a typeshed update. Closes #12434.
@pranavrajpal Correct! I also closed #11373. |
JukkaL
added a commit
that referenced
this issue
Mar 24, 2022
A wider return type can be useful if a decorator used for the overload implementation gets a more precise return type as part of a typeshed update. Closes #12434.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A wider return type can be useful if a decorator gets a more precise error type as part of a typeshed update.
@wrobell reported this concrete example in #12021 (comment):
Mypy 0.940 got a more precise type for
@asynccontextmanager
, and this resulted in apparent false positives:I think that we can allow an overload item to have a more general return type than the implementation, for convenience.
The text was updated successfully, but these errors were encountered: