-
Notifications
You must be signed in to change notification settings - Fork 11
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
Node input as args #769
Node input as args #769
Conversation
Pull Request Test Coverage Report for Build 5537284624
💛 - Coveralls |
I let this idea percolate overnight, and I think the issue is that in comparison to Joerg's demo in pyiron/pyiron_workflow#14, our Of course, no such division of |
Thanks, @liamhuber for your thoughts. I am not sure that I understand the issue of parameters coming from the function we want to wrap and those related to the node. The strings needed for the output label are arguments in the decorator, whereas all function arguments are contained in the function definition. Thus, when converting the function via a decorator the two sets of parameters should be straightforward to distinguish. Or is there something I am missing? It may be helpful to give a code example. |
Hi @JNmpi, the problem was that the strings for the output labels were provided to the decorator and/or the underlying node class at instantiation. Since there's no robust way to distinguish whether an The other comment was just that we want to be able to pass, eg, |
…put_as_args # Conflicts: # pyiron_contrib/workflow/function.py # tests/unit/workflow/test_function.py
Instead of (incorrectly!) reproducing it
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
@samwaseda, @JNmpi, there is of course more that can and will be added, but #770 and this PR together make something I'm pretty happy with. We now have a lot more freedom in terms of (not) labelling output channels, and updating input at init and on call with both args and kwargs. Example: from pyiron_contrib.workflow import Workflow
wf = Workflow("simple")
@Workflow.wrap_as.single_value_node()
def add_one(x):
y = x + 1
return y # Output labels parsed automatically
@Workflow.wrap_as.function_node(output_labels="sum") # Output labels optionally overridden
def adder(x: int | float = 1, y: int | float = 1) -> int | float:
return x + y
# Function node input data as args, kwargs, or both!
wf.a = add_one(0) # arg
wf.b = add_one(x=0) # kwarg
wf.sum = adder(wf.a, y=wf.b) # both
# Remember, with single value nodes we can pass the whole node instead of an output channel!
# Workflow automatically generate {node.label}_{channel.label} IO
print(wf.outputs.sum_sum.value)
>>> 2
# Can call a workflow, but since input has no order _only_ kwargs work
wf(a_x=2, b_x=3)
# The nodes are set to all update automatically,
# so this will propagate through the workflow without any wf.run() invokation
print(wf.outputs.sum_sum.value)
>>> 7 Docs, tests, and example notebook are all updated accordingly. |
Sorry I cannot review until Wednesday evening!! |
No worries! I've got extra childcare stuff today anyways; if I do manage to get any more done I'll just keep stacking it on top. |
Namely, on_run should be a property returning a callable
They are not implemented and working yet, so at least fail cleanly!
And downstream stuff like `update` and thus `__call__`. This was requested by Joerg and now makes things really start to feel like regular python
We may wish to later make Macro's slow, but for Workflows, since the IO is just routing through to the owned nodes, input updates are _anyhow_ most of the time re-running things, so it's a sensible default IMO
Return output when calling `run`
Clean executor fails
So far, this modifies
Function.__call__
such that it updates the input channels using**kwargs
and/or*args
. This is the first step towards being able to instantiate nodes (at least those created by a decorator) with their initial input values set as args, as requested by @JNmpi in #756.