-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Spurious error with constrained type variables in generic functions #5493
Comments
Thanks for reporting! Here is a simpler repro (that also is cleaner, since your original repro uses some questionable patterns): class A:
pass
class B(A):
pass
class C:
pass
LooseType = TypeVar('LooseType', A, B, C)
def foo(xs: List[LooseType]) -> LooseType:
return xs[0]
StrictType = TypeVar('StrictType', B, C)
def bar(xs: List[StrictType]) -> StrictType:
foo(xs)
return xs[0] It seems to me (but this is a pure guess). This is subtle combination of #4872 and how functions with restricted type variables are checked. |
Actually I uses from typing import TypeVar, List
class A:
pass
class B(A):
pass
class C:
pass
LooseType = TypeVar('LooseType', A, B, C)
ListType = List[LooseType]
def foo(xs: ListType[LooseType]) -> LooseType:
return xs[0]
StrictType = TypeVar('StrictType', B, C)
def bar(xs: ListType[StrictType]) -> StrictType:
return foo(xs) (Only last two lines are changed.) And this causes one more error with inheritance:
It does not exist neither if |
Fixes #4872 Fixes #3876 Fixes #2678 Fixes #5199 Fixes #5493 (It also fixes a bunch of similar issues previously closed as duplicates, except one, see below). This PR fixes a problems when mypy commits to soon to using outer context for type inference. This is done by: * Postponing inference to inner (argument) context in situations where type inferred from outer (return) context doesn't satisfy bounds or constraints. * Adding a special case for situation where optional return is inferred against optional context. In such situation, unwrapping the optional is a better idea in 99% of cases. (Note: this doesn't affect type safety, only gives empirically more reasonable inferred types.) In general, instead of adding a special case, it would be better to use inner and outer context at the same time, but this a big change (see comment in code), and using the simple special case fixes majority of issues. Among reported issues, only #5311 will stay unfixed.
Fixes python#4872 Fixes python#3876 Fixes python#2678 Fixes python#5199 Fixes python#5493 (It also fixes a bunch of similar issues previously closed as duplicates, except one, see below). This PR fixes a problems when mypy commits to soon to using outer context for type inference. This is done by: * Postponing inference to inner (argument) context in situations where type inferred from outer (return) context doesn't satisfy bounds or constraints. * Adding a special case for situation where optional return is inferred against optional context. In such situation, unwrapping the optional is a better idea in 99% of cases. (Note: this doesn't affect type safety, only gives empirically more reasonable inferred types.) In general, instead of adding a special case, it would be better to use inner and outer context at the same time, but this a big change (see comment in code), and using the simple special case fixes majority of issues. Among reported issues, only python#5311 will stay unfixed.
Reproduction:
This is denied with error reporting:
Is this really not allowed? If
B
is not derived fromA
, then everything is ok.In my original code, the container of
A
,B
andC
isDict[List[Tuple[LooseType, str]]]
. I cannot changeList
toSequence
because I needappend
method.In addition, the notes disappear in complicated case.
The text was updated successfully, but these errors were encountered: