-
Notifications
You must be signed in to change notification settings - Fork 76
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
Enforce type checking in tests and CI #885
Conversation
I'm kind of surprised that the type annotations in |
@fpagnoux Add |
It looks like mypy, at least in its current version, doesn't fully enforce class attributes types annotations. The following code doesn't raise any error: class Test:
def __init__(self):
self.dict: Dict[str, int] = {}
def get(self, key) -> str: # inconsistent with the attribute type, should be int
return self.dict[key] Yet the following does: from typing import Dict
class Test:
def __init__(self):
self.dict = {}
def get_dict(self) -> Dict[str, int]:
return self.dict
def get(self, key) -> str:
return self.get_dict()[key] test.py:12: error: Incompatible return value type (got "int", expected "str") It looks like mypy enforces better function signatures than attributes type. However, they're not totally ignored, as the following does raise an error: from typing import Dict
class Test:
def __init__(self):
self.dict: Dict[str, str] = {}
def get_dict(self) -> Dict[str, int]:
return self.dict test.py:9: error: Incompatible return value type (got "Dict[str, str]", expected "Dict[str, int]") |
I've open an issue to try to understand better mypy's behaviour, and see if this is a bug likely to get resolved. |
See also this recent and possibly relevant article. I don't think the criticisms therein would necessarily stop me from trying out types. I feel better for knowing about this beforehand though. |
We've got a reply. It looks like you need to add Doing so in simulation_builder raises an error at least for one annotation ( How should we move forward with this PR? I think I've seen/read/experimented enough to be wiling to try enforcing type checking in our codebase, but we could delay that if @sandcha and you would like more time to form an opinion. |
I'm OK to merge, on the understanding that it's an experimental feature; the response to an unexpected breaking build might be to disable the checking if there's no clear way to fix the type annotations. How does that sound? |
Sounds good to me! |
Extracted from #871
Typing remains optional: the type checker will only make sure that the optional annotations are consistent with the code.
Why typing ?