Was just talking with @glemaitre about this and we also very much agree with these points (or at least I thought Guillaume agrees 😅 ). I'd like to have the FrozenEstimator PR merged, and then open follow up PRs to deal with these implications.

This also deserves a @scikit-learn/core-devs ping.

In addition of cv="prefit", we also have the option prefit=True for SelectFromModel.

So in general, I think that using the FrozenEstimator is the right way because:

• it is explicit which estimator is frozen
• it is less brittle when having nested objects (pipeline in column transformer inside a cross-validation). We never really got it right in the past because this is rather complex to not miss a cloning somewhere.
• it allows to remove a parameter option that is probably of interest of "advanced" user reducing a bit of complexity
• thinking of cv="prefit", the semantic of the parameter & value is not straightforward without reading the documentation (a CV is not really prefitted)
• it simplifies the code internally because clone is handled by the FrozenEstimator and not anymore in each of the meta-estimator.

To me there is one downside:

• we request to nest an estimator inside a new meta-estimator. However, taken that this is an advanced use-case, I think that this is a mitigated complexity considering the type of user that are going to use the pattern.

So given the pros/cons that I could come with, I'm pretty much in favor of introducing FrozeEstimator and deprecate cv="prefit" and prefit=True/False

To me there is one downside:

• we request to nest an estimator inside a new meta-estimator. However, taken that this is an advanced use-case, I think that this is a mitigated complexity considering the type of user that are going to use the pattern.

So given the pros/cons that I could come with, I'm pretty much in favor of introducing FrozeEstimator and deprecate cv="prefit" and prefit=True/False

Would it be weird to add a freeze() / get_frozen() method to BaseEstimator, so that all estimators can effectively return a FrozenEstimator without having to import FrozenEstimator and do the nesting?

Perhaps it adds too much complexity and the user is confused because then there are multiple ways of "getting a frozen estimator"?

I wouldn't mind a def get_frozen(self): return FrozenEstimator(self) indeed. But I think we can move forward with the rest, and decide if we want to add this nicety later. Good suggestion though.

@ogrisel you might like the get_frozen() idea here if you don't want users to have to do an extra import.

I wouldn't mind a def get_frozen(self): return FrozenEstimator(self) indeed.

No strong opinion on whether we need it or not, but if we introduce it, I would vote in favor of a top level sklearn.freeze to be consistent with our existing sklearn.clone.

@ogrisel you might like the get_frozen() idea here if you don't want users to have to do an extra import.

You still need to import it (unless you already imported the top level sklearn for other things).

EDIT: this comment is wrong.

Let's finalize the reviews of #30171 and #30172 first, and then let's open a PR to explore how sklearn.freeze (or sklearn.frozen.get_frozen) would feel in the examples.

Oh, I misread the proposals. I did not realize the proposal above was about introducing a method instead of a function... CalibratedClassifierCV(mode.freeze()).fit(X_cal, y_cal) would feel right for me. But it's expanding the common public API for scikit-learn estimators, possibly also for third-party estimator developers.

For third party estimators who inherit from BaseEstimator (which should be all of them at this point with our new requirements), then they don't really need to do anything.

I feel that a function rather than a method is more natural with the current state of our code base. It would stand nicely next to clone.

I would find strange that cloning and freeze are not aligned in this regard (i.e. function vs method).

I would be more in favor of adding a clone to BaseEstimator rather than putting freeze beside clone 😁 .

I'd be somewhat against a sklearn.base.freeze as opposed to BaseEstimator.freeze, since the former requires the user to do an extra import anyway. And at the point we require an extra import, it could be FrozenEstimator itself.

My intuition is also that a standalone function would be nicer than adding a method.

If we do a function, in effect, we're changing

(1)

from sklearn.frozen import FrozenEstimator
MetaEstimator(estimator=FrozenEstimator(subestimator))

or

import sklearn
MetaEstimator(estimator=sklearn.frozen.FrozenEstimator(subestimator))

to

(2)

from sklearn import freeze
MetaEstimator(estimator=freeze(subestimator))

or

import sklearn
MetaEstimator(estimator=sklearn.freeze(subestimator))

while having a method, would mean

(3)

MetaEstimator(estimator=subestimator.freeze())

To me, (1) and (2) are not different enough to warrant the function, while (3) is a nicer enough experience that it's worth doing.

I would be more in favor of adding a clone to BaseEstimator rather than putting freeze beside clone 😁.

Since this alternative avoids an import and looking at #30171 when it comes to usability, then I would agree that methods might be nicer to use.