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

TODO list for "replace Hparams by init args" PR #1937

Closed
7 of 12 tasks
awaelchli opened this issue May 24, 2020 · 9 comments
Closed
7 of 12 tasks

TODO list for "replace Hparams by init args" PR #1937

awaelchli opened this issue May 24, 2020 · 9 comments
Assignees
Labels
bug Something isn't working ci Continuous Integration docs Documentation related feature Is an improvement or enhancement help wanted Open to be worked on priority: 0 High priority task
Milestone

Comments

@awaelchli
Copy link
Contributor

awaelchli commented May 24, 2020

🚀 TODO: Follow up work on module arguments rework in #1896

  • 1. (docs) Make clear the multiple ways args can and cannot be passed in.
    Example:

     class LitModel(LightningModule):
        def __init__(self, arg1, arg2):
         ...
     Trainer.add_argparse_args(parser)
     LitModel.add_model_specific_args(parser)
     LitModel(parser.parse_args())  # this will fail

    This won't work since the list of arguments in constructor is a fixed size.
    We can fix it in two ways:

    1. Add **kwargs to the init signature to catch any unnecessary args (not good design but works)
    2. Split the parsers to separate model args from Trainer args
  • 2. (docs) make it clear which types we save to the checkpoints and which not (nn.Module for example). The name "module_arguments" maybe misleading to believe all args are saved.

  • 3. Some old code was left commented, including tests, as mentioned by @yukw777

  • 4. (tests) The model checkpointing has changed, we should thoroughly test that the correct args are loaded.

  • 5. (tests) Test case for positional args

  • 6. (bugfix) Fix for when super() is not called or called after other local vars were added, e.g.,

     class LitModel(LightningModule):
        def __init__(self, arg1, arg2):
            my_local_var = 2
            super().__init__()
            # module_arguments now contains "my_local_var"
     
     LitModel.load_from_checkpoint(...)  # this fails
     # TypeError: __init__ got an unexpected argument "my_local_var"

    We obviously don't want any local vars other than the arguments in the checkpoint.

  • 7. (bugfix) In Python we are not forced to call the instance "self", this is currently hardcoded and leads to:

     class LitModel(LightningModule):
        def __init__(obj, arg1, arg2):
            obj.arg1 = arg1
            super().__init__()
            # module_arguments will contain LitModel() itself

    same applies to the conventional naming of "*args" and "**kwargs"

  • 8. (tests) make sure the LRfinder still works as expected by passing in the suggested learning rate as argument (fixed in Bugfix: Lr finder and hparams compatibility #2821 )

  • 9. (enhancement) @festeh wants to add support for dataclasses

  • 10. (bugfix) some of the examples are broken because of the problem mentioned in 1.

  • 11. (test) multiple inheritance

  • 12. Should error or warn when self.auto_collect_arguments() is called somewhere other than in init. A specific use case that is currently not working is Crash trying to construct module_arguments when module is created in a method #1976

Feel free to add additional bullet points I missed :)

@awaelchli awaelchli added feature Is an improvement or enhancement help wanted Open to be worked on bug Something isn't working docs Documentation related labels May 24, 2020
@justusschock
Copy link
Member

We should also make sure, that the current hparams will always be supported. There are definitely usecases where hparams are not suitable.

@Borda Borda added this to the 0.7.7 milestone May 25, 2020
@Borda
Copy link
Member

Borda commented May 25, 2020

We should also make sure, that the current hparams will always be supported. There are definitely usecases where hparams are not suitable.

they are as Namespace and dict are in allowed primitives

@justusschock
Copy link
Member

justusschock commented May 25, 2020

@Borda yes, but to make sure, I'd prefer to have an explicit test for this :)

Since we should really take care of backwards compatibility.

@Borda
Copy link
Member

Borda commented May 25, 2020

@Borda yes, but to make sure, I'd prefer to have an explicit test for this :)
Since we should really take care of backwards compatibility.

Sure, agree, mind draw the test in PR and I will finish it / ensure the compatibility =)

@HansBambel
Copy link
Contributor

 class LitModel(LightningModule):
    def __init__(self, arg1, arg2):
     ...
 Trainer.add_argparse_args(parser)
 LitModel(parser.pase_args())  # this will fail

@awaelchli Just for clarification: this will not fail because you have a typo in parser.pase_args(), but because the call is not supported, right?

@awaelchli
Copy link
Contributor Author

yes exactly, it will fail because the argparser has many more args than just arg1, arg2.
I will fix the typo.

@Borda
Copy link
Member

Borda commented Jun 16, 2020

@awaelchli let's update the list with respect to what has been done...
@edenlightning mind help?

@Borda Borda modified the milestones: 0.8.0, 0.8.x Jun 18, 2020
@edenlightning edenlightning modified the milestones: 0.8.x, 0.9.0, 1.0.0 Jun 18, 2020
@edenlightning edenlightning added this to the 0.8.x milestone Jun 18, 2020
@edenlightning
Copy link
Contributor

@awaelchli whats left here?

@awaelchli
Copy link
Contributor Author

awaelchli commented Aug 3, 2020

I think most of the points are outdated, much has changed. I think we can close it and track any remaining issues via reported bugs. Although I think testing of the "save_hyperparameters" feature could be more thorough in general (bullet points 5., 8., 11)

@Borda Borda modified the milestones: 0.8.x, 0.9.0 Aug 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ci Continuous Integration docs Documentation related feature Is an improvement or enhancement help wanted Open to be worked on priority: 0 High priority task
Projects
None yet
Development

No branches or pull requests

6 participants