Elijah ben Izzy
Elijah ben Izzy
> I'm concerned about: > > 1. commit history preservation - wouldn't want to lose some of the "why" for some of the decorators. > 2. Any reason function_modifiers_base needs...
Some qs this brings up: 1. Should we have the `MultiOutput` as the decorating node? Its currently duplicated for readability, but it feels unecessary. 2. How should we handle namespaces?...
Note this is a workaround for https://github.com/stitchfix/hamilton/issues/17
I think this can be fixed in `Node` -- need to mess with it. Will take on.
So I think that `check_output` will be really helpful here. But I see a few sets of problems that we can solve: 1. Making it easy to debug/isolate problems that...
One thing to consider (not sure if you've seen this) is `raw_execute`, which doesn't do a join. Under the hood, `execute` just calls `raw_execute` and does a join for you....
OK, big challenge is managing global state. Currently `resolve_nodes` is a single function that takes in a function and gives out nodes. It does *not* have access to the states...
> I think there is a benefit to being explicit. Why not do: > > > > ```python > > > > @config.when_not_in(region=['us', 'ca']) > > def some_fn__default() -> ...:...
Concensus is not to implement (for now) -- lots of complexity with little benefit (in clarity). Would love thoughts if you have them!
We should check all `frozenset` and `Set[]` implementations, as well as `dict`, `list`, etc... Also there's a python version issue as these only were allowed recently