feature: add get_feature_names() and tests to FunctionTransformer #6436
Conversation
|
Yes, is quite trivial. Probably this and #6431, also trivial cases, should have been done together. (Not that I've looked at the code yet) |
| F = FunctionTransformer() | ||
| feature_names = F.get_feature_names(["a", "b", "c"]) | ||
| testing.assert_array_equal(['a', 'b', 'c'], feature_names) | ||
|
|
There was a problem hiding this comment.
Need to test handling where input_features is not given explicitly. Indeed, we may need to decide whether to return None or to construct a default set of feature names is the better option.
|
I mean, it's also possible we should be renaming |
|
@jnothman I agree with the naming scheme of using |
5f82339 to
90c6f20
Compare
|
@yenchenlin1994 I've squashed my commits, feel free to cherry pick and add it to one of your existing PRs / create a new one. |
| ---------- | ||
| input_features : list of string, length len(input_features), optional | ||
| String names for input features if available. By default, | ||
| "x0", "x1", ... "xn_features" is used. |
There was a problem hiding this comment.
Hello @nelson-liu ,
I think doc here need to be modified since it returns None by default?
There was a problem hiding this comment.
oops, you're correct. I was halfway through implementing x0,x1,etc.. when I realized its probably easier to just stay consistent with what you did / what you and @jnothman discussed on the issue page.
90c6f20 to
a53f8e4
Compare
|
Closing in favor of combined pr with other transformers at #6431 |
Adds
get_feature_names()toFunctionTransformeras outlined in #6425. I'm not sure if I did this properly -- is the point of this function to maintain compatibility whenget_feature_names()is implemented inPipeline? Seems quite trivial otherwise / maybe I'm missing something.