You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the introduction of datamodules we have duplicated code. For example, the train/val/test_dataloader methods in LightningModule and DataModule have the same name, same docs, same signature but live in two files.
Also the argparse methods are copy pasted from Trainer, it will become impossible to maintain this in the future.
We want datamodules to be usable even if you're not using lightning for training.
This won't be changed by my suggestion. It's just refactoring, nothing else.
We are moving away from Mixins.
Which mixins? I am aware that in Lightning some classes are named mixins but conceptually they are actually not and should not be called that. Mixins have their place and one should not confuse multiple inheritance with mixins. Could you clarify what you mean?
🚀 Feature
Motivation
Since the introduction of datamodules we have duplicated code. For example, the train/val/test_dataloader methods in LightningModule and DataModule have the same name, same docs, same signature but live in two files.
Also the argparse methods are copy pasted from Trainer, it will become impossible to maintain this in the future.
Pitch
Factor out the hook definitions:
and then in the other classes, inherit from it:
Note also:
Alternatives
I see no alternatives. This is the best way I know.
@PyTorchLightning/core-contributors makes sense?
The text was updated successfully, but these errors were encountered: