-
Notifications
You must be signed in to change notification settings - Fork 5
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
Proposing change in design : uses class
instead of dictionaries
#184
Comments
I also suggested to have a tab-completable way to specify links without dicts and string keys, so I'd support the idea, even if I'm not sure of the exact suggestion with the word "future", for instance. Also, I didn't check the implementation in detail, but I'm really confused by the class containing classes, and then you access a class attribute of the inner class... Why can't you simply use a method of the outer class and store info in an instance attribute, with less python magic? (maybe easier to discuss live, I just wanted to write this comment) |
Also, I'd try to make the two examples at the top try to do the same thing, now they are a bit different I think |
That is because I started coding from inside out 😄 hahah |
Hi @khsrali , thanks for sharing your idea here. I try to explain what WorkGraph implementations, and their use cases. About using ClassWorkGraph uses
Therefore, the code you propose to run should already work using WorkGraph. wg = WorkGraph()
add_task = wg.add_task(add, name="add1", x=1, y=2)
wg.add_task(multiply, y=3, x=add_task.outputs.result)
wg.run() In most cases,
Users are not required to give a name for a task. However, they are still suggested to give the task a meaningful name so that later, when loading a finished WorkGraph, they can quickly access the tasks by their names. About the creation and executionIn your proof of concept, you also introduce the way to execute the WorkGraph, like the In I am open to further discussion if you'd like to delve deeper into the execution engine. |
After trying out the first syllabus of documentation (two issues #176 #179), I would like to propose a more intuitive interface:
The proposal:
As it is now:
Proof of concept: Can be achieved with the following design
I understand this might be considered a pain for @superstar54 but to me this is intuitive and lubricates life of a user.
I would like to know other's opinion as well, @giovannipizzi
The text was updated successfully, but these errors were encountered: