-
-
Notifications
You must be signed in to change notification settings - Fork 25k
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
RFC Move _more_tags
to "developer API" via __sklearn_tags__
#28910
Comments
+1 on
and removing |
I am +1. I updated #22606 that implements |
I don't see the reason why we need to have it public. Making the switch to
|
I agree, before merging #22606 I think it'd be nice to clean up our tags. I'll work on it and open PRs. |
As a part of making it easier and more "standard" to write scikit-learn estimators by third party developers, we have been slowly developing a "developer API" kind of thing, which are useful for third party developers, but not end users of the estimators.
Some of the work has been:
__sklearn_clone__
__metadata_request__fit
, ...get_metadata_routing
What I'm proposing here, is to create a new
__sklearn__tags__
method instead of the existing_more_tags
.We've had a lot of discussions when we designed the current system, which goes through the MRO and the
_more_tags
adds to the tag set instead of returning the tags. Now the question is do we want to keep the current system or do we want__sklearn_tags__
to return the estimator's tags instead, and call parent's__sklearn_tags__
inside itself? As in, instead of:to have:
Inside our tags, we also have some starting with
_
such as_xfail
, and the question is do we want to make those public.cc @scikit-learn/core-devs
The text was updated successfully, but these errors were encountered: