Now that we are storing the constraints in the function itself, I'll prefer the function become a "class that is callable". i.e. a class that defines __call__.

To me, using setattr on a function feels like a hack.

I think there's an issue with that approach. The decorator works with functions and methods. If the decorator returns an object I think it can't work as expected to replace a method. But maybe I just don't know how to do it. Here's what I came up with:

def validate_params(parameter_constraints):

    def decorator(func):

        @functools.wraps(func, updated=())
        class wrapper:
            def __init__(self):
                self._skl_parameter_constraints = parameter_constraints

            def __call__(self, *args, **kwargs):
                func_sig = signature(func)

                # Map *args/**kwargs to the function signature
                params = func_sig.bind(*args, **kwargs)
                params.apply_defaults()

                # ignore self/cls and positional/keyword markers
                to_ignore = [
                    p.name
                    for p in func_sig.parameters.values()
                    if p.kind in (p.VAR_POSITIONAL, p.VAR_KEYWORD)
                ]
                to_ignore += ["self", "cls"]
                params = {k: v for k, v in params.arguments.items() if k not in to_ignore}

                validate_parameter_constraints(
                    self._skl_parameter_constraints, params, caller_name=func.__qualname__
                )

                return func(*args, **kwargs)

        return wrapper()

    return decorator

maybe someone has an idea ?

Also, not sure it's that less hackish that setting an attribute on a function 😄

My understanding is that replacing a method by an object that is callable doesn't make it a method but makes it an attribute of the class that is callable. Thus, when calling it, self is not passed as first argument.

Discussing IRL with @jeremiedbb, it seems that making it callable makes things more complex. I would be inclined to keep setting the attribute on the function.

It is also possible to use the decorator on methods. I can think that we could validate kernels (of gaussian process) or splitters that are not proper estimators. So it could be handy to still make it possible to validate parameters for such classes.

I'm okay with leaving this as is. I think to actually use a "class callable" with a decorator, it would end up something like available_if and using class descriptor's:

On that note, can you check to make sure that the current implementation does not run into issues like #21344 which was fixed in #23077?

Thanks for the hint, I forgot about available_if !
Let me try to implement this and we'll chose the best solution EDIT: this would only work on methods but no longer on functions. I guess there's no simple way to make it work on both and would require to implement 2 versions of the decorator, making the whole thing a lot more complex. So I'm also keen on leaving the PR as is 😄

I also think the attribute solution is the easiest even if it populates the callables' namespaces.

I also think the attribute solution is the easiest even if it populates the callables' namespaces.