Closed sbailey closed 7 years ago
The currently supported method to change a config param in memory is:
c.first_day._value = <DATE>
However, this operation should not normally be necessary (except, e.g. for specialized testing code) so is reserved for experts. Therefore I consider it a feature, not a bug, that the following does not work:
c.first_day = <DATE>
I could hide the _value
attribute by adding a method, e.g.
c.first_day.set_value(<DATE>)
but wanted to check back with you to see your current thinking first.
OK for c.first_day.set_value(<DATE>)
if you prefer that over c.first_day = <DATE>
.
Even if it is primarily to support simulations/verification/testing, we should have a way to override a config file value that doesn't carry the implied "this might break later" message of telling users to use a private _value
variable.
The new set_value()
method is implemented now in #66, with accompanying docstring and unit test updates. I also updated earlier instances of _value = X
to use set_value(X)
.
Document how to change Configuration object parameters after they have already been read from the yaml config file. e.g. for changing the start date:
Please update the interface to make that more obvious and not require _private variables. Changing the start/stop dates is a specific case, but in general we should support the ability to algorithmically change any config variable without having to go via a custom yaml file.