DAG.__getitem__ covers the functionality of removing nodes since it extracts sub-graphs.
Maybe there's a need, still of having a remove_node (func or var) interface to the same functionality?
But what about other useful DAG operations. Adding/merging DAGs, compressing sub-DAGs into one node (maybe only useful for display?), etc.
Perhaps the add_edge one is a good reusable one.
For example, when making a pipeline (function composition), were' really just saying "add edges between every element of this list of functions, binding the previous function's output to the the first argument of the next function.
def add_edge_from(dag, func, from_node, to_param=None, ...):
"""Adds an edge sources the to_param argument from the from_node (var_node or func_node)"""The ... suggest that we'll probably want some other defaulted control arguments (such as a connection_policy one).
The function would return a (new) dag where a new func node was added which binds the data of from_node to the to_param input of func.
to_param is optional, and some connection_policy could determine how to figure it out.
For example, when making pipelines (function composition) that policy would say "just take the first argument" -- but we
could envision some utility for binding to a parameter based on the annotations of that parameter and the return_annotation of the function producing the from_node data.
Note: The language we'll use here is "by reference", but the implementation is, at this point, "by value" (e.g. dag[slice] RETURNs a transformed dag but doesn't transform the dag itself).
DAG.__getitem__covers the functionality of removing nodes since it extracts sub-graphs.Maybe there's a need, still of having a
remove_node(func or var) interface to the same functionality?But what about other useful DAG operations. Adding/merging DAGs, compressing sub-DAGs into one node (maybe only useful for display?), etc.
Perhaps the
add_edgeone is a good reusable one.For example, when making a pipeline (function composition), were' really just saying "add edges between every element of this list of functions, binding the previous function's output to the the first argument of the next function.
The
...suggest that we'll probably want some other defaulted control arguments (such as aconnection_policyone).The function would return a (new)
dagwhere a new func node was added which binds the data offrom_nodeto theto_paraminput offunc.to_paramis optional, and someconnection_policycould determine how to figure it out.For example, when making pipelines (function composition) that policy would say "just take the first argument" -- but we
could envision some utility for binding to a parameter based on the annotations of that parameter and the return_annotation of the function producing the
from_nodedata.Note: The language we'll use here is "by reference", but the implementation is, at this point, "by value" (e.g.
dag[slice]RETURNs a transformed dag but doesn't transform the dag itself).