Talip7/scikit-learn-issues-multilabel huggingface dataset:
Dark mode on documentation may not work as intended

The dark mode on version 1.7.2, [this page](https://scikit-learn.org/stable/auto_examples/compose/plot_column_transformer_mixed_types.html) looks like this:

<img width="646" height="391" alt="Image" src="https://github.com/user-attachments/assets/9abf17d4-a4de-43d9-82c4-b13446de8386" />

With version 1.8dev0:

<img width="635" height="348" alt="Image" src="https://github.com/user-attachments/assets/34cbc8b3-4848-4028-8b35-2aeeb32aa439" />

Looking at the inspector, there is a bootstrap error: 

<img width="1069" height="121" alt="Image" src="https://github.com/user-attachments/assets/eb337087-66fe-4695-aced-dc2241b8a54b" />


The dev version also seem to change the fonts, and the pipeline is much wider. I don't know if it's on purpose.
Before:
<img width="460" height="329" alt="Image" src="https://github.com/user-attachments/assets/d4e0bc39-3243-4a00-9e8e-8781dfe700de" />
After:

<img width="580" height="325" alt="Image" src="https://github.com/user-attachments/assets/44ae7185-169c-4ec0-92b3-4a1bf471ec5c" />

This may be related to https://github.com/scikit-learn/scikit-learn/pull/32330

@glemaitre @jeremiedbb

COMMENT:
We already addressed the problem of the dark theme. I'll repurpose this issue only to the fragment issue.

Edit: Actually since that we query the parent node, we might not have the issue anymore. Let's check it once the documentation on `main` is built (I could not see anymore the error when building the documentation locally).

Labels: frontend
Dark mode on documentation may not work as intended

The dark mode on version 1.7.2, [this page](https://scikit-learn.org/stable/auto_examples/compose/plot_column_transformer_mixed_types.html) looks like this:

<img width="646" height="391" alt="Image" src="https://github.com/user-attachments/assets/9abf17d4-a4de-43d9-82c4-b13446de8386" />

With version 1.8dev0:

<img width="635" height="348" alt="Image" src="https://github.com/user-attachments/assets/34cbc8b3-4848-4028-8b35-2aeeb32aa439" />

Looking at the inspector, there is a bootstrap error: 

<img width="1069" height="121" alt="Image" src="https://github.com/user-attachments/assets/eb337087-66fe-4695-aced-dc2241b8a54b" />


The dev version also seem to change the fonts, and the pipeline is much wider. I don't know if it's on purpose.
Before:
<img width="460" height="329" alt="Image" src="https://github.com/user-attachments/assets/d4e0bc39-3243-4a00-9e8e-8781dfe700de" />
After:

<img width="580" height="325" alt="Image" src="https://github.com/user-attachments/assets/44ae7185-169c-4ec0-92b3-4a1bf471ec5c" />

This may be related to https://github.com/scikit-learn/scikit-learn/pull/32330

@glemaitre @jeremiedbb

COMMENT:
I cannot see the bootstrap failure as well. @DeaMariaLeon Could you have a look to double check if in the environment where you triggered the error, it is still there.

Labels: frontend
Dark mode on documentation may not work as intended

The dark mode on version 1.7.2, [this page](https://scikit-learn.org/stable/auto_examples/compose/plot_column_transformer_mixed_types.html) looks like this:

<img width="646" height="391" alt="Image" src="https://github.com/user-attachments/assets/9abf17d4-a4de-43d9-82c4-b13446de8386" />

With version 1.8dev0:

<img width="635" height="348" alt="Image" src="https://github.com/user-attachments/assets/34cbc8b3-4848-4028-8b35-2aeeb32aa439" />

Looking at the inspector, there is a bootstrap error: 

<img width="1069" height="121" alt="Image" src="https://github.com/user-attachments/assets/eb337087-66fe-4695-aced-dc2241b8a54b" />


The dev version also seem to change the fonts, and the pipeline is much wider. I don't know if it's on purpose.
Before:
<img width="460" height="329" alt="Image" src="https://github.com/user-attachments/assets/d4e0bc39-3243-4a00-9e8e-8781dfe700de" />
After:

<img width="580" height="325" alt="Image" src="https://github.com/user-attachments/assets/44ae7185-169c-4ec0-92b3-4a1bf471ec5c" />

This may be related to https://github.com/scikit-learn/scikit-learn/pull/32330

@glemaitre @jeremiedbb

COMMENT:
@glemaitre It seems that the error is still there, when you go to the dev version of the documentation. 
With the browser I had just "inspected" and opened the console to see the error. 
I'm looking at it with Chrome.

Labels: frontend
Dark mode on documentation may not work as intended

The dark mode on version 1.7.2, [this page](https://scikit-learn.org/stable/auto_examples/compose/plot_column_transformer_mixed_types.html) looks like this:

<img width="646" height="391" alt="Image" src="https://github.com/user-attachments/assets/9abf17d4-a4de-43d9-82c4-b13446de8386" />

With version 1.8dev0:

<img width="635" height="348" alt="Image" src="https://github.com/user-attachments/assets/34cbc8b3-4848-4028-8b35-2aeeb32aa439" />

Looking at the inspector, there is a bootstrap error: 

<img width="1069" height="121" alt="Image" src="https://github.com/user-attachments/assets/eb337087-66fe-4695-aced-dc2241b8a54b" />


The dev version also seem to change the fonts, and the pipeline is much wider. I don't know if it's on purpose.
Before:
<img width="460" height="329" alt="Image" src="https://github.com/user-attachments/assets/d4e0bc39-3243-4a00-9e8e-8781dfe700de" />
After:

<img width="580" height="325" alt="Image" src="https://github.com/user-attachments/assets/44ae7185-169c-4ec0-92b3-4a1bf471ec5c" />

This may be related to https://github.com/scikit-learn/scikit-learn/pull/32330

@glemaitre @jeremiedbb

COMMENT:
Link with an error https://scikit-learn.org/dev/auto_examples/compose/plot_column_transformer_mixed_types.html

Labels: frontend
Dark mode on documentation may not work as intended

The dark mode on version 1.7.2, [this page](https://scikit-learn.org/stable/auto_examples/compose/plot_column_transformer_mixed_types.html) looks like this:

<img width="646" height="391" alt="Image" src="https://github.com/user-attachments/assets/9abf17d4-a4de-43d9-82c4-b13446de8386" />

With version 1.8dev0:

<img width="635" height="348" alt="Image" src="https://github.com/user-attachments/assets/34cbc8b3-4848-4028-8b35-2aeeb32aa439" />

Looking at the inspector, there is a bootstrap error: 

<img width="1069" height="121" alt="Image" src="https://github.com/user-attachments/assets/eb337087-66fe-4695-aced-dc2241b8a54b" />


The dev version also seem to change the fonts, and the pipeline is much wider. I don't know if it's on purpose.
Before:
<img width="460" height="329" alt="Image" src="https://github.com/user-attachments/assets/d4e0bc39-3243-4a00-9e8e-8781dfe700de" />
After:

<img width="580" height="325" alt="Image" src="https://github.com/user-attachments/assets/44ae7185-169c-4ec0-92b3-4a1bf471ec5c" />

This may be related to https://github.com/scikit-learn/scikit-learn/pull/32330

@glemaitre @jeremiedbb

COMMENT:
Something is trying to select a dom element (using bootstrap wrapped selector) with a strange selector `#:~:text=steps,-list of tuples`.
The callstack is cryptic : (

Labels: frontend
Wrong colors in SVM Tie Breaking Example

### Describe the issue linked to the documentation

In the SVM Tie Breaking Example at this link
https://scikit-learn.org/stable/auto_examples/svm/plot_svm_tie_breaking.html
the colors of the prediction regions are wrong. The green class is predicted as gray and the gray class as green. This is due to a minus sign "-" in front of pred.reshape(xx.shape) inside the call for ax.imshow() function that plots the decision regions.

### Suggest a potential alternative/fix

Removing the minus sign solves the problem.

COMMENT:
Thank you for reporting this issue, @giampierosalvi!

I can confirm that the correct plot should not include the [minus sign](https://github.com/scikit-learn/scikit-learn/blob/eb6dd0a9f8bf446b8adeb968d19ff978271df0e8/examples/svm/plot_svm_tie_breaking.py#L51).

| Current | Without Minus Sign |
|:---:|:---:|
| <img width="544" alt="Screenshot 2025-06-17 160121" src="https://scikit-learn.org/stable/_images/sphx_glr_plot_svm_tie_breaking_001.png" />| <img width="544" height="800" alt="Image" src="https://github.com/user-attachments/assets/2bf60f97-c079-4f16-9851-d6990401b5d8" /> |

Labels: Documentation
Clarify recommended usage of fit_transform() vs fit().transform() in `TargetEncoder` docs

_This is an issue for new contributors. Requirements: be willing to investigae and understand the issue; no pushing of ai-generated commits without human supervision._

The [User Guide on TargetEncoder](https://scikit-learn.org/stable/modules/preprocessing.html#target-encoder) explains the difference between calling `fit_transform()` and `fit().transform()`: the former uses _cross fitting_, while the latter fits on the whole data set (which can lead to data leakage, because values get encoded based on all targets). 
The [docstring](https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.TargetEncoder.html#sklearn.preprocessing.TargetEncoder) for these methods only hint at this difference but do not recommend when to use which.

The docs could be improved by giving a clear recommendation: use `fit_transform() `on the training data, and `transform()` on unseen data. `fit_transform()` provides all the encodings (`encodings_`) , which can be used for calling `transform` later on unseen data. Calling `fit().transform()` on the training set is unsafe. 

All this can be done minimally by adding 1-2 sentences to the User Guide (or re-writing the existing ones) and clarify usage recommendation in the docstrings of both methods.

COMMENT:
Hi, I’d like to work on this issue. Could you please assign it to me?
Thanks!

Labels: Documentation
Clarify recommended usage of fit_transform() vs fit().transform() in `TargetEncoder` docs

_This is an issue for new contributors. Requirements: be willing to investigae and understand the issue; no pushing of ai-generated commits without human supervision._

The [User Guide on TargetEncoder](https://scikit-learn.org/stable/modules/preprocessing.html#target-encoder) explains the difference between calling `fit_transform()` and `fit().transform()`: the former uses _cross fitting_, while the latter fits on the whole data set (which can lead to data leakage, because values get encoded based on all targets). 
The [docstring](https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.TargetEncoder.html#sklearn.preprocessing.TargetEncoder) for these methods only hint at this difference but do not recommend when to use which.

The docs could be improved by giving a clear recommendation: use `fit_transform() `on the training data, and `transform()` on unseen data. `fit_transform()` provides all the encodings (`encodings_`) , which can be used for calling `transform` later on unseen data. Calling `fit().transform()` on the training set is unsafe. 

All this can be done minimally by adding 1-2 sentences to the User Guide (or re-writing the existing ones) and clarify usage recommendation in the docstrings of both methods.

COMMENT:
Hi @srikanth-s2003, sorry but for now this issue is reserved for participants of the PyData Paris sprint. You are not physically present, correct? 

If however no participant claims it with the next 3 hours, the sprint is over and you are free to take it.

Labels: Documentation
⚠️ CI failed on Wheel builder (last failure: Sep 30, 2025) ⚠️

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

COMMENT:
This was the last build with the hang in the macOS wheel. This should be fixed by #32273, we will see that this morning build tell us.

For some unknown reason an error was seen in cp313t (but not cp314t) [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/18118103579/job/51557669416). I don't think we have seen this before ...

```
FAILED ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_no_user_warning_with_scoring
```

with a warning turned into an error:
```
UserWarning: `sklearn.utils.parallel.delayed` should be used with `sklearn.utils.parallel.Parallel` to make it possible to propagate the scikit-learn configuration of the current thread to the joblib workers.
```

Restarting the build removed the issue, so looks like a weird intermittent problem. I would suggest we ignore this until it shows up more regularly.

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

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

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/18150741800) on Oct 01, 2025

Labels: Needs Triage
⚠️ CI failed on Linux_Runs.pylatest_conda_forge_mkl (last failure: Sep 29, 2025) ⚠️

**CI failed on [Linux_Runs.pylatest_conda_forge_mkl](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80512&view=logs&j=dde5042c-7464-5d47-9507-31bdd2ee0a3a)** (Sep 29, 2025)
- test_fit_transform[98]

COMMENT:
related to #32214 and #32184. PR for addressing the failure is here: #32221

Labels: Needs Triage
⚠️ CI failed on Linux_Runs.pylatest_conda_forge_mkl (last failure: Sep 29, 2025) ⚠️

**CI failed on [Linux_Runs.pylatest_conda_forge_mkl](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80512&view=logs&j=dde5042c-7464-5d47-9507-31bdd2ee0a3a)** (Sep 29, 2025)
- test_fit_transform[98]

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80574&view=logs&j=dde5042c-7464-5d47-9507-31bdd2ee0a3a) on Oct 01, 2025

Labels: Needs Triage
PERF: `np_compat` sort/argsort much slower than `np`

#### EDIT: It's because `np_compat` uses stable sort by default, while numpy doesn't

### Describe the bug

By `np_compat` I mean: `from sklearn.externals.array_api_compat import numpy as np_compat`, which is the numpy used for instance in `sklearn.utils.stats._weighted_percentile` when you pass a numpy array in input.


This feels pretty crazy:
- sort is 8x slower with `np_compat.sort` compared to `np.sort`
- argsort is 2x slower

Maybe I'm doing something wrong. Maybe it's my set-up/my machine?

I found that while investigating this comment https://github.com/scikit-learn/scikit-learn/pull/32100#issuecomment-3338768674 about the speed of `_weighted_percentile`

CC @ogrisel 

### Steps/Code to Reproduce

In a notebook cell, run:

```Python
import numpy as np
from sklearn.externals.array_api_compat import numpy as np_compat

x = np.random.rand(int(1e7))
%time np.sort(x)
%time np_compat.sort(x)
%time np.argsort(x)
%time np_compat.argsort(x)
```

### Expected Results

I would expect `np_compat` and `np` to run the exact same underlying C code, and have the same speed.

### Actual Results

Crazy differences:
```
CPU times: user 89.9 ms, sys: 7 ms, total: 96.9 ms
Wall time: 96.9 ms
CPU times: user 793 ms, sys: 16.2 ms, total: 810 ms
Wall time: 809 ms
CPU times: user 622 ms, sys: 8.27 ms, total: 630 ms
Wall time: 630 ms
CPU times: user 1.16 s, sys: 16 ms, total: 1.18 s
Wall time: 1.18 s
```

### Versions

```shell
System:
    python: 3.12.11 (main, Aug 18 2025, 19:19:11) [Clang 20.1.4 ]
executable: /home/arthur/dev-perso/scikit-learn/sklearn-env/bin/python
   machine: Linux-6.14.0-32-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.8.dev0
          pip: None
   setuptools: 80.9.0
        numpy: 2.3.3
        scipy: 1.16.2
       Cython: 3.1.4
       pandas: 2.3.2
   matplotlib: 3.10.6
       joblib: 1.5.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-8fb3d286.so
        version: 0.3.30
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/scipy.libs/libscipy_openblas-b75cc656.so
        version: 0.3.29.dev
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
```

COMMENT:
Ah! I found out why: we force kind="stable" [here](https://github.com/scikit-learn/scikit-learn/blob/4fd34545e517d164881126ce539aa8bfabae86d2/sklearn/externals/array_api_compat/common/_aliases.py#L481) and [here](https://github.com/scikit-learn/scikit-learn/blob/4fd34545e517d164881126ce539aa8bfabae86d2/sklearn/externals/array_api_compat/common/_aliases.py#L513)

Labels: Bug, Performance
PERF: `np_compat` sort/argsort much slower than `np`

#### EDIT: It's because `np_compat` uses stable sort by default, while numpy doesn't

### Describe the bug

By `np_compat` I mean: `from sklearn.externals.array_api_compat import numpy as np_compat`, which is the numpy used for instance in `sklearn.utils.stats._weighted_percentile` when you pass a numpy array in input.


This feels pretty crazy:
- sort is 8x slower with `np_compat.sort` compared to `np.sort`
- argsort is 2x slower

Maybe I'm doing something wrong. Maybe it's my set-up/my machine?

I found that while investigating this comment https://github.com/scikit-learn/scikit-learn/pull/32100#issuecomment-3338768674 about the speed of `_weighted_percentile`

CC @ogrisel 

### Steps/Code to Reproduce

In a notebook cell, run:

```Python
import numpy as np
from sklearn.externals.array_api_compat import numpy as np_compat

x = np.random.rand(int(1e7))
%time np.sort(x)
%time np_compat.sort(x)
%time np.argsort(x)
%time np_compat.argsort(x)
```

### Expected Results

I would expect `np_compat` and `np` to run the exact same underlying C code, and have the same speed.

### Actual Results

Crazy differences:
```
CPU times: user 89.9 ms, sys: 7 ms, total: 96.9 ms
Wall time: 96.9 ms
CPU times: user 793 ms, sys: 16.2 ms, total: 810 ms
Wall time: 809 ms
CPU times: user 622 ms, sys: 8.27 ms, total: 630 ms
Wall time: 630 ms
CPU times: user 1.16 s, sys: 16 ms, total: 1.18 s
Wall time: 1.18 s
```

### Versions

```shell
System:
    python: 3.12.11 (main, Aug 18 2025, 19:19:11) [Clang 20.1.4 ]
executable: /home/arthur/dev-perso/scikit-learn/sklearn-env/bin/python
   machine: Linux-6.14.0-32-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.8.dev0
          pip: None
   setuptools: 80.9.0
        numpy: 2.3.3
        scipy: 1.16.2
       Cython: 3.1.4
       pandas: 2.3.2
   matplotlib: 3.10.6
       joblib: 1.5.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-8fb3d286.so
        version: 0.3.30
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/scipy.libs/libscipy_openblas-b75cc656.so
        version: 0.3.29.dev
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
```

COMMENT:
But we should probably set `stable=False` in the argsort inside `sklearn.utils.stats._weighted_percentile`: stable sort is not needed there. I'll open a PR for that (and other places where stable sort might not be needed).

(we can probably close this issue?)

Labels: Bug, Performance
PERF: `np_compat` sort/argsort much slower than `np`

#### EDIT: It's because `np_compat` uses stable sort by default, while numpy doesn't

### Describe the bug

By `np_compat` I mean: `from sklearn.externals.array_api_compat import numpy as np_compat`, which is the numpy used for instance in `sklearn.utils.stats._weighted_percentile` when you pass a numpy array in input.


This feels pretty crazy:
- sort is 8x slower with `np_compat.sort` compared to `np.sort`
- argsort is 2x slower

Maybe I'm doing something wrong. Maybe it's my set-up/my machine?

I found that while investigating this comment https://github.com/scikit-learn/scikit-learn/pull/32100#issuecomment-3338768674 about the speed of `_weighted_percentile`

CC @ogrisel 

### Steps/Code to Reproduce

In a notebook cell, run:

```Python
import numpy as np
from sklearn.externals.array_api_compat import numpy as np_compat

x = np.random.rand(int(1e7))
%time np.sort(x)
%time np_compat.sort(x)
%time np.argsort(x)
%time np_compat.argsort(x)
```

### Expected Results

I would expect `np_compat` and `np` to run the exact same underlying C code, and have the same speed.

### Actual Results

Crazy differences:
```
CPU times: user 89.9 ms, sys: 7 ms, total: 96.9 ms
Wall time: 96.9 ms
CPU times: user 793 ms, sys: 16.2 ms, total: 810 ms
Wall time: 809 ms
CPU times: user 622 ms, sys: 8.27 ms, total: 630 ms
Wall time: 630 ms
CPU times: user 1.16 s, sys: 16 ms, total: 1.18 s
Wall time: 1.18 s
```

### Versions

```shell
System:
    python: 3.12.11 (main, Aug 18 2025, 19:19:11) [Clang 20.1.4 ]
executable: /home/arthur/dev-perso/scikit-learn/sklearn-env/bin/python
   machine: Linux-6.14.0-32-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.8.dev0
          pip: None
   setuptools: 80.9.0
        numpy: 2.3.3
        scipy: 1.16.2
       Cython: 3.1.4
       pandas: 2.3.2
   matplotlib: 3.10.6
       joblib: 1.5.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-8fb3d286.so
        version: 0.3.30
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 16
         prefix: libscipy_openblas
       filepath: /home/arthur/dev-perso/scikit-learn/sklearn-env/lib/python3.12/site-packages/scipy.libs/libscipy_openblas-b75cc656.so
        version: 0.3.29.dev
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 16
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
```

COMMENT:
I global searched for xp.argsort/sort and found it in two places:
- in `sklearn.utils.stats._weighted_percentile`
- in `sklearn/externals`. I just openned a PR for that in https://github.com/data-apis/array-api-extra

Labels: Bug, Performance