-
Notifications
You must be signed in to change notification settings - Fork 54
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
Change task types to class hierarchy #9
Comments
I agree with this change. For me, the main point is better The only potential problem that I see is now is persistent sessions; reconstructing a graph in different Python client will be more complicated than now. |
Good point about reconstruction from in-server data. We can map known types to their classes and then fallback with |
We need a representation for the task types. We have the following task kinds:
One TODO is to bikeshed task class names |
Done on v0.3: All builtin and user tasks derive from the Task class. |
In the Python API, all the tasks are currently an instance of the
Task
class with different types indicated bytask_type
. It would be more pythonic to implement them as a hierarchy of classes, one for eachtask_type
(or even one for everyProgram
or pythonRemote
func. - TBD). This would have the advantages to allow usingisinstance
and better introspection (__repr__
), access to parameters specific to the task type and allow subclassing.Independently of this change, we can keep the task-creation operations as functions (and lower-cased), e.g. keep
tasks.concat
in additon to havingtasks.ConcatTask
.This should be mostly non-disruptive change and needs a more detailed spec of Task interface.
The text was updated successfully, but these errors were encountered: