You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As application code becomes more complex, it can be useful to organize all of the possible options into a single source of truth, rather than declaring them all in-line. I am imagining something like this could be useful.
Ideally there would also be a way to add a docstring to each option as well, which could potentially allow for the full option set of an application/library to be automatically documented with sphinx (perhaps requiring a plugin)
The text was updated successfully, but these errors were encountered:
Something to consider when designing the namespace:
Currently, with a structure of classes to store Options, we can do something like this:
class PKG:
class MODULE_1:
A = Option('PKG.MODULE_1.A')
B = Option('PKG.MODULE_1.B')
class MODULE_2:
A = Option('PKG.MODULE_2.A')
B = Option('PKG.MODULE_2.B') >> func
where we can apply a basic cleaning/ingestion function on the Option definition itself rather than applying it every place where PKG.MODULE_2.B is called. Not sure if preserving this functionality would be possible in a namespace?
As application code becomes more complex, it can be useful to organize all of the possible options into a single source of truth, rather than declaring them all in-line. I am imagining something like this could be useful.
Ideally there would also be a way to add a docstring to each option as well, which could potentially allow for the full option set of an application/library to be automatically documented with sphinx (perhaps requiring a plugin)
The text was updated successfully, but these errors were encountered: