Arbitrary input for meters

[philngo]

Meters currently require a single input: a ConsumptionHistory object. However, this doesn't allow variation in other necessary inputs, such as weather or project data (e.g. ZIP code, retrofit completion dates). It would be nice to create a framework which would allow for easy specification of different types of input data without becoming so general that ordinary use cases become obfuscated. Thoughts and ideas about how to do this?

[philngo]

Input types should be fixed at class creation time. I think it would be good to support at least two different ways of supplying input data to meters: 1) at evaluation of the "run" function and 2) at instantiation of the meter object.

Supporting the first is absolutely essential, as almost all data will be associated with particular homes or projects (such as consumption data and retrofit pre/post dates), and must be supplied when the meter is run.

Supporting the second might be preferable for optimization of execution time or to reduce API call load (e.g. gathering weather data from an API only once per station rather than once per household) while retaining control in the meter specification over how and from where data is collected.

[philngo]

One way to implement input flexibility might be to generate the run function declaratively; providing in each metric a specification of its particular named input requirements, which must then be supplied as keyword arguments to the run functions. The Meter base class (more accurately its meta class) would then be responsible for gathering metric inputs and dispatching then appropriately when the run function is called.

A named attribute of the class, perhaps something like initialization_inputs = ["zipcode"] (separate from any particular metric) might provide a way to create a parallel method for supplying input data at instantiation time - by modifying the __init__ function instead of the run function.

[philngo]

Meters now scan the metric evaluate method in order to find inputs; run must be supplied with keyword args in order to dispatch correctly.

For init inputs, it's easiest and cleanest just override the __init__ method. Shouldn't cause problems to do so. (Overriding the __new__ method will cause problems).