Use pydantic for argument value checking.

changed milestone to %Someday

I just played around a bit...To check for example for valid pandas frequency strings, this would do the trick:

from typing_extensions import Annotated

from pydantic import validate_call
from pydantic.functional_validators import AfterValidator

def checkFrequency(freq: str) -> str:
    try:
        pd.tseries.frequencies.to_offset(freq)
    except ValueError:
        raise ValueError(f"This is an invalid frequency: '{freq}'")
    return freq


FreqString = Annotated[str, AfterValidator(checkFrequency)]

@validate_call
def foo(freq: FreqString):
    pass


foo("Min30")  # fails
foo("30Min")  # doesn't fail

This even allows to make argument type conversions. If, for example, in the above example checkFrequency is defined as:

def checkFrequency(freq: str) -> pd.offsets.BaseOffset:
    try:
        return pd.tseries.frequencies.to_offset(freq)
    except ValueError:
        raise ValueError(f"This is an invalid frequency: '{freq}'")

the foo will receive its argument as a pd.offsets.BaseOffset.

I think, we could spare as quite a bit of code and argument handling with this...

Think its worth the effort.

mentioned in merge request !805

So i checked this out and transferred argument validation of flagUniLof, flagLOF and flagRange of the outliers. (!805)

def flagLOF(
        self,
        field: str | Sequence[str],
        n: Annotated[int, Field(ge=1)] = 20,
        thresh: Literal["auto"] | Annotated[float, Field(ge=0)] = 1.5,
        algorithm: Literal["ball_tree", "kd_tree", "brute", "auto"] = "ball_tree",
        p: Annotated[int, Field(ge=1)] = 1,
        flag: float = BAD,
        **kwargs,
    )

signature definition is blown up a little - but only minimal with regard to the fact, that most basic value range checks like greater as, smaller as, member of and so on can just be assigned there now.
also as pointed out by @schaefed - custom/more elaborate type checks and transformations can be also just assigned within the type hinting
also validations of unions of types works out of the box and error messages in case of failed validations list all the valid input types/constraints
so thats quite plug and play and we can get rid of a lot of code and coding (thus incentivising actually implementing type validations for new functions)
the Annotation and Field calls get removed/resolved via autodoc_pydantic and dont appear in the sphinx doc (wich allows also for enabling value range constraints in the docstring, if wanted)
error messages are thrown out of the validate_call wrapper of the function and show function name, parameter name, violated constraint and all valid types and constraints for that parameter. Parameter name is only shown by name when function was called with the parameter as keyword style assignment (a=1), otherwise only the position of the parameter in the function call is given
although forward references are supported, "SaQC" type validation somehow fails - i didnt get into that, but guess thats solve able somehow.
unfortunately the only thing i am not sure of being fixable easily, is, that Unions of types, where one option has an additional constraint to it, get transferred from "pipe" notation into Union[] notation in the sphinx doc page. - since its a sphinx thing i am not totally confident that can be fixed easily.

So, what do you think? Would the switch be a net positive as of now?

I would definetly say net positive

because it would than be really possible to on-the-fly define parameter constraints, which is kind of a prerequisite to have that coherently done
because constraints are easier accessible, comprehensible and easier to change also - wich is also a prerequisite to have that consistently maintained
code gets much streamlined
constraines can be automatically transferred to sphinx doc

Use pydantic for argument value checking.

Designs

Child items ...

Activity