Introduce coupling between input channels #36
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will be helpful for making macros into walled gardens that have their own IO instead of simply using references to their children's IO; it will allow us to keep the child node input up-to-date.
|
|
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Eliminate redundant information
So that Workflow and Composite can do things differently
I wrongly eliminated logic passing over connected channels
I also wrongly eliminated logic passing channels mapped to None
To reflect the fact that IO is actually reconstructed now on replacement; we can still check for the correct link between macro and child by looking at the value receiver though
So it's also available for output
Since we might be rebuilding because of an internal change, allow for the channels to now differ
We want to avoid ever having a `concurrent.futures.Executor` as an attribute, because it holds a truly unpickleable thread lock object. Instead, we now pass in information _about_ an executor and instantiate one on the fly if we need it. In the medium term we'll want a more sophisticated interface, i.e. information about how to connect to some existing executor object, or more detailed information on what type of executor to instantiate. But for the sake of getting workflows to work on executors, this trivially bool is enough.
So that macro and workflow can lean on the same code, and macro can just extend things a little bit to reflect the fact that it needs to rebuild its IO on unpacking children (workflow _always_ rebuilds its IO, so it's a non-issue)
I had a typo in what I wanted to test for, but it turns out that the test is ill-conceived anyhow, because the futures object is returning new instances each time I ask for the `.result()`, so the `.result()` that the macro got internally will differ from the one in the test
These are a little simpler tests, as the workflow can't have siblings it's connected to
I don't know how to update self attributes right now
…ecutors_for_composite
So that the workflows and macros play well with executors
Executors for composite
These can for sure be dropped when support for <=3.10 is dropped, maybe before.
Works for 3.11 at least
No io by reference for macros
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This will be helpful for making macros into walled gardens that have their own IO instead of simply using references to their children's IO; it will allow us to keep the child node input up-to-date.