Parameter
Parameter
class
prefect.core.parameter.Parameter
(name, default=<no default>, required=None, tags=None)
[source] A Parameter is a special task that defines a required flow input.
A parameter's "slug" is automatically -- and immutably -- set to the parameter name. Flows enforce slug uniqueness across all tasks, so this ensures that the flow has no other parameters by the same name.
Args:
name (str)
: the Parameter name. default (any, optional)
: A default value for the parameter. Must be a JSON-Serializable type. required (bool, optional)
: If True, the Parameter is required and the default value is ignored. Defaults to False
if a default
is provided, otherwise True
. tags ([str], optional)
: A list of tags for this parameter
methods: |
prefect.core.parameter.Parameter.copy (name, **task_args) [source] |
Creates a copy of the Parameter with a new name.
Args: name (str) : the new Parameter name **task_args (dict, optional) : a dictionary of task attribute keyword arguments, these attributes will be set on the new copy Raises: AttributeError : if any passed task_args are not attributes of the original Returns: Parameter : a copy of the current Parameter, with a new name and any attributes updated from task_args
|
prefect.core.parameter.Parameter.run () [source] |
The run() method is called (with arguments, if appropriate) to run a task.
Note: The implemented run method cannot have *args in its signature. In addition, the following keywords are reserved: upstream_tasks , task_args and mapped .
If a task has arguments in its run() method, these can be bound either by using the functional API and calling the task instance, or by using self.bind directly.
In addition to running arbitrary functions, tasks can interact with Prefect in a few ways: - Return an optional result. When this function runs successfully, the task is considered successful and the result (if any) can be made available to downstream tasks.
- Raise an error. Errors are interpreted as failure.
- Raise a signal. Signals can include
FAIL , SUCCESS , RETRY , SKIP , etc. and indicate that the task should be put in the indicated state. FAIL will lead to retries if appropriate SUCCESS will cause the task to be marked successful RETRY will cause the task to be marked for retry, even if max_retries has been exceeded SKIP will skip the task and possibly propogate the skip state through the flow, depending on whether downstream tasks have skip_on_upstream_skip=True .
|
prefect.core.parameter.Parameter.serialize () [source] |
Creates a serialized representation of this parameter
Returns: - dict representing this parameter
|
DateTimeParameter
class
prefect.core.parameter.DateTimeParameter
(name, default=<no default>, required=True, tags=None)
[source] A DateTimeParameter that casts its input as a DateTime
Args:
name (str)
: the Parameter name. default (any, optional)
: A default value for the parameter. Must be a JSON-Serializable type, and must be parseable by pendulum. required (bool, optional)
: If True, the Parameter is required. Otherwise, it is optional and will return None
if no value is provided. tags ([str], optional)
: A list of tags for this parameter
methods: |
prefect.core.parameter.DateTimeParameter.run () [source] |
The run() method is called (with arguments, if appropriate) to run a task.
Note: The implemented run method cannot have *args in its signature. In addition, the following keywords are reserved: upstream_tasks , task_args and mapped .
If a task has arguments in its run() method, these can be bound either by using the functional API and calling the task instance, or by using self.bind directly.
In addition to running arbitrary functions, tasks can interact with Prefect in a few ways: - Return an optional result. When this function runs successfully, the task is considered successful and the result (if any) can be made available to downstream tasks.
- Raise an error. Errors are interpreted as failure.
- Raise a signal. Signals can include
FAIL , SUCCESS , RETRY , SKIP , etc. and indicate that the task should be put in the indicated state. FAIL will lead to retries if appropriate SUCCESS will cause the task to be marked successful RETRY will cause the task to be marked for retry, even if max_retries has been exceeded SKIP will skip the task and possibly propogate the skip state through the flow, depending on whether downstream tasks have skip_on_upstream_skip=True .
|
This documentation was auto-generated from commit bd9182e
on July 31, 2024 at 18:02 UTC