Is your feature request related to a problem? Please describe.
There is no parallel backend API in skbase today, while sktime, skpro, and Hyperactive each carry their own backend selection and configuration using the pair backend and backend_params.
Describe the solution you'd like
I propose to add a small skbase.parallel module that defines a common interface for parallel execution. Once skbase provides this shared primitive, downstream projects can remove duplicate code and depend on the central API. This is a rough sketch how those classes could look like:
class LokyParallel:
n_jobs: Optional[int] = None
prefer: Optional[str] = None
require: Optional[str] = None
class RayParallel:
ray_remote_args: Optional[Dict[str, Any]] = None
shutdown_ray: bool = True
logger_name: str = "ray"
mute_warnings: bool = False
class DaskParallel:
scheduler: Optional[str] = None Describe alternatives you've considered
A nested dictionary with a single top level key was considered instead of a dataclass because it encodes the dependency in one parameter. This is harder to explain and invites deep untyped structures, which burden documentation and error messages.
Is your feature request related to a problem? Please describe.
There is no parallel backend API in skbase today, while sktime, skpro, and Hyperactive each carry their own backend selection and configuration using the pair backend and backend_params.
Describe the solution you'd like
I propose to add a small skbase.parallel module that defines a common interface for parallel execution. Once skbase provides this shared primitive, downstream projects can remove duplicate code and depend on the central API. This is a rough sketch how those classes could look like:
Describe alternatives you've considered
A nested dictionary with a single top level key was considered instead of a dataclass because it encodes the dependency in one parameter. This is harder to explain and invites deep untyped structures, which burden documentation and error messages.