Skip to content

registry⚓︎

Canonical name-to-class lookup for the shipped analysis flavours.

A convenience for introspection (available_analyses()) and for anyone building a scheme's own COMPATIBLE_ANALYSES dict (see :class:~pipt.update_schemes.core.analysis_binding.AnalysisBindingMixin) without importing approx_update/full_update/subspace_update individually.

Registering a flavour here (:func:register_analysis) does not by itself make it selectable on any existing scheme: each algorithm class (ESMDA, EnKF, ...) declares its own COMPATIBLE_ANALYSES, read directly off the class rather than computed from this registry, so that reading one scheme's source tells you everything it supports. Wiring a newly registered flavour into a scheme means adding it to that scheme's COMPATIBLE_ANALYSES -- or, for a wholly out-of-tree scheme, registering the combination directly via :func:pipt.update_schemes.registry.register_scheme.

Kept in its own module rather than in :mod:pipt.update_schemes.analysis.base: the concrete flavours import the base, so a registry living there would import its own importers. tests/test_import_hygiene.py guards the layering.

available_analyses() ⚓︎

Return the registered flavour names, sorted.

get_analysis(analysis) ⚓︎

Look up the analysis class for a flavour.

Raises:

Type Description
KeyError

If the flavour is not registered. The message lists the valid ones.

register_analysis(analysis, cls, *, overwrite=False) ⚓︎

Add an analysis under a flavour name, for later lookup by that name.

This alone does not make cls selectable on any existing scheme -- see the module docstring for how to actually wire a new flavour in.

Parameters:

Name Type Description Default
analysis str

Flavour name to register it under.

required
cls type

Analysis class implementing it.

required
overwrite bool

Allow replacing an existing entry. Defaults to False, so two packages claiming one name is an error rather than a load-order lottery -- matching registry.register_scheme.

False