Remove the ability to pass worker kwargs to Submitter/Task.__call__()

[tclose]

This is a question I have been playing with in my head and think probably warrants discussion before we lock in the syntax. It is super convenient to be able to pass worker kwargs when executing tasks, e.g.

outputs = my_task(worker="cf", n_procs=2)

However, there is a risk of the worker kwargs (especially if they are in a plugin) clashing with the names of future kwargs we may want to add to the Submitter.__init__/Task.__call__ methods. Therefore, it would be cleaner/safer to just pass the worker object as

from pydra.workers.cf import ConcurrentFutures

outputs = my_task(worker=ConcurrentFutures(n_procs=2))

although more verbose and painful.

Thoughts?

[aranyics]

I might not be the most suitable to have strong opinions about the issue, I'm still beginner in the new library. Are there other kwargs in the Task.call() other than worker setting? If there are, then I think we should not be afraid of injecting the worker object into the call. If the documentation describes the available worker classes and their usage properly, it should not be a hurdle for a user.

Not only the possible kwargs clashes can cause confusion later, but also I guess different workers take different set of arguments, which would also confuse me how to properly set up the Task call. Passing a set up worker object looks cleaner to me. I personally would prefer the later version.

[satra]

passing the worker object seems reasonable.

[tclose]

I might not be the most suitable to have strong opinions about the issue, I'm still beginner in the new library. Are there other kwargs in the Task.call() other than worker setting? If there are, then I think we should not be afraid of injecting the worker object into the call. If the documentation describes the available worker classes and their usage properly, it should not be a hurdle for a user.

Not only the possible kwargs clashes can cause confusion later, but also I guess different workers take different set of arguments, which would also confuse me how to properly set up the Task call. Passing a set up worker object looks cleaner to me. I personally would prefer the later version.

Thanks for the input, more than welcome :)

[tclose]

Maybe the string version, i.e. worker="cf" could still be used if you are happy with the default args