-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
RFC generalised Pipeline.get_feature_names #6424
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
agreed on 1) and 2). |
Do you mean an |
Ah, I didn't think about that. But these are two different errors, right? one is there is no post-fix with |
Now that we released |
There has been some demand for
Pipeline.get_feature_names
(#2007, #5172, #6421) for the case where the last element in the pipeline is a feature extractor. Following on from #6372, we instead shall makeget_feature_names
able to transform some list of input features in the general case. I propose the following behaviour:Pipeline.get_feature_names
may be called with a listinput_features
as an argument only if all its estimators supportget_feature_names
with an argument. The initialinput_features
is transformed iteratively through the estimators.Pipeline.get_feature_names
may be called without an argument only if a suffix of its estimators supportget_feature_names
. The first of that suffix may or may not acceptinput_features
, and the remainder must acceptinput_features
; the output of the firstget_feature_names
call is iteratively modified by downstream transformers'get_feature_names
.get_feature_names
will not be supported in the case thatget_feature_names
is available before (but not adjacent to) that suffix.ValueError
is raised. Or: should the attribute become invisible, as forpredict
et al.?The text was updated successfully, but these errors were encountered: