Adds parameterized_inputs

[skrawcz]

This change adds paramterized_inputs decorator, which
is almost a carbon copy of paramterized_input but that it allows
any number of parameters to be mapped.

Why is it a separate class? Well for backwards compatibility
we don't want to break parameterized_input. Should we try to
consolidate them? I think so -- so we should then mark parameterized_input
as deprecated and will be removed in a 2.0 release? ✅

I should then probably update all documentation to reflect parameterized_inputs
and thus the documentation on paramterized_input to either be hidden or
non-existant? Hmm. ✅

Changes

• Add parameterized_inputs decorator.
• Deprecates parameterized_input decorator.
• Adjust documentation to promote parameterized_inputs instead.

Testing

1. unit tests pass.

Notes

Motivation is a side project and having to write out repetitive functions is laborious -- this is admittedly a power
user mode, but one I think that makes sense to have.
e.g. this looks nice and readable

from hamilton.function_modifiers import parametrized_inputs
import pandas as pd

NUMERIC_FEATURES = ['age', 'height', 'weight', 'body_mass_index', 'transportation_expense',
                    'distance_from_residence_to_work', 'service_time', 'work_load_average_per_day',
                    'hit_target']


@parametrized_inputs(**{f'{k}_mean': dict(feature=k) for k in NUMERIC_FEATURES})
def mean_computer(feature: pd.Series) -> pd.Series:
    """Average of {feature}"""
    return feature.mean()


@parametrized_inputs(**{f'{k}_std_dev': dict(feature=k) for k in NUMERIC_FEATURES})
def std_dev_computer(feature: pd.Series) -> pd.Series:
    """Standard deviation of {feature}"""
    return feature.std()


@parametrized_inputs(**{f'{k}_zero_mean': dict(feature=k, feature_mean=f'{k}_mean') for k in NUMERIC_FEATURES})
def zero_mean_computer(feature: pd.Series, feature_mean: pd.Series) -> pd.Series:
    """Creates zero mean value of {feature} by subtracting {feature_mean}"""
    return feature - feature_mean


@parametrized_inputs(**{f'{k}_zero_mean_unit_var': dict(feature_mean=f'{k}_mean', feature_std_dev=f'{k}_std_dev') 
                        for k in NUMERIC_FEATURES})
def zero_mean_unit_var_computer(feature_mean: pd.Series, feature_std_dev: pd.Series) -> pd.Series:
    """Computes zero mean unit variance of {feature_mean} with {feature_std_dev} to create {output_name}"""
    return feature_mean / feature_std_dev

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.
• Reviewers requested with the Reviewers tool ➡️

Testing checklist

Python - local testing

• python 3.6
• python 3.7

[skrawcz]

So next steps I'm thinking:

• Change docs to default to parameterized_inputs (plural).
• Put a deprecation warning on parameterized_input -- and log when it's used.

[elijahbenizzy]

Not completely sure how I feel about this API. Definitely cleaner but it seems that its not particularly consistent with other APIs. Its dryer/slightly easier to read (which is good), but it takes quite a bit of work to figure out what's happening/parse the API. The design philosophy behind decorators is specifically to make it easy to figure out what's going on. I worry that with objects/named tuples its going to be harder to figure out the shape of the DAG.

Honestly, I wonder if that's just an inherent issue with @parametrized_inputs?

[elijahbenizzy]

Some thoughts

[elijahbenizzy]

LGTM -- not convinced we want parameterization. I get it if we need later kwargs, but I think using **parameterization is going to look cleaner/be more readable.

[elijahbenizzy]

LGTM!