I rather see the code changing fast than not at all 
Thanks for adding CUDA support. I’ll try it out as soon as a model I’m working on finishes training.
Happy you like the Metrics class! I saw that you’ve implemented it, so I guess no need for a PR? It also looks like you’re handling the interaction with the History callback?
Everything moves so fast in ML that I bet all I do now will be outdated a year from now, so that kinda validates your point about backwards compatibilty, haha.
I don’t think object composition is wrong per se (I’m actually a big fan haha). But I see your point about it being cumbersome to pass a model to trainer. The issue I have though, is that I can’t use SuperModule as I’m using pretrained models from PyTorch vision 5 repo that do not extend SuperModule. Thus, why passing a model to ModuleTrainer is my only option? I’ve also thought of merging SuperModule and a Module methods during runtime, but this seems like a hacky idea and probably not worth it.
Adding an extra class sounds like a good compromise. However, if we go that way, I’d love to have all training code in a single class e.g. TrainerModule implements all fit, evaluate, etc methods and SuperModule simply forwards those calls to a TrainerModule (maybe stored as class attribute of SuperModule). Less room for errors. Is this what you had in mind?
I’d also like to add some tests to the metrics classes. Do you have any thoughts on how you’d structure them?