Talip7/scikit-learn-issues-multilabel huggingface dataset:
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
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.

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
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.

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
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).

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
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.

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

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

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
If we do a function, in effect, we're changing 

(1)
```py
from sklearn.frozen import FrozenEstimator
MetaEstimator(estimator=FrozenEstimator(subestimator))
```

or
```py
import sklearn
MetaEstimator(estimator=sklearn.frozen.FrozenEstimator(subestimator))
```

to

(2)
```py
from sklearn import freeze
MetaEstimator(estimator=freeze(subestimator))
```
or
```py
import sklearn
MetaEstimator(estimator=sklearn.freeze(subestimator))
```

while having a method, would mean

(3)
```py
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.

Labels: API, RFC
Implications of FrozenEstimator on our API

With https://github.com/scikit-learn/scikit-learn/pull/29705, we have a simple way to freeze estimators, which means there is no need for `cv="prefit"`. This also opens the door for https://github.com/scikit-learn/scikit-learn/pull/8350 to make `Pipeline` and `FeatureUnion` follow our conventions. This issue is to discuss the API implications of introducing `FrozenEstimator`. Here are the two I had in mind:

### cv="prefit"

For the cv case, users pass a frozen estimator directly into cv:

```python
rf = RandomForestClassifer()
rf.fit(X_train, y_train)
frozen_rf = FrozenEstimator(rf)

calibration = CalibratedClassifierCV(frozen_rf)
calibration.fit(X_calib, y_calib)
```

Making this change will simplify our codebase with `cv="prefit"`

### compose.Pipeline

We introduce a new `compose.Pipeline` which follows our conventions with `clone`. (The current `pipeline.Pipeline` does not clone.)

```python
from sklearn.compose import Pipeline

prep = ColumnTransformer(...)
prep.fit(X_train, y_train)
frozen_prep = FrozenEstimator(prep)

pipe = Pipeline([frozen_prep, LogisticRegression()])

pipe.fit(X_another, y_another)
```

---

In both cases, I like prefer the semantics of `FrozenEstimator`.

COMMENT:
> 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.

Labels: API, RFC
⚠️ CI failed on Wheel builder (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/10978032969)** (Sep 22, 2024)

COMMENT:
The same tests are failing here: https://github.com/scikit-learn/scikit-learn/issues/29889

Labels: Needs Triage
⚠️ CI failed on Wheel builder (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/10978032969)** (Sep 22, 2024)

COMMENT:
The root cause is likely numpy-dev or scipy-dev https://github.com/scikit-learn/scikit-learn/issues/29864

Labels: Needs Triage
⚠️ CI failed on Wheel builder (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/10978032969)** (Sep 22, 2024)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/10987327652) on Sep 23, 2024

Labels: Needs Triage
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_ovr_multinomial_iris
- test_logistic_regression_multinomial
- test_sample_weight_not_modified[class_weight0-multinomial]
- test_sample_weight_not_modified[class_weight0-auto]
- test_warm_start_effectiveness

COMMENT:
The same tests are failing in the wheel builder for Python 3.13 on linux: https://github.com/scikit-learn/scikit-learn/issues/29891

Labels: Needs Triage
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_ovr_multinomial_iris
- test_logistic_regression_multinomial
- test_sample_weight_not_modified[class_weight0-multinomial]
- test_sample_weight_not_modified[class_weight0-auto]
- test_warm_start_effectiveness

COMMENT:
The root cause is likely numpy-dev or scipy-dev https://github.com/scikit-learn/scikit-learn/issues/29864

Labels: Needs Triage
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[21-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_ovr_multinomial_iris
- test_logistic_regression_multinomial
- test_sample_weight_not_modified[class_weight0-multinomial]
- test_sample_weight_not_modified[class_weight0-auto]
- test_warm_start_effectiveness

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70436&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2) on Sep 23, 2024

Labels: Needs Triage
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
We have https://github.com/scikit-learn/scikit-learn/pull/29789 to get closer to a release.

Labels: Build / CI
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Closing as a duplicate, And we'll be releasing the wheels for the next release which us coming soon anyway.

Labels: Build / CI
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
I would suggest we leave this one open, be it only to have an issue for tracking progress. It feels a bit weird to close it as "not planned" since we are planning to publish Python 3.13 wheels.

I am not sure which issue this is a duplicate of by the way ... the closest one being https://github.com/scikit-learn/scikit-learn/issues/29292 but it is about development wheels so not quite the same, since this one is about release wheels on PyPI.

Labels: Build / CI
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Feels like this is about publish wheels for 1.5.2, which is what we decided not to do.

Labels: Build / CI
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
> Feels like this is about publish wheels for 1.5.2, which is what we decided not to do.

My understanding was that there was a possibility that we upload the wheels manually for 1.5.2, but we'll see :wink:

Labels: Build / CI
Publish Python 3.13 wheels on PyPI for 1.5.2

### Describe the workflow you want to enable

Hello,
Could you please release CPython 3.13 manylinux wheels on PyPI?
Python 3.13.0~rc2 has already been released and there will be no ABI changes even for bug fixes at this point.
It will help projects starts using scikit-learn from the day the final candidate is released. Python 3.13 is also a main Python in Fedora 41 which will be released in October, so we'd like to enable seamless `pip install scikit-learn` experience to our users.

### Describe your proposed solution

Publishing the wheels on PyPI

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Wheels are available for Python 3.13 on PyPI

Labels: Build / CI
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
I can reproduce with numpy 2.1.1. and scipy-dev I am going to wild-guess that this is the LBFGS C-rewrite https://github.com/scipy/scipy/pull/21314?

I opened https://github.com/scipy/scipy/issues/21583.

Labels: Needs Triage
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
I fixed the problem you have submitted to https://github.com/scipy/scipy/issues/21583 Let's see what the machine says today about possible remaining issues.

Labels: Needs Triage
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
Nice, thanks a lot for the fix! Locally at least, all the previously failing tests now pass :tada:

Labels: Needs Triage