Hello everyone, I’m trying to have an oriented approach to Flows and Tasks. The idea is to inherit specific flow types that already have some methods as tasks. Only overriding them if necessary. I realize that the decorator

task

doesn’t seem to work for class properties. Here is the error:

File "/Users/nuno/Developer/Data-Framework/data-prefect/data_prefect/utils/flows.py", line 67, in factory_flow
    flow.fetch()
  File "/Users/nuno/Developer/Data-Framework/data-prefect/.venv/lib/python3.8/site-packages/prefect/core/task.py", line 470, in __call__
    new.bind(
  File "/Users/nuno/Developer/Data-Framework/data-prefect/.venv/lib/python3.8/site-packages/prefect/core/task.py", line 511, in bind
    callargs = dict(signature.bind(*args, **kwargs).arguments)  # type: Dict
  File "/usr/local/Cellar/python@3.8/3.8.5/Frameworks/Python.framework/Versions/3.8/lib/python3.8/inspect.py", line 3025, in bind
    return self._bind(args, kwargs)
  File "/usr/local/Cellar/python@3.8/3.8.5/Frameworks/Python.framework/Versions/3.8/lib/python3.8/inspect.py", line 2940, in _bind
    raise TypeError(msg) from None
TypeError: missing a required argument: 'self'

It seems that I cannot pass the method “self” argument. Do you guys have any suggestion? Thank you in advance.

Hey @Nuno, I believe you are looking for a more object-oriented approach using the imperative API to subclass the base

Task

class (or any task class for that matter) and not

task

. In that case, we'd need to from

prefect import Task

instead of

task

. I think this is a good example of subclassing capital T-ask and creating custom tasks in that way.

Thanks Kyle. Yes, actually I had already seen that tutorial, and I came the conclusion that it would be best to follow that approach instead of trying to re-invent the wheel. It almost the same thing that I wanted to do, the difference is that I’m creating classes on the task level instead of the flow Level, and having the tasks available as properties methods. I think it would be nice though, to see if this last approach would be good to use. The advantage, in my opinion, is less boilerplate code.

Ah I see, you want to subclass Flow in some respect with a set of built-in tasks and add tasks/dependencies as needed? I haven't seen an example of that yet! Others have certainly passed a set of custom tasks between their flows, but I imagine using a Flow with property tasks could make setting up dependencies slightly more difficult.

👍