Skip to content
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

Closed
gavento opened this issue Mar 19, 2018 · 4 comments
Closed

Change task types to class hierarchy #9

gavento opened this issue Mar 19, 2018 · 4 comments
Assignees
Labels
enhancement New feature or request python API
Milestone

Comments

@gavento
Copy link
Contributor

gavento commented Mar 19, 2018

In the Python API, all the tasks are currently an instance of the Task class with different types indicated by task_type. It would be more pythonic to implement them as a hierarchy of classes, one for each task_type (or even one for every Program or python Remote func. - TBD). This would have the advantages to allow using isinstance 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 having tasks.ConcatTask.

This should be mostly non-disruptive change and needs a more detailed spec of Task interface.

@gavento gavento added enhancement New feature or request python API labels Mar 19, 2018
@spirali
Copy link
Collaborator

spirali commented Mar 19, 2018

I agree with this change. For me, the main point is better __repr__ than what we have now.

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.

@gavento
Copy link
Contributor Author

gavento commented Mar 20, 2018

Good point about reconstruction from in-server data. We can map known types to their classes and then fallback with CustomTask (or such) - for those it is no worse than just a Task instance now.

@gavento gavento self-assigned this Apr 12, 2018
@gavento
Copy link
Contributor Author

gavento commented Apr 12, 2018

We need a representation for the task types. We have the following task kinds:

  • Built-in task, names prefixed with !, finite and relatively stable set
    • Python @remote tasks
      • Task type !py
      • Class: Either just PyTask, or one PyTask subclass per @remote. Possible drawback:
    • External programs
      • Task type !exec
      • Class: ExecTask
  • User-provided subworkers (possibly including Python)
    • Propose subworker_name/provided_task (where subworker_name is the name subworker was registered with at the worker, preferably the binary name, provided_task is the name the subworker function was registered with, preferably based on the function name)
    • Class: SubworkerTask and subclasses
    • Possibly let the client declare MyownSubworker classes?

One TODO is to bikeshed task class names

@gavento
Copy link
Contributor Author

gavento commented Jul 2, 2018

Done on v0.3: All builtin and user tasks derive from the Task class.

@gavento gavento closed this as completed Jul 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request python API
Projects
None yet
Development

No branches or pull requests

2 participants