Restrict input data to have at most one connection #673
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #498. This doesn't make the graph truly deterministic yet, but it does resolve the explicit non-determinacy mentioned there.
The goes part of the way to resolving #502, but there we need what is currently the sole input "connection" and the current concept of a "value_receiver" (well, "value_source" from the perspective of the input channel) to be put on more equal footing -- i.e. each data node can have at most one upstream "source". So this is related PR, but I leave that issue open.
Even though making multiple connections is now strictly illegal, when we go via the route of assignment to input panels there is syntactic sugar to do the necessary disconnection for you. IMO this should feel very pythonic, as when we assign something new to the attribute of course the old assignment is thrown away. E.g.
Where we see
n2is correctly leveraging its one and only more-recent source, and we can see that the old source got disconnected because the workflow can tell it's a dangling output.This means the "manually constructed while-loop" demo had to be thrown out of the integration tests, because the whole concept of relying on the "input connection stack" no longer exists. This should be fine, as while-loop behaviour has its own class now (#650)