-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Type override for attributes is not checked #2211
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
Comments
IIRC there's an issue for this already. It's definitely a bug.
…--Guido (mobile)
|
I have looked before opening but couldn't find one... After a second look, there's a mention to this in #1338 , but they seem to be two related but distinct issues. |
Still I suspect that they can be fixed with one PR. Shouldn't even be that
hard.
|
JukkaL
pushed a commit
that referenced
this issue
Nov 28, 2016
#2380) * For class variables, lookup type in base classes (#1338, #2022, #2211) * Ignore TypeVars from base class when looking up types of class variables * Break even if the base type is a TypeVar This avoids looking into the base class of a base class while the type has been changed * Support TypeVar when lookup up class variables in a base class * An additional test-case to see if TypeVars are resolved with an extra subclass * Also handle TypeVars in, for example, a List * Fix initial test-case * Validate if type is defined with an incompatible value against the type of a base class * Additional test case to ensure methods/variables don't overwrite each other * Also support properties * Add test case to show class variable type can be overwritten with Any
gvanrossum
added a commit
that referenced
this issue
Nov 28, 2016
gvanrossum
added a commit
that referenced
this issue
Nov 28, 2016
gvanrossum
pushed a commit
that referenced
this issue
Jan 27, 2017
Fixed by #2510. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
from what I see, overriding an attribute with an incompatible type (which can lead to unsoundness) does not produce any kind of warning with mypy:
The code above shows that mypy thinks that the
d.f()
expression is a string, while it's actually an int. Shouldn't this kind of redefinitions be forbidden?The text was updated successfully, but these errors were encountered: