-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
parameters_to_validate
to allow for partial validation in validation framework
#25058
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
instead of |
We already have that :) I think it would be the most appropriate because it really means delegate validation to whatever uses this param. For instance, we use it for the |
Ah yes. Moving forward, I will start recommending |
I'm reopening because it's actually not fully satisfying. If we put |
@glemaitre also found that having long lists of "no_validation" was non very satisfying either and can be error prone because if a contributor put "no_validation" for a parameter that is actually not in the class, then it will never be validated and no test would catch that. Thus we thought that we could allow to only pass a fraction of the parameters to the function constraint dict and the common test would take the constraint dict of the class and the function, merge them (giving priority to the function for duplicated entries), and then proceed with the checks. (It does solve the issue I raised in the previous message though) |
Side note: my favorite solution would be to deprecate all these functions that are just wrappers around estimators 😄 |
In some PRs for adding validation to functions: #24924 or #25026, there will be double validation, by the function and another by the estimator. @adrinjalali and I share the same concern about keeping constraints in sync between the function and the estimator: #24924 (comment), #25026 (comment).
The test for validation is very strict about including a constraint for every parameter. I see the purpose of having this strictness is such that when a new parameter is added, then a constraint is also included.
I propose adding a
parameters_to_validate
tovalidate_params
which is a collection of strings that states which parameters should be validated. This way when a new parameter is added, the default is to add a constraint for the new parameter, but it can be ignored by adding it to theparameters_to_validate
list.CC @jeremiedbb @glemaitre @adrinjalali
The text was updated successfully, but these errors were encountered: