I'm currently stuck, because _InstancesOf doesn't support numpy data types, see #23599

I think we leave off validation dtype for now. In NumPy, the dtype can be specified in many ways. For example, this currently works:

from sklearn.preprocessing import OrdinalEncoder
enc = OrdinalEncoder(dtype="i4")
X = [['dog'], ['cat'], ['snake']]
enc.fit_transform(X)
# array([[1],
#        [0],
#        [2]], dtype=int32)

We can let NumPy handle bad dtypes. For example, this will raise already:

from sklearn.preprocessing import OrdinalEncoder
enc = OrdinalEncoder(dtype="i423e12")
X = [['dog'], ['cat'], ['snake']]
enc.fit_transform(X)
# TypeError: data type 'i423e12' not understood

For reference, what NumPy considers a valid "dtype" is quite complex according to NumPy's typing system

Since the parameter validation requires at least one constraint for each parameter. What is the best way to approach the dtype parameter? Is there some "meta" class/type that always returns True?

What is the best way to approach the dtype parameter?

I think we can use object. For future contributors, include a comment near the validate_params for dtype that states that we are allowing NumPy to do the validation.

I think we can use object.

Unfortunately this collides with sklearn.utils.estimator_checks.check_param_validation. This function includes a test, whether an artificial "bad" parameter raises an appropriate error message. The artificial bad parameter yields True for isinstance.

>>> param_with_bad_type = type("BadType", (), {})()
>>> isinstance(param_with_bad_type, object)
True

Maybe this check should be disabled for object as parameter_constraint.

The current design of _validate_params is not flexible enough to turn off validation. Let's see what @jeremiedbb thinks about adding such functionality. For context, I think it's better to delegate validation of dtype to NumPy because the dtype parameter can accept many inputs.

The current design of _validate_params is not flexible enough to turn off validation. Let's see what @jeremiedbb thinks about adding such functionality. For context, I think it's better to delegate validation of dtype to NumPy because the dtype parameter can accept many inputs.

@thomasjpfan I guess we can add a special case "no validation" or "any" or "delegate validation". This is a case were going for using typing would have make it easier 😄. I'll make a PR to implement that.

I'll make a PR to implement that.

Okay, then I'll resume working on this, when the PR is done :)

@Diadochokinetic I directly pushed some changes to take into account the recent improvements in the validation mechanism.

Thanks @Diadochokinetic