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
Attribute compatibility checks should take compatibility into consideration #2454
changed the title [-]Attribute compatibility checks should take inheritance into consideration[/-][+]Attribute compatibility checks should take compatibility into consideration[/+]on Nov 14, 2016
In the first example Y might have a method that expects attr to be a B, and if that method is called on a Z instance it might be disappointed. So maybe Z.attr should have type B?
FWIW I tried with X inheriting from Y or vice versa, and both are allowed. That seems strange?
In the first example Y might have a method that expects attr to be a B, and if that method is called on a Z instance it might be disappointed. So maybe Z.attr should have type B?
Maybe then it should just be like I said in the second comment, that the child class can explicitly set it to a type to silence the error? That way, it's up to the user to figure out what they want to do.
So the current error is correct.
I think you should not be allowed to override it without `# type: ignore`.
But then we still have a bug when X derives from Y or Y from X.
Attribute compatibility across a class hierarchy is only safe if it's invariant, since attributes are mutable. This is similar to why List[T] is invariant. As pointed out by Guido, You can use # type: ignore to force mypy to accept covariant overriding.
It's a separate issue that mypy only detects attribute incompatibility when it's caused by multiple inheritance (see #2510).
Closing this as the generated errors for the original examples seem correct, though perhaps we should document this more clearly.
Activity
[-]Attribute compatibility checks should take inheritance into consideration[/-][+]Attribute compatibility checks should take compatibility into consideration[/+]refi64 commentedon Nov 14, 2016
As an extension to this, maybe also attributes declared in the derived class could override it:
gvanrossum commentedon Nov 14, 2016
In the first example Y might have a method that expects attr to be a B, and if that method is called on a Z instance it might be disappointed. So maybe Z.attr should have type B?
FWIW I tried with X inheriting from Y or vice versa, and both are allowed. That seems strange?
refi64 commentedon Nov 14, 2016
@gvanrossum
True, but then you lose some type safety:
Maybe then it should just be like I said in the second comment, that the child class can explicitly set it to a type to silence the error? That way, it's up to the user to figure out what they want to do.
gvanrossum commentedon Nov 15, 2016
JukkaL commentedon Jan 16, 2017
Attribute compatibility across a class hierarchy is only safe if it's invariant, since attributes are mutable. This is similar to why
List[T]is invariant. As pointed out by Guido, You can use# type: ignoreto force mypy to accept covariant overriding.It's a separate issue that mypy only detects attribute incompatibility when it's caused by multiple inheritance (see #2510).
Closing this as the generated errors for the original examples seem correct, though perhaps we should document this more clearly.