-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds group feature for injecting kwargs #107
Conversation
eb26af0
to
d3db8e5
Compare
a4eb9fd
to
4b4f996
Compare
807ef28
to
96f4457
Compare
Part of me wants the grouped dependency to be a dictionary (or list of tuples) and not a straight list. Why? So that someone could do this and get the correct behavior: @inject(group(source("foo"), source("bar"), source("baz")))
def my_df(series_list: List[pd.Series]) -> pd.DataFrame:
"""One would likely expect the series to be named and thus the output to be "foo", "bar", "baz"... but it's not guaranteed."""
return pd.concat(series_list)
@inject(group(source("foo"), source("bar"), source("baz")))
def my_df(series_list: List[Tuple[str, pd.Series]]) -> pd.DataFrame:
"""This would be guaranteed to work"""
return pd.DataFrame(dict(series_list))
@inject(group(source("foo"), source("bar"), source("baz")))
def my_df(series_dict: Dict[str, pd.Series]) -> pd.DataFrame:
"""This would be guaranteed to work"""
return pd.DataFrame(series_dict) Or maybe we can do all the above and know what to do based on the parameter type annotation? |
Otherwise @elijahbenizzy should someone be able to do this: @inject(group(source("foo"), source("foo"), source("foo")))
def my_df(series_list: List[pd.Series]) -> pd.DataFrame:
"""Should we have three? or just one?"""
return sum(series_list)
constant = pd.Series([1,2,3,4])
@inject(group(source("foo"), source("boo"), source("baz"), value(constant)))
def my_df(series_list: List[pd.Series]) -> pd.DataFrame:
"""Are values allowed?"""
return sum(series_list) |
Ughh, yeah, currently this is broken but not for great reasons. Need to fix + add tests. Was thinking of releasing then fixing -- as this is a weird case. IMO the strangest case that will currently break is:
This is busted due to the popping of kwargs when we parse
This is fine by me -- it'll just work I think? |
I would argue against allowing duplicates, since you can achieve that another way more clearly.
I don't think we want that to work TBH. What's the "name" of the constant? |
Yeah, so I think we should allow it to be a dict depending on the annotation -- it should be pretty easy. That said, we could just as well do a |
4b4f996
to
2038d1f
Compare
6b79312
to
6f3828f
Compare
64f6eed
to
5e21e4b
Compare
This is a little hacky but the API is solid. Basically this is a parameterized of 1 parameterization. It goes very well with config-driven pipelines, allowing you to group a set of functions to do stuff with.
6f3828f
to
843bcad
Compare
There is a bit of duplicated code here, but its well-tested and solves a common problem. At some point we'll clean it up when we rewrite decorators, but for now this is OK. This allows mapping between the following: - group(*args) -> List[...] - group(**kwargs) -> Dict[str, ...] Anything else is not supported yet.
843bcad
to
7235d26
Compare
Merging this to consolidate PRs -- these two were using similar pieces so I wanted to merge them together. See https://github.com/DAGWorks-Inc/hamilton/tree/configure-everything for continuation. |
We were doing this in the replacement function. Looks like everythin ghas to go in the replacement function, which makes things slightly trickier, but at least we can centralize the logic in that function.
[Short description explaining the high-level reason for the pull request]
Changes
How I tested this
Notes
Checklist