MNT Param validation: convenience constraint for booleans #23618
Conversation
|
@jeremiedbb , This looks nice. Is it possible to leave the [bool] constraint as it is? In a way, np.bool_ is to bool what Integer is to int. Same thing, different abstractions. if I use [np.bool_] , then np.bool_ and bool conditions are considered. If I use [bool], then only bool is considered. If I use an [int], then bool, np.bool_ and int are considered. Then it's easy to decouple the use of np.bool_ from bool. For strict backwards compatibility, [np.bool_] would be advised, |
|
@Nwanna-Joseph You can always be specific with the specific type. In scikit-learn, we have been too flexible and we need to remain backwards compatible and create a |
Oh, I see. Thanks a lot. |
Already merged and currently under reviews PRs for #23462 define the constraints for boolean params as
[bool]. The issue is that it's not backward compatible since we usually also acceptnp.bool_and even anint.(Issue raised in this comment #23593 (comment))
Accpeting an int doesn't seem necessary and I propose to deprecate it. Accepting a np.bool_ is probably convenient for many users. To avoid having to repeat all accepted options all the time I propose to make a helper for that and just specify
["boolean"]instead.Question: Should the docstrings mention
bool or np.bool_orbooleaninstead of justbool?