Implements opinionated decorator lifecycle #28

This adds to the set of decorators that can be applied to a node, and puts them in a uniform setting. The ordering is provided in function_base.resolve_nodes -- the algorithm is as follows: 1. If there is a list of function resolvers, apply them one after the other. Otherwise, apply the default function resolver which will always return just the function. This determines whether to proceed -- if any function resolver is none, short circuit and return an empty list of nodes. 2. If there is a list of node creators, that list must be of length 1 -- this is determined in the node creator class. Apply that to get the initial node. 3. If there is a list of node expanders, apply them. Otherwise apply the default nodeexpander This must be a list of length one. This gives out a list of nodes. 4. If there is a node transformer, apply that. Note that the node transformer gets applied individually to just the sink nodes in the subdag. It subclasses "DagTransformer" to do so. 5. Return the final list of nodes.

@Transform

This allows us to run nodes like the following: @Transform('a=a+b+c') def a(): ... And now a will be the result of adding a to b to c. Note a, b, c, currently have to be a node or a config item. Some caveats: 1. Its unsafe! We use eval now 2. Its just called transform. Re (2) we should make it so the transform utilizes the same pattern as config: 1. The transform takes in a lambda that takes in a dict 2. transform.to(...) takes in an expression and creates (1) by passing to a superclass

For when the function signature doesn't accurately reflect the dependency type -- E.G. in created nodes (such as a transform) in which we want to use kwargs.

There's some subtlety with the name. Previously, config.when would change the function name accordingly. This was so that later on decorators could refer to the function by its true name. However, this broke depending on decorator ordering. This change adds a sanitize_name functionality to unblock the transform decorator, but does not yet take away the name changing functionality. We'll need to think through that, but this is a happy medium for now I think.

This solves #53 This allows us to decouple the notion of dynamic_transform from model. Model was specific to Stitch Fix's use-case. With this change, we can build more complex dynamic transforms that aren't limited to pd.Series or simple combinations of nodes. This is also more readable/makes more inherent sense. Note that full backwards compatibility has been maintained by subclassing and keeping parameter names.

This is not going to make it into the final release. Instead see draft PR #60

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implements opinionated decorator lifecycle #28

Implements opinionated decorator lifecycle #28

Commits on Feb 6, 2022