Inspired by @seeM dive into design options, I started exploring what if we could compose callbacks. The idea is to keep TrainCB as a callback but make it possible to provide additional pluggable options such as mixed precision training or integration with accelerate. This notebook motivates the composition alternative by noting that implementing training as a callback seems to force us to go in the direction of inheritance if we want to extend it. It provides an initial proof of concept that works for simple cases, but it feels hackish and fragile. Nevertheless, it could be useful for discussion or to explore other ideas.
I couldn't quite get it right, but instead of Learner being the spine on top of which callbacks are hooked, callbacks would process "state" and pass it on to the next callback.
I've used simple functional-style composable patterns in other languages but I'm not yet familiar with Python design patterns, so this could be totally wrong. In Swift, for instance, everything starts from designing your type system and then filling in the code that plugs them together.
Anyway, happy to learn that this is all useless and there are much better solutions :)
Inspired by @seeM dive into design options, I started exploring what if we could compose callbacks. The idea is to keep
TrainCB
as a callback but make it possible to provide additional pluggable options such as mixed precision training or integration withaccelerate
. This notebook motivates the composition alternative by noting that implementing training as a callback seems to force us to go in the direction of inheritance if we want to extend it. It provides an initial proof of concept that works for simple cases, but it feels hackish and fragile. Nevertheless, it could be useful for discussion or to explore other ideas.I couldn't quite get it right, but instead of
Learner
being the spine on top of which callbacks are hooked, callbacks would process "state" and pass it on to the next callback.I've used simple functional-style composable patterns in other languages but I'm not yet familiar with Python design patterns, so this could be totally wrong. In Swift, for instance, everything starts from designing your type system and then filling in the code that plugs them together.
Anyway, happy to learn that this is all useless and there are much better solutions :)