-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Custom argparser extension with Trainer arguments (argument types added) #1147
Custom argparser extension with Trainer arguments (argument types added) #1147
Conversation
Hello @alexeykarnachev! Thanks for updating this PR. There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻 Comment last updated at 2020-03-24 18:54:51 UTC |
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 🚀
pytorch_lightning/trainer/trainer.py
Outdated
def add_argparse_args(cls, parent_parser: ArgumentParser) -> ArgumentParser: | ||
"""Extend existing argparse by default `Trainer` attributes.""" | ||
parser = ArgumentParser(parents=[parent_parser], add_help=False) | ||
def _get_argparse_args_and_types(cls) -> Generator[Tuple[str, Any, Any], None, 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.
def _get_argparse_args_and_types(cls) -> Generator[Tuple[str, Any, Any], None, None]: | |
def _get_init_arguments_and_types(cls) -> Generator[Tuple[str, Any, Any], None, None]: |
sounds a bit better as it can be used elsewhere not only for argparser
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.
Maybe in this case it’s worth to make this method public?
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.
And also move the allowed_types
to the method's input arguments?
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.
yes, both are good suggestions, lest doing it...
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 decided to make this method more general. Let's a client decides what arguments he needs. For instance, add_argparse_args
is a "client" of this method, and it restricts the allowed types by itself.
What are your thoughts on this?
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.
that would be nice, just thinking if is better to defien wanted args/types or ignored ones
…ainer-argparser-types
Codecov Report
@@ Coverage Diff @@
## master #1147 +/- ##
======================================
Coverage 91% 91%
======================================
Files 61 61
Lines 3151 3151
======================================
Hits 2868 2868
Misses 283 283 |
@alexeykarnachev could you pls update from master? we have fixed the failure in #1163 |
Co-Authored-By: Jirka Borovec <Borda@users.noreply.github.com>
…in tuples (not in sets)
…ainer-argparser-types
This PR works great for me with the exception of boolean casting. I.e. if I run with This can be resolved with distutils: bool('false')
# True
bool(distutils.util.strtobool('false'))
# False Would it be possible to add a line to check for |
good point, @joeddav could you do it in review mode as a suggestion (so it is clear and @alexeykarnachev can simply accept it) or follow-up PR? |
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.
Add more robust boolean type casting
Co-Authored-By: Joe Davison <joe@huggingface.co>
Co-Authored-By: Joe Davison <joe@huggingface.co>
This pull request is now in conflict... :( |
Before submitting
What does this PR do?
Fixes #1139
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃