Reference Issues/PRs

Follow-on from #24224, and relevant for #23462 and #22722.

What does this implement/fix? Explain your changes.

_validate_params is currently being rolled out to all estimators as part of #23462, however when a parameter doesn't match the constraints, a blanked ValueError is thrown, even when a TypeError would be more relevant. This PR adds a new is_correct_type to each constraint, and raises a TypeError when the value being checked doesn't match any type of the constraints. If the type of at least one constraint is matched, a ValueError is still thrown.

For example, for the following constraint,

"max_samples": [
            None,
            Interval(Real, 0.0, 1.0, closed="right"),
            Interval(Integral, 1, None, closed="left"),
        ],

if a value -1 is given, a ValueError is thrown, but if a value "1" is given, a TypeError is thrown.

is_correct_type is added as an abstract method to _Constraint, and the default behaviour of is_satisfied_by is to only check is_correct_type (since many constraints only check type). For constraints that also have a value check, this is handled by is_satisfied_by, which also checks is_correct_type (this ensures that the entire constraint is satisfied, and not just the value).

Any other comments?

This should give more granular feedback to a user for incorrect parameter specification.

generate_invalid_params: The invalid check for _MissingValues raises a TypeError at present (generated_invalid_params is intended for ValueErrors only), and the constraint allows for all possible values for each type, so I can't think of a way to generate a ValueError (unless I write new methods for generating params of invalid type). I have also commented out the invalid param check for HasMethods for now, for similar reasons.

Tests have been updated accordingly.