-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Covariant generic type context results in confusing message with __add__ #5971
Comments
After your investigation, how this relates to #5874? I mean are you going to skip the outer context only for dunders, or use some heuristics for context, or both? |
I think that these are separate issues. Here the issue is with a covariant generic type in type context, whereas #5874 has invariant context. I'm not yet sure what's the best way to fix this. And this issue has two components -- the confusing error message and the unexpected inferred type. |
Looks like not using type context for type inference if it's a covariant generic type at least doesn't break many tests. I'll see how it works with Dropbox internal codebases tomorrow. |
Not using type context for type inference breaks causes lots of issues and does not look like a good option. I'm going to try an alternative where we don't infer anything from a union of type variables, as this causes ambiguity. This should also fix #5874. |
Note that here actually the return type is |
This one intends to work around python/mypy#5971 Given a: Sequence[object] b1: List[Any] b2: List[int] now both a = b1 + b2 a = b2 + b1 will pass.
This generates a false positive on the last line:
The error message is confusing, since
B[Any]
andB[int]
are compatible.We perhaps shouldn't use the type context from
a
for type inference in this case.This issue affects built-in
list
andSequence
type context with the latest typeshed master.The text was updated successfully, but these errors were encountered: