-
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
Deprecate TrainerDataLoadingMixin
and move logic to DataConnector
#11282
Deprecate TrainerDataLoadingMixin
and move logic to DataConnector
#11282
Conversation
…lightning into TrainerDataLoadingMixin
Co-authored-by: Rohit Gupta <[email protected]> Co-authored-by: Aki Nitta <[email protected]>
…torch-lightning into TrainerDataLoadingMixin
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…torch-lightning into TrainerDataLoadingMixin
for more information, see https://pre-commit.ci
@@ -2364,6 +2369,151 @@ def terminate_on_nan(self, val: bool) -> None: | |||
) | |||
self._terminate_on_nan = val # : 212 | |||
|
|||
def reset_train_dataloader(self, model: Optional["pl.LightningModule"] = 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.
how about moving the reload logic to data_connector and trainer.reset_train_dataloader
just calls trainer._data_connector._reset_train_dataloader
? not sure if it's a good idea, but just trying to avoid all the logic being kept inside the single Trainer module.
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 don't feel strongly either way. I probably have a slight preference for keeping it as it is now, since I feel like having a function that just calls the private function adds a bit of unnecessary abstraction/complexity. If others feel strongly we can change 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'd say it's fine as it is. I'd only do that if it aids in testing, but we don't have unit tests for each of these separate methods.
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.
It is fine because the trainer owns the dataloaders, so resetting is her responsibility. But this won't be the case in the future, pretty sure. Which is why I also suggested in my previous comment to map the public property to the protected one in the connector.
In any case, let's just please not mix properties and methods like 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.
n any case, let's just please not mix properties and methods like this.
@daniellepintz I believe my comment was missed here. Could you send a follow up PR? I believe reviewers did not catch this properly
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.
@awaelchli sorry I am confused by that line. Could you clarify which property you are talking about?
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 mean the disorganization that this has caused. Previously, methods and properties were organized, but now new methods have been added and now it's mixed up:
method
method
property
property
new method
new method
It should be
method
method
new method
new method
property
property
given that Trainer wants to have all properties at the bottom.
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.
Ah I see good point. Will send a follow up PR
Co-authored-by: Rohit Gupta <[email protected]> Co-authored-by: Carlos Mocholí <[email protected]>
…torch-lightning into TrainerDataLoadingMixin
@@ -2364,6 +2369,151 @@ def terminate_on_nan(self, val: bool) -> None: | |||
) | |||
self._terminate_on_nan = val # : 212 | |||
|
|||
def reset_train_dataloader(self, model: Optional["pl.LightningModule"] = 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.
I'd say it's fine as it is. I'd only do that if it aids in testing, but we don't have unit tests for each of these separate methods.
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.
nit:
Co-authored-by: Rohit Gupta <[email protected]>
Ready to be merged! |
What does this PR do?
Fixes #11248
Does your PR introduce any breaking changes? If yes, please list them.
Before submitting
PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:
Did you have fun?
Make sure you had fun coding 🙃