A policy environment consists of functions and their parameters. It is usually created by set_up_policy_environment. However, set_up_policy_environment returns the parameters and functions separately in a tuple. Likewise, compute_taxes_and_transfers expects parameters and functions to be provided separately. This usually leads to code that is similar to this:
Parameters and functions are first taken apart, before being put together again.
Describe the solution you would like to see
It would be cleaner to bundle functions and their parameters into an object, so they always get passed around together. Thus, I propose to add a PolicyEnvironment class.
The class can also provide methods for common use-cases like overwriting some specific function, while ensuring that functions and parameters don't get out of sync.
Interface breaking implications
set_up_policy_environment would return a PolicyEnvironment.
compute_taxes_and_transfers would take a PolicyEnvironment instead of the parameters and functions.
However, the proposed change can prevent breaking changes in the future, since we can hide the implementation of the function and parameter lists inside the class.
Is your feature request related to a problem?
A policy environment consists of functions and their parameters. It is usually created by
set_up_policy_environment
. However,set_up_policy_environment
returns the parameters and functions separately in a tuple. Likewise,compute_taxes_and_transfers
expects parameters and functions to be provided separately. This usually leads to code that is similar to this:Parameters and functions are first taken apart, before being put together again.
Describe the solution you would like to see
It would be cleaner to bundle functions and their parameters into an object, so they always get passed around together. Thus, I propose to add a
PolicyEnvironment
class.The class can also provide methods for common use-cases like overwriting some specific function, while ensuring that functions and parameters don't get out of sync.
Interface breaking implications
set_up_policy_environment
would return aPolicyEnvironment
.compute_taxes_and_transfers
would take aPolicyEnvironment
instead of the parameters and functions.However, the proposed change can prevent breaking changes in the future, since we can hide the implementation of the function and parameter lists inside the class.
Describe alternatives you've considered
/
Additional context