You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Incorrect type inference in Derived class that was explicitly typed in Base #12268
test.py:12: error: Incompatible types in assignment (expression has type "List[A]", base class "Base" defined the type as "List[Union[A, B]]")
test.py:12: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
test.py:12: note: Consider using "Sequence" instead, which is covariant
Found 1 error in 1 file (checked 1 source file)
The error is on the last line. The complaint is that variable1 is of type List[A], and so it cannot be assigned to variable2. At first, this seems reasonable, but notice that the type of variable1 is explicitly defined to be List[Union[A, B]] in the superclass. More interesting still is that the previous line, line 11, is accepted just fine.
I believe Derived types should inherit their superclass types if possible before resorting to a type inference.
I'm trying to file a PR for this but am struggling to navigate the codebase. My understanding of the problem is that although variable1 is type-checked in the base, and MyPy correctly type checks that assignment, it still infers the type of variable1. The problem is, I don't know in what function this should be fixed.
Basically, on line 2256 of checker.py, the inferred value is generated. Even after checking the type with the supertype on line 2280, the inferred type is still used. However, I don't have access to the base type in this class or anything. Maybe I should be looking elsewhere?
Closed PR because this seems like an anti-feature. I think the real issue we want to solve has something more subtle to do with variance. I'll file in a separate PR.
For what it's worth, pyright implements the behavior you're describing here. I don't consider it an anti-feature :).
It seems logical to me that a type declaration should always take precedence, and type inference should be used only in cases where a declaration is missing. Mypy applies this rule for local variables and for instance/class variables within a class, but it doesn't do it for inherited instance/class variables.
Is this behavior intended, or is it a bug / oversight? I'd be curious to hear from core mypy developers.
classBase:
# Base class contains type declaration for "var1"var1: float|NoneclassDerived(Base):
# Child class contains assignment but no declarationvar1=0reveal_type(Derived().var1) # Pyright: float | None, Mypy: int
Activity
Riolku commentedon Mar 2, 2022
I'm trying to file a PR for this but am struggling to navigate the codebase. My understanding of the problem is that although
variable1is type-checked in the base, and MyPy correctly type checks that assignment, it still infers the type ofvariable1. The problem is, I don't know in what function this should be fixed.Basically, on line 2256 of checker.py, the inferred value is generated. Even after checking the type with the supertype on line 2280, the inferred type is still used. However, I don't have access to the base type in this class or anything. Maybe I should be looking elsewhere?
infer types from base if not explicitly typed
infer types from base if not explicitly typed
Riolku commentedon Mar 3, 2022
Closed PR because this seems like an anti-feature. I think the real issue we want to solve has something more subtle to do with variance. I'll file in a separate PR.
use base type as hint when inferring
erictraut commentedon Mar 3, 2022
For what it's worth, pyright implements the behavior you're describing here. I don't consider it an anti-feature :).
It seems logical to me that a type declaration should always take precedence, and type inference should be used only in cases where a declaration is missing. Mypy applies this rule for local variables and for instance/class variables within a class, but it doesn't do it for inherited instance/class variables.
Is this behavior intended, or is it a bug / oversight? I'd be curious to hear from core mypy developers.
Riolku commentedon Mar 3, 2022
I don't know. Have you looked at the open source snippets I mentioned? I want the code there to still work.
Riolku commentedon Mar 4, 2022
Sorry, said snippet is in the old closed PR.
Riolku commentedon Mar 4, 2022
I re-opened because I think that this could be fixed by #12284
would fix python#12268
Fixes python#12268
force github to link issue
erictraut commentedon Aug 13, 2023
This appears to have been fixed in mypy 0.9.0. I think it can be closed.