The recorded_property and recorded_property_cached decorators both use dicts to store their time-series data. To support this, Ledger must receive initial_year as an __init__ arg. This requires initial_year to be passed to a lot of objects!
The current dict-based approach provides two benefits: client code doesn't need to translate between years and 0-based indices and Ledger-based records can be started in different years while still allowing comparison between records of the same year. The former is just syntactic convenience. The latter doesn't currently have any application in the software, but if it's desired it could probably be replicated via an optional parameter.
Using an optional initial_year would require a lot of comparison logic; consider an optional offset (with a default value of 0) which could be added to (or subtracted from) an index to allow harmonization between Ledger objects. In that case, we'd likely want to add history-accessing methods (probably not properties, since we'd likely need to subclass list) that can take an index and apply the offset appropriately. Since this is not currently required, we can leave it for a future revision.
Ledger objects maintain an ordered (and contiguous) set of records. This maps better to list than dict. Accordingly, we should shift recorded_property and recorded_property_cached to use list for value history.
We'll need to consider how to handle user-input values (e.g. via the input parameter or via settings or constants). Those can likely continue to be dicts since those values can be non-contiguous. Whether they should be indexed by year (e.g. 2015) or indices (0-based) should be considered.
This feature is an efficiency-focused optimization. It's not appropriate for v. 0.1 Pushed back to v. 0.2, since it belongs with Monte Carlo simulation methods.
The
recorded_property
andrecorded_property_cached
decorators both use dicts to store their time-series data. To support this,Ledger
must receiveinitial_year
as an__init__
arg. This requiresinitial_year
to be passed to a lot of objects!The current dict-based approach provides two benefits: client code doesn't need to translate between years and 0-based indices and Ledger-based records can be started in different years while still allowing comparison between records of the same year. The former is just syntactic convenience. The latter doesn't currently have any application in the software, but if it's desired it could probably be replicated via an optional parameter.
Using an optional
initial_year
would require a lot of comparison logic; consider an optionaloffset
(with a default value of 0) which could be added to (or subtracted from) an index to allow harmonization between Ledger objects. In that case, we'd likely want to add history-accessing methods (probably not properties, since we'd likely need to subclasslist
) that can take an index and apply the offset appropriately. Since this is not currently required, we can leave it for a future revision.Ledger
objects maintain an ordered (and contiguous) set of records. This maps better tolist
thandict
. Accordingly, we should shiftrecorded_property
andrecorded_property_cached
to uselist
for value history.We'll need to consider how to handle user-input values (e.g. via the
input
parameter or viasettings
orconstants
). Those can likely continue to bedict
s since those values can be non-contiguous. Whether they should be indexed by year (e.g. 2015) or indices (0-based) should be considered.