Description
We have our crudifier decorator prepare_for_crude_dispatch,
but one of the pillar design flavors in i2i is to extract and centralize configuration, and when possible,
abstract configuration patterns into reusable conventions.
In the case of crudification, we want to be able to centralize the crudification specifications so we can apply the logic in bulk.
Again, there's a routing theme here: Do we base it on arg names only? Sure, but then when we have some collisions/exceptions,
how do we handle that? We could offer tools to transform the functions to fit the "arg name only" config powers, which keeps the configuration simple, but pushed the complexity elsewhere.
Some ideas already implemented in crudify_based_on_names. See the configuration language choices there (key lookup with argname, or (func, argname) etc.).
Note first that the output store handling for crudify_based_on_names
dosn't seem to work. So there's that to look into.
But it works for inputs:
>>> from functools import partial
>>> def foo(x, y):
... return x + y
>>> def bar(a, x):
... return a * x
>>> general_crudifier = partial(
... crudify_based_on_names,
... arg_input_stores={'x': 'x_store'},
... crudifier=partial(prepare_for_crude_dispatch, mall={'x_store': {'stored_two': 2, 'stored_four': 4}})
... )
>>>
>>> foo, bar = map(general_crudifier, [foo, bar])
>>>
>>> foo('stored_two', 10)
12
>>> bar(4, 'stored_four')
16
We're not over though.
We probably (do we?) want to allow the user to centralize the "rules" for all arguments of prepare_for_crude_dispatch
.
param_to_mall_map: Optional[Union[dict, Iterable]] = None,
mall: Optional[Mall] = None,
include_stores_attribute: bool = False,
output_store: Optional[Union[Mapping, str]] = None,
# the arguments below only apply if output_store is given
save_name_param: str = "save_name",
empty_name_callback: Callable[[], Any] = None,
auto_namer: Callable[..., str] = None,
output_trans: Callable[..., Any] = None,
verbose: bool = True,
In crudify_based_on_names
we only give control over param_to_mall_map
(through arg_input_stores
) and output_store
(through func_output_stores
).
I'd propose this approach:
- We keep the same parameters of
prepare_for_crude_dispatch
(instead of thearg_input_stores
andfunc_output_stores
) - possibly renaming them to fit both cases. - "Automate" the logic between the single case of
prepare_for_crude_dispatch
and it's "bulk" counter-part. Essentially, a generalization of theCrudifier
class.