Talip7/scikit-learn-issues-multilabel huggingface dataset:
StandardScaler `mean_` is not None when `with_mean=False`

### Describe the bug

In the documentation, it is stated that

> **mean_**
ndarray of shape (n_features,) or None
The mean value for each feature in the training set. Equal to None when with_mean=False.

But the actual mean values are returned for `mean_` attribute.





### Steps/Code to Reproduce

```python
from sklearn.preprocessing import StandardScaler
data = [[0, 0], [0, 0], [1, 1], [1, 1]]
scaler = StandardScaler(with_mean=False)
print(scaler.fit(data))
print(scaler.mean_)
```

### Expected Results

StandardScaler(with_mean=False)
None

### Actual Results

StandardScaler(with_mean=False)
[0.5 0.5]

### Versions

```shell
System:
    python: 3.10.10 | packaged by conda-forge | (main, Mar 24 2023, 20:12:31) [Clang 14.0.6 ]
executable: /opt/homebrew/Caskroom/miniforge/base/envs/rim/bin/python3.10
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.1.3
          pip: 23.1.2
   setuptools: 67.7.2
        numpy: 1.23.3
        scipy: 1.9.1
       Cython: None
       pandas: 2.0.1
   matplotlib: 3.6.0
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /opt/homebrew/Caskroom/miniforge/base/envs/xxx/lib/libopenblas.0.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: VORTEX
    num_threads: 10

       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /opt/homebrew/Caskroom/miniforge/base/envs/xxx/lib/libomp.dylib
        version: None
    num_threads: 10
```

COMMENT:
The documentation was fixed in https://github.com/scikit-learn/scikit-learn/pull/26753

Labels: Bug
Adding `estimators_samples_` property to ensemble of tree methods such as RandomForest and ExtraTrees

### Describe the workflow you want to enable

In `BaggingClassifier/Regressor`, which is basically an ensemble of trees, it is possible to generate the sampled indices on the fly for the forest using `estimators_samples_`.

I am wondering if it is possible to add this to all the forest-based methods (e.g. ExtraTrees and RandomForest), since there are many times, one might be interested in analyzing the samples which each tree did not see. 

The current forests have the option of fitting the `oob` decision function during `fit()`, but we lose information on what the oob sample indices were with respect to each tree.

### Describe your proposed solution

Add a similar `estimators_samples_` function, which generates the sample indices on the fly, to prevent having to store the sample data.

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

A user would have to keep track of this outside of the class, which may be prone to error.

### Additional context

Xref on BaggingClassifier: https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.BaggingRegressor.html#sklearn.ensemble.BaggingRegressor.estimators_samples_

COMMENT:
Sounds good to: it would improve the consistency between bagging-style ensemble estimators and should not add any overhead for users who don't need it.

Labels: New Feature
Adding `estimators_samples_` property to ensemble of tree methods such as RandomForest and ExtraTrees

### Describe the workflow you want to enable

In `BaggingClassifier/Regressor`, which is basically an ensemble of trees, it is possible to generate the sampled indices on the fly for the forest using `estimators_samples_`.

I am wondering if it is possible to add this to all the forest-based methods (e.g. ExtraTrees and RandomForest), since there are many times, one might be interested in analyzing the samples which each tree did not see. 

The current forests have the option of fitting the `oob` decision function during `fit()`, but we lose information on what the oob sample indices were with respect to each tree.

### Describe your proposed solution

Add a similar `estimators_samples_` function, which generates the sample indices on the fly, to prevent having to store the sample data.

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

A user would have to keep track of this outside of the class, which may be prone to error.

### Additional context

Xref on BaggingClassifier: https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.BaggingRegressor.html#sklearn.ensemble.BaggingRegressor.estimators_samples_

COMMENT:
Cool! I will submit a PR then for the following:

1. add the workflow for using `estimators_samples_` similar to `Bagging*` to `RandomForest*` and `ExtraTrees*` storing `_seed` and then
2. update documentation

Labels: New Feature
MAINT: Sphinx gallery bug after Sphinx min dependency increased to 6.0.0

Sphinx gallery error when resolving links:
```
TypeError: list indices must be integers or slices, not str
```
See CI: https://app.circleci.com/pipelines/github/scikit-learn/scikit-learn/48046/workflows/c2bbef06-cb62-416d-98c5-29b211a01b93/jobs/240437 from #26677 

This bug was introduced after sphinx 4.3.0 (thus introduced after #26627) and fixed in sphinx gallery 0.10.1, see: https://github.com/sphinx-gallery/sphinx-gallery/issues/879

Can we increase the min dep of sphinx gallery to 0.10.1 ?

COMMENT:
https://github.com/scikit-learn/scikit-learn/pull/26705 should resolve the issue

Labels: Documentation, Build / CI
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
The errors are legit: some segfault in Windows and MacOS when running the test from `extmath.py`

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
The segfault seems to have been caused by the merge of https://github.com/scipy/scipy/pull/18358 (cc @ilayn) (EDIT this was included in scipy 1.11.0 released yesterday):

```
    File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/scipy/linalg/_decomp_lu.py", line 313 in lu
    File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/sklearn/utils/extmath.py", line 278 in randomized_range_finder
    File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/sklearn/utils/extmath.py", line 450 in randomized_svd
    File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/sklearn/utils/extmath.py", line 608 in _randomized_eigsh
    File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/sklearn/utils/tests/test_extmath.py", line 226 in test_randomized_eigsh_compared_to_others
```

I suppose we should be able to reproduce locally with a post-mortem native debugger on macos or windows against scipy's nightly wheels with:

```
pytest -k test_randomized_eigsh_compared_to_others sklearn/utils/tests/test_extmath.py
```

Too bad it does not fail on linux. I don't know how to use gdb on windows nor how to install gdb on my M1 macos laptop...

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
For reference, here are the details of one of the runtime environments where it fails:

<details>

```
  System:
      python: 3.11.4 (v3.11.4:d2340ef257, Jun  6 2023, 19:15:51) [Clang 13.0.0 (clang-1300.0.29.30)]
  executable: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/bin/python
     machine: macOS-12.6.6-x86_64-i386-64bit
  
  Python dependencies:
        sklearn: 1.4.dev0
            pip: 23.1.2
     setuptools: 67.7.2
          numpy: 1.25.0
          scipy: 1.11.0
         Cython: None
         pandas: 2.0.2
     matplotlib: None
         joblib: 1.2.0
  threadpoolctl: 3.1.0
  
  Built with OpenMP: True
  
  threadpoolctl info:
         user_api: openmp
     internal_api: openmp
           prefix: libomp
         filepath: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/sklearn/.dylibs/libomp.dylib
          version: None
      num_threads: 3
  
         user_api: blas
     internal_api: openblas
           prefix: libopenblas
         filepath: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
          version: 0.3.23
  threading_layer: pthreads
     architecture: Sandybridge
      num_threads: 3
  
         user_api: blas
     internal_api: openblas
           prefix: libopenblas
         filepath: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-0tc4opqq/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/scipy/.dylibs/libopenblas.0.dylib
          version: 0.3.21.dev
  threading_layer: pthreads
     architecture: Sandybridge
      num_threads: 3
```

</details>

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
Actually I am confused, I thought it was the `scipy-dev` build but it's actually our own dev build against `scipy: 1.11.0` <del>so it's probably not related to https://github.com/scipy/scipy/pull/18358 as I thought.</del>

Actually it is: scipy 1.11.0 was released yesterday, so it's the first release to include https://github.com/scipy/scipy/pull/18358.

Too bad our `scipy-dev` nightly build was not affected to detect this problem earlier.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
The cirusci confirms that this is an `x86_64` specific problem, we did not get the failure on arm64 / macos:

- https://cirrus-ci.com/build/5045362751176704

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
Nevermind my OpenMP comment in the issue tracker, here there is a job also x86 but python 3.8 that didn't fail. I still don't know how to reproduce this without OpenMP to be honest. Does anyone have something similar with multithreading or parallel etc.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
> Too bad our scipy-dev nightly build was not affected to detect this problem earlier.

Also how did this happen? In the past it caught almost instantly any discrepancies.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
> Also how did this happen? In the past it caught almost instantly any discrepancies.

Our `scipy-dev` build is Linux only so far.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
> Also 3.8 too didn't fail for macos. Weird

This is because those 3.8 builds use scipy 1.10.1 instead of 1.11.0. Probably because scipy 1.11.0 wasn't released for Python 3.8:

https://pypi.org/project/scipy/1.11.0/#files

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
LU is not releasing GIL anyways so if there was a memory issue then it would have been found on Linux too. 

Can you point me to where the exact LU call is done with what inputs? I can't find the usecase under all that randomised algorithms

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
For the interested, I have an alternative implementation in https://github.com/scipy/scipy/pull/18762 if someone can test it out that would be great.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5397015550)** (Jun 28, 2023)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/5408261793) on Jun 29, 2023

Labels: Needs Triage
DOC a spefic docstring guide for scikit-learn

When I was contributing to scikit-learn, what often confuses me is how to write docstrings. For instance, should I use backticks or double backticks for inline codes? Should I make a line break between parameters or not? etc.

Asides from these details that are only visible in codes, some inconsistencies exist in the public API that are visible to general users. For instance, some short summaries end with period while some do not; descriptions of parameter types are inconsistent; some string literals and True/False are considered inline codes and enclosed in backticks while others are not; etc.

IMHO, a specific docstring guide would greatly help improve consistency. Indeed [PEP257](https://peps.python.org/pep-0257/) already documents some semantics and conventions for docstrings, it is far too general for a project of this scale. Some other projects indeed have docstring guides (e.g., [pandas docstring guide](https://pandas.pydata.org/docs/development/contributing_docstring.html)).

*I am aware that this will require significant job and is not of that great importance so it is completely fine if maintainers don't accept this proposal.*

COMMENT:
The guidelines have been proposed here: https://scikit-learn.org/dev/developers/contributing.html#documentation

It covers pretty well what needs to be done. The discrepancy in the current documentation is due to legacy code. Solving all the issues according to the guideline would be tedious and maybe not that much impactful for the end-user. I think it was the reason that we thought about fixing the documentation as we go instead to have a dedicated meta-issue and solving everything. Currently, we only adopted to follow strictly the `numpydoc` validation (done with a CI job).

Labels: Needs Triage
DOC a spefic docstring guide for scikit-learn

When I was contributing to scikit-learn, what often confuses me is how to write docstrings. For instance, should I use backticks or double backticks for inline codes? Should I make a line break between parameters or not? etc.

Asides from these details that are only visible in codes, some inconsistencies exist in the public API that are visible to general users. For instance, some short summaries end with period while some do not; descriptions of parameter types are inconsistent; some string literals and True/False are considered inline codes and enclosed in backticks while others are not; etc.

IMHO, a specific docstring guide would greatly help improve consistency. Indeed [PEP257](https://peps.python.org/pep-0257/) already documents some semantics and conventions for docstrings, it is far too general for a project of this scale. Some other projects indeed have docstring guides (e.g., [pandas docstring guide](https://pandas.pydata.org/docs/development/contributing_docstring.html)).

*I am aware that this will require significant job and is not of that great importance so it is completely fine if maintainers don't accept this proposal.*

COMMENT:
@glemaitre Sorry that I missed that guideline (was looking at the stable version). Thanks for your explanation! Indeed I agree that making this a meta-issue is tiresome with low return.

Just one more question before closing this issue: will scikit-learn accept PRs for these minor fixes in docstrings, and if so at what scale (i.e., 1 PR per class/per file/per module)?

Labels: Needs Triage
DOC a spefic docstring guide for scikit-learn

When I was contributing to scikit-learn, what often confuses me is how to write docstrings. For instance, should I use backticks or double backticks for inline codes? Should I make a line break between parameters or not? etc.

Asides from these details that are only visible in codes, some inconsistencies exist in the public API that are visible to general users. For instance, some short summaries end with period while some do not; descriptions of parameter types are inconsistent; some string literals and True/False are considered inline codes and enclosed in backticks while others are not; etc.

IMHO, a specific docstring guide would greatly help improve consistency. Indeed [PEP257](https://peps.python.org/pep-0257/) already documents some semantics and conventions for docstrings, it is far too general for a project of this scale. Some other projects indeed have docstring guides (e.g., [pandas docstring guide](https://pandas.pydata.org/docs/development/contributing_docstring.html)).

*I am aware that this will require significant job and is not of that great importance so it is completely fine if maintainers don't accept this proposal.*

COMMENT:
We definitely wouldn't mind every now and then such a PR. One PR per module or something maybe. Not too small, not too large.

Labels: Needs Triage
DOC a spefic docstring guide for scikit-learn

When I was contributing to scikit-learn, what often confuses me is how to write docstrings. For instance, should I use backticks or double backticks for inline codes? Should I make a line break between parameters or not? etc.

Asides from these details that are only visible in codes, some inconsistencies exist in the public API that are visible to general users. For instance, some short summaries end with period while some do not; descriptions of parameter types are inconsistent; some string literals and True/False are considered inline codes and enclosed in backticks while others are not; etc.

IMHO, a specific docstring guide would greatly help improve consistency. Indeed [PEP257](https://peps.python.org/pep-0257/) already documents some semantics and conventions for docstrings, it is far too general for a project of this scale. Some other projects indeed have docstring guides (e.g., [pandas docstring guide](https://pandas.pydata.org/docs/development/contributing_docstring.html)).

*I am aware that this will require significant job and is not of that great importance so it is completely fine if maintainers don't accept this proposal.*

COMMENT:
Okay thanks for the reply! Closing now.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5341371822)** (Jun 22, 2023)

COMMENT:
The hash of the scipy package downloaded did not match. I assume that it could only be corrupted due the downloading. 

I would expect this PR to auto close. We can still manually check the hash of those files.

Labels: Needs Triage
⚠️ CI failed on Wheel builder ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/5341371822)** (Jun 22, 2023)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/5352632123) on Jun 23, 2023

Labels: Needs Triage
Pipeline doc references inexistent example

https://github.com/scikit-learn/scikit-learn/blob/364c77e047ca08a95862becf40a04fe9d4cd2c98/sklearn/pipeline.py#L65

> parameter name separated by a `'__'`, as in the example below

There is no example below that shows that technique.

COMMENT:
Indeed we could add a small liner to show how to set a parameter

Labels: Documentation, good first issue
Pipeline doc references inexistent example

https://github.com/scikit-learn/scikit-learn/blob/364c77e047ca08a95862becf40a04fe9d4cd2c98/sklearn/pipeline.py#L65

> parameter name separated by a `'__'`, as in the example below

There is no example below that shows that technique.

COMMENT:
We can also reference an example like `plot_digits_pipe.py` which already has the syntax maybe?

Labels: Documentation, good first issue
Pipeline doc references inexistent example

https://github.com/scikit-learn/scikit-learn/blob/364c77e047ca08a95862becf40a04fe9d4cd2c98/sklearn/pipeline.py#L65

> parameter name separated by a `'__'`, as in the example below

There is no example below that shows that technique.

COMMENT:
There is also a nice and simple example in the user guide https://scikit-learn.org/stable/modules/compose.html#nested-parameters

Labels: Documentation, good first issue
Automatic decision tree pruning based on accuracy scores

### Describe the workflow you want to enable

Could the process described in the linked article be automated in the training (fit) function for tree models?
https://scikit-learn.org/stable/auto_examples/tree/plot_cost_complexity_pruning.html#sphx-glr-auto-examples-tree-plot-cost-complexity-pruning-py

I think this would be a nice feature for users that only care about obtaining the least complicated model with the most accuracy.

### Describe your proposed solution

Automate process described in this article: https://scikit-learn.org/stable/auto_examples/tree/plot_cost_complexity_pruning.html#sphx-glr-auto-examples-tree-plot-cost-complexity-pruning-py

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

_No response_

### Additional context

_No response_

COMMENT:
The linked article is already the scikit-documentation and the parameter is therefore available to prune trees.

Labels: New Feature, Needs Triage
ArrayAPI: `isdtype` improper comparison to set

### Describe the bug

The newly introduced `sklearn.utils._array_api.isdtype` is comparing types with respect to defined sets.

See here https://github.com/scikit-learn/scikit-learn/blob/cb233674ddffeb1f75f63309f94e4f90d0a2bdf8/sklearn/utils/_array_api.py#L92

This is not working as NumPy's dtype object is "tricky".

### Steps/Code to Reproduce

```python
>>> np.float32 in {np.float64, np.float32}
False
>>> np.float32 in [np.float64, np.float32]
True
```

Because

```python
>>> np.float32 is np.dtype(np.float32)
False
>>> np.float32 == np.dtype(np.float32)
True
```

### Expected Results

The check should be more robust. I suggest using directly `array_api_compat.xp.isdtype` (or vendoring it).

### Actual Results

N/A

### Versions

```shell
On main
```

cc @thomasjpfan

COMMENT:
`sklearn.utils._array_api.isdtype` was not designed to be used with NumPy directly. It was designed to be only used through `_NumPyAPIWrapper` or `_ArrayAPIWrapper`.

When using the `_NumPyAPIWrapper`, the types are converted to the dtype objects:

https://github.com/scikit-learn/scikit-learn/blob/cb233674ddffeb1f75f63309f94e4f90d0a2bdf8/sklearn/utils/_array_api.py#L234-L236

In this sense, everything being compared in `sklearn.utils._array_api.isdtype` is a dtype object.

Labels: Enhancement