Skip to content

RFC generalised Pipeline.get_feature_names #6424

@jnothman

Description

@jnothman

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 make get_feature_names able to transform some list of input features in the general case. I propose the following behaviour:

  1. Pipeline.get_feature_names may be called with a list input_features as an argument only if all its estimators support get_feature_names with an argument. The initial input_features is transformed iteratively through the estimators.
  2. Pipeline.get_feature_names may be called without an argument only if a suffix of its estimators support get_feature_names. The first of that suffix may or may not accept input_features, and the remainder must accept input_features; the output of the first get_feature_names call is iteratively modified by downstream transformers' get_feature_names.
    • To be cautious until we find a use-case otherwise, get_feature_names will not be supported in the case that get_feature_names is available before (but not adjacent to) that suffix.
  3. Otherwise, a ValueError is raised. Or: should the attribute become invisible, as for predict et al.?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions