Class builder for functions not conforming to parameters-process structure
Summary
Class builder for functions not conforming to parameters-process structure
Current behaviour/setbacks
-
wela
exists as a place for routines that can be shared by multiple software ecosystems, e.g.aliby
andomniplate
. However, by this design, code that goes there that function as processes do not necessarily conform to the parameters-processes structure. - What I've been doing was to reflect the changes on
wela
in the relevant process inpostprocessor
(in my case, mostlycrosscorr
). This manual intervention is tedious, not up-to-date, prone to errors, and breaks best practise. - This hasn't been an issue before because the main developers of processes have been adding them in the parameters-processes paradigm from day one. There hasn't been a need to have a tool to convert anything to the parameters-processes structure.
Desired behaviour/advantages
The class builder should take a function as an input. It then should strip out the function's arguments. The class builder should create two outputs, (a) a ParametersABC
object derived from the function's arguments, and (b) a PostProcessABC
object derived from the operations in the function.
Essentially the class builder will give us the best of both worlds:
- Eliminate having to manually update processes to match
wela
functions. - Keep the advantages of parameters-process paradigm: easy to construct analysis pipelines (just by editing a YAML file, among other methods), list of modifications to a dataset along with parameters recorded in HDF5 attributes (for reproducibility).
And we should confirm that things work with tests -- i.e. changes to wela
does not break functionality.
Implementation sketch
- Use the 'template method' design pattern.
- There should be core Python functions that extract arguments from a function.
- May use a subclass for multiple inheritance.
- Put
pytest
-based tests in thetest
directory.