Repository navigation
Type declarations of base class attributes not carried over to subclasses if None is present #2022
Description
Simplest repro:
class BaseClass:
my_attr = () # type: tuple
class Subclass(BaseClass):
my_attr = None
Output:
testing.py: note: In class "Subclass":
testing.py:5: error: Need type annotation for variable
However, if None isn't the sole value but part of something else, this is likely not the desired behaviour. Consider this:
from typing import Tuple, Any
class BaseClass:
my_attr = ( ("", None), ) # type: Tuple[Tuple[str, Any]]
class Subclass(BaseClass):
my_attr = (
("one", set ),
("two", str ),
("three",None),
)
Output:
testing.py: note: In class "Subclass":
testing.py:8: error: Need type annotation for variable
Changing None for anything else, adding a # type: ignore comment on the ("one", set), line (but not on any other line of the assignment) silences the error. This is somewhat related to #1338 (and, to a lesser extent, #1032).
Activity
gvanrossum commentedon Aug 13, 2016
Yeah, definitely a bug. I think it's related to #1338, the type of class attributes is just not checked against the base classes at all (unlike methods).
For class variables, lookup type in base classes (#1338, #2022, #2211) (
Revert "For class variables, lookup type in base classes (#1338, #2022,
Revert "For class variables, lookup type in base classes (#1338, #2022,
For class variables, lookup type in base classes (#1338, #2022, #2211) (
gvanrossum commentedon Jan 27, 2017
Looking into this again (now that #2510 has been merged) I think there's still something fishy here: I think the first example (in the absence of
--strict-optional) should be silent, since it's essentially equivalent towhich is silent.
(However the second example contains an error, since the subclass uses
attrinstead ofmy_attr. Fixing that, the example correctly complains that the top-level Tuple type in the subclass (of three items) is incompatible with the type from the base class (of 1 item).)Vgr255 commentedon Jan 28, 2017
Whoops, I probably messed up when I copied the repro over. Edited the comment to correct this. I sadly no longer have a use case for this, as the affected code is gone. I still think it's worth fixing, though, and I hope you figure it out. Cheers!
AlexWaygood commentedon Mar 27, 2022
The example code no longer causes a mypy error if you use the
--no-strict-optionaloption (which was the default at the time of the bug being filed). If you don't use the--no-strict-optionaloption, you just need to change the annotations to this:And mypy is fine with it.