✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: a4e3fe4. Link to the linter CI: here}

The approach looks reasonable to me. It is based on how the deprecation of Y for y is done.

For me the big question is if it is worth the effort to do this. What is the problem we are fixing by doing this (except for solving a naming inconsistency)?

The approach looks reasonable to me. It is based on how the deprecation of Y for y is done.

For me the big question is if it is worth the effort to do this. What is the problem we are fixing by doing this (except for solving a naming inconsistency)?

I encountered it while trying to switch a Pipeline out with a StandardScaler and using kwargs.
This was my reproducible example from the issue:

# Has Xt arg
pipeline = make_pipeline(StandardScaler())
Xt = pipeline.fit_transform(X)
X_again = pipeline.inverse_transform(Xt=Xt)

# inverse_transform takes X instead of Xt
transformer = StandardScaler()
Xt = transformer.fit_transform(X)
X_again = transformer.inverse_transform(Xt=Xt)
# TypeError: inverse_transform() got an unexpected keyword argument 'Xt'

Pipelines might be the most used object but I'd think having a uniformed API with the transformers themselves might be good.

What are your thoughts?

I agree it is a bit annoying that using/not using a Pipeline changes whether your code works or not.

The big question for me is how typical transformer.inverse_transform(Xt) vs transformer.inverse_transform(Xt=Xt) is. My guess would be that most people use the "positional argument" version. So they never run into the problem that the argument is sometimes called X and sometimes Xt. However I don't know how we could resolve this question with some data, instead of people's hunches :-/

Maybe other people/maintainers have an opinion? @scikit-learn/core-devs

I'm not really in favor of such a change:

• It breaks backward compatibility for cosmetic reason, which I something I frown on, as it is pushing pain to our users
• It breaks consistency across models, all the examples that I looked up use "X" in inverse transform (PCA https://scikit-learn.org/stable/modules/generated/sklearn.decomposition.PCA.html#sklearn.decomposition.PCA.inverse_transform , RobustScaler, feature selection object...)

Here's the list:

CCA                           X
DictVectorizer                X
FastICA                       X
FeatureAgglomeration          Xt
FunctionTransformer           X
GaussianRandomProjection      X
GenericUnivariateSelect       X
GridSearchCV                  Xt
IncrementalPCA                X
KBinsDiscretizer              Xt
KernelPCA                     X
LabelBinarizer                Y
LabelEncoder                  y
MaxAbsScaler                  X
MinMaxScaler                  X
MiniBatchNMF                  Xt
MiniBatchSparsePCA            X
MultiLabelBinarizer           yt
NMF                           Xt
OneHotEncoder                 X
OrdinalEncoder                X
PCA                           X
PLSCanonical                  X
PLSRegression                 X
Pipeline                      Xt
PowerTransformer              X
QuantileTransformer           X
RFE                           X
RFECV                         X
RandomizedSearchCV            Xt
RobustScaler                  X
SelectFdr                     X
SelectFpr                     X
SelectFromModel               X
SelectFwe                     X
SelectKBest                   X
SelectPercentile              X
SequentialFeatureSelector     X
SimpleImputer                 X
SparsePCA                     X
SparseRandomProjection        X
StandardScaler                X
TruncatedSVD                  X
VarianceThreshold             X

It's true that most estimators use X. However it's unfortunate that the main meta-estimators (Pipeline, Search*) use Xt, as explained in #28756 (comment).

I agree that we should not change for cosmetic reasons. But the inconsistency between most estimators and the main meta-estimators gives a bad user experience that we can improve. I don't know however how many users are concerned, i.e. using kwargs for X.

Side note: only the users who pass X as kwarg would actually see the API change and the deprecation warnings and this change aims to improve the experience of these users. It would be transparent for other users.

So overall I'm +0.5 here.

I didn't count but from scrolling through the list of estimators it seems many of them use X. Maybe, if we do anything, we should standardise on X?

mine too at first, but notice that the Xts are in Pipeline, GridSearchCV, RandomizedSearchCV, ..., so changing them might impact as many users as changing the others :/

I feel like the impact is minimum because it only impacts users that write inverse_transform(Xt=...). In all our documentation, we always set the input of inverse_transform as a positional argument.

We'll still go through a deprecation cycle and the change is fairly simple for users to make. (Make the input positional or use X=...).

Thanks everyone for the feedback!

Thanks for making the list @jeremiedbb. Very helpful!
My sense is that Pipeline, GridSearchCV, RandomizedSearchCV would be the most used and since they use Xt then that should be the way to go.

Personally, X doesn't make much sense to me if
Xt = transform(X)
since then
X = inverse_transform(Xt)

I want to note that the goal is to be backwards compatible. That would mean:

• No warning with positional arguments. instance.inverse_transform(Xt)
• Standard deprecation warning if keyword X. instance.inverse_transform(X=...)
• ValueError if both keywords are used

I will fix all of the examples in docstrings if they use a keyword example. However, I don't think any do at first glance. https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22inverse_transform(X%3D%22&type=code

I didn't have None for Xt which might have caused some confusion. I've added that with the latest commit!

+1 for making it consistent. For me, it‘s not a cosmetic change, but a real flaw. The sooner the fix the better.

+1 for making it consistent. For me, it‘s not a cosmetic change, but a real flaw. The sooner the fix the better.

🎉

If others have the same idea, then I will go through with the rest of the implementation!

@wd60622 I‘m just one voice and @GaelVaroquaux has a different view than me. So it’s not decided yet.

I am not a core dev but regarding the change I am aligned with @GaelVaroquaux.
Also, for me the context has already be provided by the method itself inverse_transform so there is not need for Xt.
For consistency I would prefer everywhere X.
However, I expect that most of us use inverse_transform with positional argument.

Regarding the impact I agree with @thomasjpfan

I feel like the impact is minimum because it only impacts users that write inverse_transform(Xt=...). In all our documentation, we always set the input of inverse_transform as a positional argument.

We'll still go through a deprecation cycle and the change is fairly simple for users to make. (Make the input positional or use X=...).

A public poll regarding the use of positional or keyword arguments usage in inverse_transform would provide a sense of the impact of the change.

A public poll

That's expensive and I would dedicate such a poll to much more impactful questions.

Consistency is a good thing.

Totally, agree. Hence the PR 😄

Hence given the summary above showing that X and Xt are used, I can be convinced :) I'm slightly more in favor of converging to X than to Xt.

Is there an issue with the name Xt? Why is X better than Xt given my argument that that name doesn't make much sense?
Even though more transformers use X, I think that should be weighted by the frequency of use. To me, the Pipeline, GridSearchCV, RandomizedSearchCV are the most used. Since they use Xt, the scale leans toward Xt if it is a weighted average.
However, my usage weights might be a wrong assumption. Just my gut off using the package the last few years

I'm slightly more in favor of converging to X than to Xt.

+1. Makes the API simpler.

I guess we have reached a decision.

I'm slightly more in favor of converging to X than to Xt.

+1. Makes the API simpler.

I guess we have reached a decision.

And that is X?

X it is!

I have made the adjustments based on the latest feedback @betatim @jeremiedbb. Hope they're squashed 😆

@wd60622 I think that you misunderstood, the decision was not to put them between quotes. Can you please revert your latest changes, or I can do it if you prefer ?

@wd60622 I think that you misunderstood, the decision was not to put them between quotes. Can you please revert your latest changes, or I can do it if you prefer ?

Sorry. I did but them between quotes though! Not sure what you mean then

Yeah, you can revert!

the decision was not to put them between quotes.

"not to" 😄 . Don't worry, I'll revert.