Talip7/scikit-learn-issues-multilabel huggingface dataset:
RFC: Potential improvement of HTML Display's css logic

I propose to remove repetition of CSS styling in `sklearn/utils/_repr_html/estimator.py`.

Every time that a cell in a jupyter notebook (or similar) uses the HTML display method, a new CSS block is added to the DOM. This happens in [`estimator_html_repr`](https://github.com/scikit-learn/scikit-learn/blob/4a10d0ed8d85e6ed24a647bd28a65c0c64b101ef/sklearn/utils/_repr_html/estimator.py#L448C5-L472C66).

But CSS is static and the styling rules don't change between estimators. That means that the `#$` in the css file [`estimator.css`](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/utils/_repr_html/estimator.css) is not needed I think.  ~~And we could cache the css file so it's loaded and added to the DOM only once.~~

This way we improve performance by avoiding:

~~- DOM bloat with many duplicate CSS rules.~~
~~- Browser memory waste.~~
~~- Less parsing overhead by the browser (browser processing several times identical styles).~~
- Repeated template substitution through string processing in `estimator.py`.

~~The same thing happens with the javascript script, it is added to the DOM with each cell that uses a HTML display. But the script could be added just once at the bottom of the DOM.~~

Note: the container id in `estimator.py` is still needed as it is used by javascript - It's used to construct the fully qualified name of parameters. But I would add a new class name (to this file) because we still need a CSS selector in `estimator.css`.

I have done local tests that seem to work. If I am missing something about the purpose of multiple CSS blocks, I would love to know. 

WDYT?
@Charlie-XIAO @glemaitre (or anybody) 

Edit: crossing out points above, but keeping the last one. 

<details>
<summary> Screenshot showing issue</summary>
One can see that for each estimator, there is styling and a script.
<img width="1344" height="964" alt="Image" src="https://github.com/user-attachments/assets/ea30c328-42c2-4679-9d72-74a925dd0434"/>
</details>

COMMENT:
Thank you for your interest @sakshisemalti, but I already have a pull request for this.

Labels: RFC
Broken dev website JupyterLite since December 2

can reproduce opening a new notebook in https://scikit-learn.org/dev/lite/lab/index.html

Maybe related to merging https://github.com/scikit-learn/scikit-learn/pull/32824, maybe something else in the world that changed.

Noticed thanks to https://github.com/lesteve/test-scikit-learn-jupyterlite

Error in browser console mentions `micropip`:
```
Uncaught (in promise) Traceback (most recent call last):
  File "/lib/python312.zip/_pyodide/_base.py", line 597, in eval_code_async
    await CodeRunner(
  File "/lib/python312.zip/_pyodide/_base.py", line 411, in run_async
    coroutine = eval(self.code, globals, locals)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<exec>", line 2, in <module>
  File "/lib/python3.12/site-packages/piplite/__init__.py", line 3, in <module>
    from .piplite import install
  File "/lib/python3.12/site-packages/piplite/piplite.py", line 17, in <module>
    from micropip.package_index import ProjectInfo, CompatibilityLayer
ImportError: cannot import name 'CompatibilityLayer' from 'micropip.package_index' (/lib/python3.12/site-packages/micropip/package_index.py)
```

COMMENT:
Just double-checked and the dev JupyterLite is functional again: https://scikit-learn.org/dev/lite/lab/index.html

Labels: Bug, Documentation, Build / CI, wasm
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Dec 10, 2025) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83308&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Dec 10, 2025)
- test_pandas_copy_on_write

COMMENT:
December 2 [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83072&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf). New thing in pandas dev version `pd.option_context("mode.copy_on_write", True)` yields a warning (turned into error in our CI)

```
pandas.errors.Pandas4Warning: Copy-on-Write can no longer be disabled, setting to False has no impact. This option will be removed in pandas 4.0.
```

Since this is in a test, this seems doable to work around it.

Labels: Bug
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Dec 10, 2025) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83308&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Dec 10, 2025)
- test_pandas_copy_on_write

COMMENT:
Actually maybe @AnneBeyer you could have a look at this one? Let me know if something is unclear but basically in the following code, the idea would probably be to do
- a version check if pandas version >= 4, then no need to do pd.option_context copy-on-write is enabled and you can not disable it *I think* (needs to be double-checked)
- a filterwarnings to ignore the warning with a TODO to say remove this when pandas 4 is our minimum version (i.e. in the very far away future 😉)

https://github.com/scikit-learn/scikit-learn/blob/47621fec9c88727fcf06e1acfb9493480454edf9/sklearn/preprocessing/tests/test_target_encoder.py#L704-L714

Labels: Bug
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Nov 30, 2025) ⚠️

**CI failed on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83023&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Nov 30, 2025)
Unable to find junit file. Please see link for details.

COMMENT:
November 30 [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83023&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf) failed at install time because pandas is a released version instead of a dev one, weird. There are some development wheels on [scientific-python-nightly-wheels](https://anaconda.org/channels/scientific-python-nightly-wheels/packages/pandas/files). Let's wait a few days to see if this persists.

Labels: Needs Triage
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Nov 30, 2025) ⚠️

**CI failed on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83023&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Nov 30, 2025)
Unable to find junit file. Please see link for details.

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83036&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf) on Dec 01, 2025

Labels: Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
Thank you for opening this issue.

I'm not an expert on this, but #32766 is the PR that releases 1.8.0rc1, and https://github.com/conda-forge/scikit-learn-feedstock/pull/291 might be related as well.

Cc'ing @lesteve for visibility. Apologies for the spam in advance.

Labels: Build / CI, Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
So between the release candidate and the release we are a bit in a weird state for a variety of reasons (we are using towncrier, we created the release branch but the stable website doesn't point to 1.8, the links are all misleading). This would be nice to figure out how to improve, but so far nobody has found the time ...

The 1.8 release candidate changelog can be found [here](https://scikit-learn.org/1.8/whats_new/v1.8.html#version-1-8-0).

This was noted before, I can't find the relevant issue right now ... actually maybe there is no issue but only scattered comments like https://github.com/scikit-learn/scikit-learn/pull/31469#issuecomment-2932923417.

I ended up creating an issue to track possible improvements on the changelog during the transition pereiod https://github.com/scikit-learn/scikit-learn/issues/32814. I'll try to add more details there beginning of next week.

Labels: Build / CI, Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
> I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: 

@Remi-Gau thanks a lot for testing the release candidate 🙏, definitely let us know when you understand more the source of the problem!

Labels: Build / CI, Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
> > I got there trying to figure out why 1.8.0rc1 was breaking some of our tests:
> 
> [@Remi-Gau](https://github.com/Remi-Gau) thanks a lot for testing the release candidate 🙏, definitely let us know when you understand more the source of the problem!

it's not you, it's us!!!

we are using a [private function from sklearn](https://github.com/nilearn/nilearn/blob/a361e72b5ed447f8bb564d71a7223708b75cb36e/nilearn/decoding/space_net.py#L20), so should not be a surprise that things may break without forewarning

https://github.com/nilearn/nilearn/pull/5869#discussion_r2570009604

Labels: Build / CI, Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
given there is another issue for this, I will close this one.

Labels: Build / CI, Needs Triage
release notes for 1.8.0 look suspiciously empty

Not sure this is relate to this PR specifically but the release notes for version 1.9 look very full and that for 1.8 very empty:

https://scikit-learn.org/dev/whats_new/v1.9.html
https://scikit-learn.org/dev/whats_new/v1.8.html 

Maybe this is normal but I got there trying to figure out why 1.8.0rc1 was breaking some of our tests: so I thought I would open an issue as others may get the same problem trying to get to the changelog.

COMMENT:
> we are using a [private function from sklearn](https://github.com/nilearn/nilearn/blob/a361e72b5ed447f8bb564d71a7223708b75cb36e/nilearn/decoding/space_net.py#L20), so should not be a surprise that things may break without forewarning

OK thanks for letting us know!

Labels: Build / CI, Needs Triage
RFC: `Bagging` estimators: avoid changing `max_samples` default behavior in 1.8

As stated in the change log of PR #31414

> `max_samples` is now interpreted as a fraction of `sample_weight.sum()` instead of `X.shape[0]` when passed as a float.

Because `max_samples` default to `1.0`, this is a change of the default behavior. I expressed concerns about this change in this thread https://github.com/scikit-learn/scikit-learn/pull/31529#discussion_r2541938811 for a different PR but the same kind of change (on random forests).

It seems @antoinebaker, the author of both PRs, agrees with me that having `max_samples=None` as default (and `None` is then re-interpreted as `X.shape[0]`) sounds safer/less surprising for users. (I'll let you confirm or not @antoinebaker ^^).

So **I propose to not merge the PR/commit #31414 in v1.8** (is this even possible? 😅 @lesteve)

Or, merge a PR to change the default before v1.8? (not sure this is possible either).

Why I think this is "urgent"? Because we don't want to change default twice in a row (those are backward incompatible changes: same code produces different results).

What are your thoughts? @antoinebaker @ogrisel

COMMENT:
I confirm that introducing a new default `max_samples = None` for Bagging estimators sounds safer and will help harmonize the API with RandomForest.

Labels: RFC
RFC: `Bagging` estimators: avoid changing `max_samples` default behavior in 1.8

As stated in the change log of PR #31414

> `max_samples` is now interpreted as a fraction of `sample_weight.sum()` instead of `X.shape[0]` when passed as a float.

Because `max_samples` default to `1.0`, this is a change of the default behavior. I expressed concerns about this change in this thread https://github.com/scikit-learn/scikit-learn/pull/31529#discussion_r2541938811 for a different PR but the same kind of change (on random forests).

It seems @antoinebaker, the author of both PRs, agrees with me that having `max_samples=None` as default (and `None` is then re-interpreted as `X.shape[0]`) sounds safer/less surprising for users. (I'll let you confirm or not @antoinebaker ^^).

So **I propose to not merge the PR/commit #31414 in v1.8** (is this even possible? 😅 @lesteve)

Or, merge a PR to change the default before v1.8? (not sure this is possible either).

Why I think this is "urgent"? Because we don't want to change default twice in a row (those are backward incompatible changes: same code produces different results).

What are your thoughts? @antoinebaker @ogrisel

COMMENT:
So I have not followed the sample weight work closely enough to have an opinion on this, but is that somehow related to https://github.com/scikit-learn/scikit-learn/pull/31414#discussion_r2143883085 or is it a different concern?

cc @ogrisel who has followed the discussion, and who will probably have a more informed opinion than me on this issue.

> So I propose to not merge the PR/commit https://github.com/scikit-learn/scikit-learn/pull/31414 in v1.8 (is this even possible? 😅 @lesteve)

Depending on how important we think this is and what is the easiest path, there are a few things we could do:
- we can revert #31414. I tried quickly and it seems like there will be conflicts to fix, but that's probably doable.
- we can do a PR to change `max_samples` default and have it in 1.8
- we can leave it like this and decide that it's not a blocker for 1.8 and see what we can do about it in the future
- plenty of other variations

In an ideal world we decide rather quickly because right now I am aiming to do the 1.8 release no later than next Monday (December 8). This would give us a nice buffer in case we need a quick bug-fix release before the Christmas break.

Labels: RFC
RFC: `Bagging` estimators: avoid changing `max_samples` default behavior in 1.8

As stated in the change log of PR #31414

> `max_samples` is now interpreted as a fraction of `sample_weight.sum()` instead of `X.shape[0]` when passed as a float.

Because `max_samples` default to `1.0`, this is a change of the default behavior. I expressed concerns about this change in this thread https://github.com/scikit-learn/scikit-learn/pull/31529#discussion_r2541938811 for a different PR but the same kind of change (on random forests).

It seems @antoinebaker, the author of both PRs, agrees with me that having `max_samples=None` as default (and `None` is then re-interpreted as `X.shape[0]`) sounds safer/less surprising for users. (I'll let you confirm or not @antoinebaker ^^).

So **I propose to not merge the PR/commit #31414 in v1.8** (is this even possible? 😅 @lesteve)

Or, merge a PR to change the default before v1.8? (not sure this is possible either).

Why I think this is "urgent"? Because we don't want to change default twice in a row (those are backward incompatible changes: same code produces different results).

What are your thoughts? @antoinebaker @ogrisel

COMMENT:
> we can do a PR to change max_samples default and have it in 1.8

I think it would the easiest option, if we can review/merge #32825 fast enough.

Labels: RFC
RFC: `Bagging` estimators: avoid changing `max_samples` default behavior in 1.8

As stated in the change log of PR #31414

> `max_samples` is now interpreted as a fraction of `sample_weight.sum()` instead of `X.shape[0]` when passed as a float.

Because `max_samples` default to `1.0`, this is a change of the default behavior. I expressed concerns about this change in this thread https://github.com/scikit-learn/scikit-learn/pull/31529#discussion_r2541938811 for a different PR but the same kind of change (on random forests).

It seems @antoinebaker, the author of both PRs, agrees with me that having `max_samples=None` as default (and `None` is then re-interpreted as `X.shape[0]`) sounds safer/less surprising for users. (I'll let you confirm or not @antoinebaker ^^).

So **I propose to not merge the PR/commit #31414 in v1.8** (is this even possible? 😅 @lesteve)

Or, merge a PR to change the default before v1.8? (not sure this is possible either).

Why I think this is "urgent"? Because we don't want to change default twice in a row (those are backward incompatible changes: same code produces different results).

What are your thoughts? @antoinebaker @ogrisel

COMMENT:
> I think it would the easiest option, if we can review/merge https://github.com/scikit-learn/scikit-learn/pull/32825 fast enough.

I agree, thanks for PR!

Labels: RFC
TSNE segfaults when numbers turn to NaN

### Describe the bug

When running `TSNE.fit_transform`, if numbers produced during the initialization somehow turned to NaN, it will segfault the process instead of throwing a python exception.

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.manifold import TSNE
X = np.ones((10,5))
TSNE(init="pca", perplexity=5).fit_transform(X)
```

### Expected Results

Should not segfault.

### Actual Results

Segfaults.

### Versions

```shell
System:
    python: 3.12.6 | packaged by conda-forge | (main, Sep 22 2024, 14:16:49) [GCC 13.3.0]
executable: /home/david/miniforge3/bin/python
   machine: Linux-6.12.57+deb12-amd64-x86_64-with-glibc2.36

Python dependencies:
      sklearn: 1.7.1
          pip: 24.2
   setuptools: 74.1.2
        numpy: 2.0.1
        scipy: 1.14.1
       Cython: 3.1.0
       pandas: 2.2.3
   matplotlib: 3.9.2
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libscipy_openblas
       filepath: /home/david/.local/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-99b71e71.so
        version: 0.3.27
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: mkl
    num_threads: 14
         prefix: libmkl_rt
       filepath: /home/david/miniforge3/lib/libmkl_rt.so.2
        version: 2023.2-Product
threading_layer: gnu

       user_api: openmp
   internal_api: openmp
    num_threads: 20
         prefix: libgomp
       filepath: /home/david/miniforge3/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
@david-cortes I think that pca is giving t-sne func zero value (as variance is 0), so zero gets in denominator (func:X_embedded = X_embedded / np.std(X_embedded[:, 0]) * 1e-4), due to which nan values are produced causing segmentation fault.

Labels: Bug, Needs Triage
TSNE segfaults when numbers turn to NaN

### Describe the bug

When running `TSNE.fit_transform`, if numbers produced during the initialization somehow turned to NaN, it will segfault the process instead of throwing a python exception.

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.manifold import TSNE
X = np.ones((10,5))
TSNE(init="pca", perplexity=5).fit_transform(X)
```

### Expected Results

Should not segfault.

### Actual Results

Segfaults.

### Versions

```shell
System:
    python: 3.12.6 | packaged by conda-forge | (main, Sep 22 2024, 14:16:49) [GCC 13.3.0]
executable: /home/david/miniforge3/bin/python
   machine: Linux-6.12.57+deb12-amd64-x86_64-with-glibc2.36

Python dependencies:
      sklearn: 1.7.1
          pip: 24.2
   setuptools: 74.1.2
        numpy: 2.0.1
        scipy: 1.14.1
       Cython: 3.1.0
       pandas: 2.2.3
   matplotlib: 3.9.2
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libscipy_openblas
       filepath: /home/david/.local/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-99b71e71.so
        version: 0.3.27
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: mkl
    num_threads: 14
         prefix: libmkl_rt
       filepath: /home/david/miniforge3/lib/libmkl_rt.so.2
        version: 2023.2-Product
threading_layer: gnu

       user_api: openmp
   internal_api: openmp
    num_threads: 20
         prefix: libgomp
       filepath: /home/david/miniforge3/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
Hi @Aaraviitkgp 

I've opened a PR to solve this issue regarding TSNE segfaults when numbers turn to NaN #32788.

Labels: Bug, Needs Triage
TSNE segfaults when numbers turn to NaN

### Describe the bug

When running `TSNE.fit_transform`, if numbers produced during the initialization somehow turned to NaN, it will segfault the process instead of throwing a python exception.

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.manifold import TSNE
X = np.ones((10,5))
TSNE(init="pca", perplexity=5).fit_transform(X)
```

### Expected Results

Should not segfault.

### Actual Results

Segfaults.

### Versions

```shell
System:
    python: 3.12.6 | packaged by conda-forge | (main, Sep 22 2024, 14:16:49) [GCC 13.3.0]
executable: /home/david/miniforge3/bin/python
   machine: Linux-6.12.57+deb12-amd64-x86_64-with-glibc2.36

Python dependencies:
      sklearn: 1.7.1
          pip: 24.2
   setuptools: 74.1.2
        numpy: 2.0.1
        scipy: 1.14.1
       Cython: 3.1.0
       pandas: 2.2.3
   matplotlib: 3.9.2
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libscipy_openblas
       filepath: /home/david/.local/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-99b71e71.so
        version: 0.3.27
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: mkl
    num_threads: 14
         prefix: libmkl_rt
       filepath: /home/david/miniforge3/lib/libmkl_rt.so.2
        version: 2023.2-Product
threading_layer: gnu

       user_api: openmp
   internal_api: openmp
    num_threads: 20
         prefix: libgomp
       filepath: /home/david/miniforge3/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
@david-cortes this seems like a duplicate of https://github.com/scikit-learn/scikit-learn/issues/28368, right?

Labels: Bug, Needs Triage