Update index handling in PandasAdapter

[it176131]

Describe the workflow you want to enable

As noted in #27037, handling the index of an input container can be hairy. The solution implemented in #27044 works, but it excludes pandas.Series input types. I'd like to modify the logic in the :method:PandasAdapter.create_container so that it checks if the X_original is a pandas.DataFrame or pandas.Series. This would allow transformers that accept 1-dimensional inputs and output 2-dimensional dataframes to persist their indices.

Describe your proposed solution

I'd like to change line 124 from this:

            elif isinstance(X_original, pd.DataFrame):

To this:

            elif isinstance(X_original, (pd.DataFrame, pd.Series)):

Describe alternatives you've considered, if relevant

User sets the index on their own:

some_series = pd.Series(...)
trf = SomeTransformer().set_output(transform="pandas")
out_frame = trf.fit_transform(some_series).set_index(some_series.index)

Additional context

I recognize most transformers in scikit-learn expect 2-dimensional inputs. But some packages that depend on scikit-learn (like mlxtend) have transformers that transform 1-dimensional input into 2-dimensional output. I believe this would greatly benefit them. See the newly updated TransactionEncoder for an example.

I'm willing to submit a PR if this is an acceptable enhancement.

[glemaitre]

This is currently outside our API scope and I don't think that we want to make some code that we are not using internally. I think this is a design purpose that scikit-learn define X to be a 2D container because it remove some ambiguity regarding features/samples.

We might be revisit this if we come to think of transformer that make independent column-wise transform.

So I'm -1 for the inclusion right now.

[it176131]

This is currently outside our API scope and I don't think that we want to make some code that we are not using internally. I think this is a design purpose that scikit-learn define X to be a 2D container because it remove some ambiguity regarding features/samples.

We might be revisit this if we come to think of transformer that make independent column-wise transform.

So I'm -1 for the inclusion right now.

Makes sense. Perhaps this would be useful for the CountVectorizer, TfidfVectorizer, and TfidfTransformer as they expect a 1D container? Of course, they output sparse matrices by default, but maybe an option in the future.

[glemaitre]

they expect a 1D container?

As input but not as output. Here, I think that this is more on the output side that you want to act.

[it176131]

they expect a 1D container?

As input but not as output. Here, I think that this is more on the output side that you want to act.

Correct—those transformers take 1D input and then output a 2D object. I figure if they had access to the set_output method and the user chose to return a dense object rather than sparse, we'd want to persist the index.