Skip to content
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

Support multiple levels of subclassing in from_argparse_args #3315

Closed
nathanpainchaud opened this issue Sep 2, 2020 · 3 comments
Closed
Labels
feature Is an improvement or enhancement help wanted Open to be worked on won't fix This will not be worked on

Comments

@nathanpainchaud
Copy link
Contributor

nathanpainchaud commented Sep 2, 2020

🚀 Feature

Improve from_argparse_args methods in LightningDataModule and Trainer so that they can support more than one level of subclassing from their base Lightning class.

Motivation

Users might want to develop a custom hierarchy of subclasses to either LigthingDataModule or Trainer to deal with common/boilerplate code (e.g. systematically add common arguments to data modules like batch_size or num_workers). However, the generic from_argparse_args methods fail them in this case, and users must implement by hand a custom initialization logic.

Pitch

It would be easy to implement a recursive inspection of the parent's init signature to include its args as well until we hit the base Lightning class.

Edit: To help discuss the issue, I opened a draft PR #3316 which already implements the desired behavior.

@nathanpainchaud nathanpainchaud added feature Is an improvement or enhancement help wanted Open to be worked on labels Sep 2, 2020
@github-actions
Copy link
Contributor

github-actions bot commented Sep 2, 2020

Hi! thanks for your contribution!, great first issue!

@Borda
Copy link
Member

Borda commented Sep 2, 2020

Let's continue the discussion on the created PR...

@stale
Copy link

stale bot commented Oct 21, 2020

This issue has been automatically marked as stale because it hasn't had any recent activity. This issue will be closed in 7 days if no further activity occurs. Thank you for your contributions, Pytorch Lightning Team!

@stale stale bot added the won't fix This will not be worked on label Oct 21, 2020
@stale stale bot closed this as completed Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Is an improvement or enhancement help wanted Open to be worked on won't fix This will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants