The canonical @task decorated Python function task is pretty simple to reason about. At execution time (either
locally or on a Flyte cluster), the function runs.
This class, along with the ShimTaskExecutor class below, represents another execution pattern. This pattern,
has two components:
The TaskTemplate, or something like it like a FlyteTask.
An executor, which can use information from the task template (including the custom field)
Basically at execution time (both locally and on a Flyte cluster), the task template is given to the executor,
which is responsible for computing and returning the results.
> [!NOTE]
> The interface at execution time will have to derived from the Flyte IDL interface, which means it may be lossy.
This is because when a task is serialized from Python into the TaskTemplate some information is lost because
Flyte IDL can’t keep track of every single Python type (or Java type if writing in the Java flytekit).
This class also implements the dispatch_execute and execute functions to make it look like a PythonTask
that the entrypoint.py can execute, even though this class doesn’t inherit from PythonTask.
This function is largely similar to the base PythonTask, with the exception that we have to infer the Python
interface before executing. Also, we refer to self.task_template rather than just self similar to task
classes that derive from the base PythonTask.
This function must be overridden and is where all the business logic for running a task should live. Keep in
mind that you’re only working with the TaskTemplate. You won’t have access to any information in the task
that wasn’t serialized into the template.
Parameter
Type
Description
tt
_task_model.TaskTemplate
This is the template, the serialized form of the task.
kwargs
**kwargs
These are the Python native input values to the task. :return: Python native output values from the task.