-
-
Notifications
You must be signed in to change notification settings - Fork 986
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
Type Hints for Optim module and Setup MyPy as part of CI #2853
Conversation
@@ -103,7 +104,7 @@ def step(self, closure=None): | |||
|
|||
return loss | |||
|
|||
def _step_param(self, group, p): | |||
def _step_param(self, group: Dict, p) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I din't get what p is and the datatype is expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe p
is the parameter to be differentiated and is of type torch.Tensor
(it may or may not be the narrower type torch.nn.Parameter
)
@@ -144,7 +145,7 @@ def _step_param(self, group, p): | |||
step = _transform_inverse(exp_avg / denom, time_dim, duration) | |||
p.data.add_(step.mul_(-step_size)) | |||
|
|||
def _step_param_subsample(self, group, p, subsample): | |||
def _step_param_subsample(self, group: Dict, p, subsample) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The expected datatype of p and subsample?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @kamathhrishi thanks so much for starting this effort! Looks great so far.
I have a few general questions for the broader effort that make sense to address in this PR:
- Should we add a typechecking stage to CI? (using
mypy
or some other checker) - Should we specify types for internal functions like
._step()
? I have only a little experience with type hints and am unsure whether they are intended more for public functions or are intended for more thorough use. - Is there an easy way to inspect undocumented code so as to determine desired type hint during this effort? E.g. can we run all unit tests and collect a log of the types passed to every function and every method? (this is more a question of your workflow during the proposed series of PRs)
Thank you
|
I have added mypy as part of CI. I am trying to experiment with automatically infering type hints from tests. It works with basic code with tools like pyannotate and monkeyannotate. With pyro, I unable to think how to integrate them. |
@kamathhrishi this is great, thanks for adding a
Is this a Python version thing? I think it's fine to use a higher Python version like 3.7 or 3.8 for the
Should be
I'm pretty sure a newer numpy supports type hints; if not there should be a stub library...
I believe this is
We may be able to fix the
I believe this is
In Pyro we often use automatic import mechanisms which appear to confuse MyPy. I'm unsure the best way to resolve this in the long term, but in the short term I think it's best to ignore these errors. (Maybe in the long term we could add a script to automatically update
Funsor is an optional dependency. I think it's safe to ignore these for now.
We use |
@fritzo I accidentally ran it for the whole module. Right now I have added the typechecks only for the optim module. I have had some errors in a few places which I ignored by using #type:ignore keyword. I will let you know when I find a fix for automatic imports. |
Also you would like me to skip private functions with a _ from mypy or to completely not use type annotations. I think it would help any new developer to read the codebase easier if added to private functions. |
I agree with your argument that it would help developers to include private functions in type checking. |
So I will be adding the type hints for them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, this is a great first PR!
@kamathhrishi is it possible to enable type checking incrementally for new files? E.g. in #2856 I have added type hints. If I merge that PR after this one, how would I update setup.cfg to enable checking for the pyro/ops/streaming.py
and tests/ops/test_streaming.py
?
@fritzo Thank you, looking forward to adding it to the rest of the modules.
and similarly for einsum.py, contract.py. This is one solution, a better way to do is to somehow ignore errors completely for ops except for streaming.py. I tried something like
Din't work as expected. Further, I don't think you should perform type checking on tests. Just modules. |
Thanks @kamathhrishi, I've updated #2856 as you suggested. The only hitch was that I needed to move all the |
This PR adds type hints to optim module.
It addresses issue #2550
This is the first PR that addresses type hints. I will be addressing other modules one PR at a time gradually covering the codebase.
Right now its a WIP since I have to reverify some of the types and ensure all functions are covered.