-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Refactoring it into
CompositeMetricis what I think is the best approach (while renaming it), e.g.:class CompositeMetric(BaseMetric): """Base class for composite metrics. This class provides common functionality for composite metrics. Args: name: The name of the metric. preserve_dims: The dimensions to preserve in the computation. Defaults to "lead_time". forecast_variable: The forecast variable to use in the computation. target_variable: The target variable to use in the computation. metric_list: The metrics to include in the composite metric evaluation. *args: Additional arguments to pass to the metric. **kwargs: Additional keyword arguments to pass to the metric. """ def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.metric_list: list["BaseMetric"] = metric_list ...This change also reminds me that I want to do a sweep of the docstrings to adhere to PEP257 and shift them into the
__init__method:The docstring for a class should summarize its behavior and list the public methods and instance variables. If the class is intended to be subclassed, and has an additional interface for subclasses, this interface should be listed separately (in the docstring). The class constructor should be documented in the docstring for its
__init__method. Individual methods should be documented by their own docstring....And to ensure consistency in verbiage:
If a class subclasses another class and its behavior is mostly inherited from that class, its docstring should mention this and summarize the differences. Use the verb “override” to indicate that a subclass method replaces a superclass method and does not call the superclass method; use the verb “extend” to indicate that a subclass method calls the superclass method (in addition to its own behavior).