Users might want to use more than 1 loggers at once
A good way to do this might be to create a ListLogger class or similar that takes a list of loggers and iterates over them on each call. Can then make this happen auto-magically in the Trainer when a list of loggers is given. Any issues with this approach @PyTorchLightning/core-contributors ? Otherwise I'm happy to implement it :)
The LoggerCollection sounds good, a user would pass list loggers he wants to use and then under the hood, it will be transformed to this wrapper...
Moreover, we may do the same, simplified API, with callbacks... as e.g. Keras did, pass just list of callbacks to be executed and Trainer will call then when needed instead of having them specified
https://github.com/PyTorchLightning/pytorch-lightning/blob/b1040523b2180300574d961444b00abfa3c84195/pytorch_lightning/trainer/trainer.py#L65-L66
Yeah, that sounds good, I'll do this for Loggers first and then we can think about following up for callbacks
why not just take in the list of loggers
# default logger
Trainer(logger=True)
# no logger
Trainer(logger=False)
# single logger
Trainer(logger=Logger)
# n loggers
Trainer(logger=[a, b, c])
And anytime we call the logger right now internally, we replace with a call to all of them.
The value of a LoggerList object or similar here is that the Trainer code doesn't need to care how the Loggers were given except in the init where it wraps them. The API the user sees will be the same, but it seems more encapsulated this way. That said, either option is fine in that they will both give the same result. Any strong opinions for either option? Otherwise I tend towards a LoggerList
as I mentioned, we would keep the API as Will gave example but under the hood, we would use a class iteration loggers co you do not repeat looping over all logger or checking if there is just one or more...
Yeah, i think under the hood a loggerlist or some class to encapsulate makes sense as @ethanwharris mentioned! To the user though they should just intuit that they can pass in a list of loggers.
@srush thoughts?
Yup, the user API of torch-lightning seems to be that passing/returning lists just works, so I like that style.
Closed by #903
Most helpful comment
why not just take in the list of loggers
And anytime we call the logger right now internally, we replace with a call to all of them.