Talip7/scikit-learn-issues-multilabel huggingface dataset:
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
I would rather keep having one option where downloading pyodide distro is not required, for folks with lower bandwidth, but I don't mind which solution that uses (marimo or binder, or anything else)

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
Maybe this is related to #24878, where we discussed that turning some examples into more interactive demos would be interesting, as long as it doesn't bring extra maintenance cost on our side or make us depend on external maintenance efforts.

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
Yeah you can build demos like that with marimo too, all from WASM. Will explore sphinx-gallery right now.

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
If you want a suggestion, I've always thought that the [Ablation study of the outlier detection example](https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_outlier_detection_bench.html#ablation-study) could really benefit from becoming interactive.

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
Am working on this now: https://github.com/koaning/sphinx-marimo

Let me know if there's any feedback!

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
Whenever you're happy with your plugin, you could send a PR here for us to see how it looks and feels.

Labels: Documentation, RFC
marimo for WASM notebooks

### Describe the issue linked to the documentation

I couldn't help but notice that the docs have Jupyter lite and binder. The binder links seem to fail at the moment and while the Jupyterlite seems to run ok ... would folks maybe be open to marimo notebooks for this as an alternative? 

<img width="1442" height="787" alt="Image" src="https://github.com/user-attachments/assets/95f7b5ae-6bc0-4360-95ff-69c4c84abdbf" />

The examples I've tried sofar seem to run totally fine in our WASM environment as well as on [molab](https://molab.marimo.io/notebooks). I imagine that there's a preference to host the examples on a static page though. 

In terms of work, we can accept the `.ipynb` formatted files already so the main thing would be to add a link to the docs. 

@adrinjalali @ArturoAmorQ would you be interested in this?

### Suggest a potential alternative/fix

There's also demos I can come up with that use widgets and sliders, but I would imagine that it's preferable to ensure consistency across notebooks above more fancy UI features.

COMMENT:
<img width="1101" height="770" alt="Image" src="https://github.com/user-attachments/assets/2662661d-dae5-4a18-a9ba-12da909fc444" />

work in progress ...

Labels: Documentation, RFC
Target value described as "average" instead of "median" in sklearn.datasets.fetch_california_housing documentation

### Describe the issue linked to the documentation

Returned target is described as
"Each value corresponds to the average house value in units of 100,000."

In 8.2 of the User Guide the return value is described as median house value, as well as the Kaggle Data Card.

### Suggest a potential alternative/fix

The word "average" should be replaced with "median"

COMMENT:
I would like to work on this issue

Labels: Easy, Documentation, module:datasets
RFC Consider changing the output of transformer returning sparse matrix to sparse array

Currently, we have a couple of transformer that returns sparse matrix. With the work on array-api in the ecosystem, it could actually be annoying because matrix are not array and might not be supported.

To illustrate with an example, let's look at:

```python
from scipy.spatial.distance import pdist
from sklearn.feature_extraction.text import TfidfVectorizer

text = ['Example Category', 'Random Word']
transformer = TfidfVectorizer()
vector = transformer.fit_transform(text)
pdist(vector.todense())
```

It will fail with the following error

```pytb
TypeError: Inputs of type `numpy.matrix` are not supported.
```

Because `.todense()` will convert from a sparse matrix to a sparse array and that nowadays scipy will dipatch using the array-api.

If instead, we were returning a sparse array, `.todense()` would provide a NumPy array and we would be fine.

So a broad question is: do we want to anticipate and send a `FutureWarning` and change the type of output and requesting people to make an explicit conversion to a sparse matrix if they want to keep the previous behaviour?

COMMENT:
Actually, @GaelVaroquaux mentioned to me IRL that leveraging the `.set_output` could be a nice way: `default` could switch from sparse matrix to array while we could provide `.set_output(transform="sparse-matrix")` for backward compatibility.

Labels: RFC
RFC Consider changing the output of transformer returning sparse matrix to sparse array

Currently, we have a couple of transformer that returns sparse matrix. With the work on array-api in the ecosystem, it could actually be annoying because matrix are not array and might not be supported.

To illustrate with an example, let's look at:

```python
from scipy.spatial.distance import pdist
from sklearn.feature_extraction.text import TfidfVectorizer

text = ['Example Category', 'Random Word']
transformer = TfidfVectorizer()
vector = transformer.fit_transform(text)
pdist(vector.todense())
```

It will fail with the following error

```pytb
TypeError: Inputs of type `numpy.matrix` are not supported.
```

Because `.todense()` will convert from a sparse matrix to a sparse array and that nowadays scipy will dipatch using the array-api.

If instead, we were returning a sparse array, `.todense()` would provide a NumPy array and we would be fine.

So a broad question is: do we want to anticipate and send a `FutureWarning` and change the type of output and requesting people to make an explicit conversion to a sparse matrix if they want to keep the previous behaviour?

COMMENT:
Hey @glemaitre,

One thing I’m wondering: if we move to sparse arrays by default, won’t this break code that relies on `scipy.sparse.csr_matrix`? I understand the idea of adding a `FutureWarning`, but how much time do you usually give users to migrate before making the breaking switch?

Labels: RFC
RFC Consider changing the output of transformer returning sparse matrix to sparse array

Currently, we have a couple of transformer that returns sparse matrix. With the work on array-api in the ecosystem, it could actually be annoying because matrix are not array and might not be supported.

To illustrate with an example, let's look at:

```python
from scipy.spatial.distance import pdist
from sklearn.feature_extraction.text import TfidfVectorizer

text = ['Example Category', 'Random Word']
transformer = TfidfVectorizer()
vector = transformer.fit_transform(text)
pdist(vector.todense())
```

It will fail with the following error

```pytb
TypeError: Inputs of type `numpy.matrix` are not supported.
```

Because `.todense()` will convert from a sparse matrix to a sparse array and that nowadays scipy will dipatch using the array-api.

If instead, we were returning a sparse array, `.todense()` would provide a NumPy array and we would be fine.

So a broad question is: do we want to anticipate and send a `FutureWarning` and change the type of output and requesting people to make an explicit conversion to a sparse matrix if they want to keep the previous behaviour?

COMMENT:
We give two releases which is almost one year. In short, we are going to request people to do the following:

```python
transformer = TfidfVectorizer().set_output(transform="sparse-matrix")
```

if they don't want to change the rest of the code.

Labels: RFC
RFC Consider changing the output of transformer returning sparse matrix to sparse array

Currently, we have a couple of transformer that returns sparse matrix. With the work on array-api in the ecosystem, it could actually be annoying because matrix are not array and might not be supported.

To illustrate with an example, let's look at:

```python
from scipy.spatial.distance import pdist
from sklearn.feature_extraction.text import TfidfVectorizer

text = ['Example Category', 'Random Word']
transformer = TfidfVectorizer()
vector = transformer.fit_transform(text)
pdist(vector.todense())
```

It will fail with the following error

```pytb
TypeError: Inputs of type `numpy.matrix` are not supported.
```

Because `.todense()` will convert from a sparse matrix to a sparse array and that nowadays scipy will dipatch using the array-api.

If instead, we were returning a sparse array, `.todense()` would provide a NumPy array and we would be fine.

So a broad question is: do we want to anticipate and send a `FutureWarning` and change the type of output and requesting people to make an explicit conversion to a sparse matrix if they want to keep the previous behaviour?

COMMENT:
About the ability to switch between sparse array and sparse matrix output, this seems related to https://github.com/scikit-learn/scikit-learn/pull/31177, that is taking the approach to use our config for this.

About the snippet, I guess using `pdist(vector.toarray())` would be a work-around. Not sure how much this can be considered a regression in scipy 1.16 ...

Labels: RFC
⚠️ CI failed on macOS.pylatest_conda_forge_mkl_no_openmp (last failure: Sep 18, 2025) ⚠️

**CI failed on [macOS.pylatest_conda_forge_mkl_no_openmp](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80124&view=logs&j=8b4d29c4-7356-5617-94d6-7bef17a56394)** (Sep 18, 2025)
- test_fit_transform[76]

COMMENT:
Same failure as https://github.com/scikit-learn/scikit-learn/issues/32184

Labels: Bug, module:test-suite
⚠️ CI failed on macOS.pylatest_conda_forge_mkl_no_openmp (last failure: Sep 18, 2025) ⚠️

**CI failed on [macOS.pylatest_conda_forge_mkl_no_openmp](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80124&view=logs&j=8b4d29c4-7356-5617-94d6-7bef17a56394)** (Sep 18, 2025)
- test_fit_transform[76]

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80574&view=logs&j=8b4d29c4-7356-5617-94d6-7bef17a56394) on Oct 01, 2025

Labels: Bug, module:test-suite
Missing Python 3.14 in Readme and Pypi

### Describe the issue linked to the documentation

At <https://github.com/scikit-learn/scikit-learn/releases/tag/1.7.2> it is stated that the new release 1.7.2 supports Python 3.14 but neither at <https://pypi.org/project/scikit-learn/> nor in the repo's readme file this is reflected.

Shall I simply add this 3.14 line to the `pyproject.toml` file or is there a reason for omitting this I did not see?

### Suggest a potential alternative/fix

_No response_

COMMENT:
@ChVeen sure, please make sure there are no other places where 3.14 needs to be mentioned as well.

Labels: Documentation
Missing Python 3.14 in Readme and Pypi

### Describe the issue linked to the documentation

At <https://github.com/scikit-learn/scikit-learn/releases/tag/1.7.2> it is stated that the new release 1.7.2 supports Python 3.14 but neither at <https://pypi.org/project/scikit-learn/> nor in the repo's readme file this is reflected.

Shall I simply add this 3.14 line to the `pyproject.toml` file or is there a reason for omitting this I did not see?

### Suggest a potential alternative/fix

_No response_

COMMENT:
@adrinjalali Fired a PR, but the changes in the repo will not change the metadata at <https://pypi.org/project/scikit-learn/>.
For this, someone with appropriate access rights needs to change it there (maintainer?, member?)...

Labels: Documentation
Missing Python 3.14 in Readme and Pypi

### Describe the issue linked to the documentation

At <https://github.com/scikit-learn/scikit-learn/releases/tag/1.7.2> it is stated that the new release 1.7.2 supports Python 3.14 but neither at <https://pypi.org/project/scikit-learn/> nor in the repo's readme file this is reflected.

Shall I simply add this 3.14 line to the `pyproject.toml` file or is there a reason for omitting this I did not see?

### Suggest a potential alternative/fix

_No response_

COMMENT:
pypi will change with the next release. We don't need to do anything there.

Labels: Documentation
RFC: Proposal for autoclose option for non-compliant PRs

Following up on the discussion in #31679 about low-effort contributions (like ai-generated with low human supervision), @lucyleeow and me worked out an idea: We would like to propose introducing an autoclose option for PRs that gets triggered when setting an "autoclose" label that can be removed if the PR is improved.

The idea is to provide a structured way to handle PRs that don't yet meet our contribution standards and facilitate the reviewing process. This will be transparent and fair for new contributors.

**Suggested process**
1. A contributor opens a PR that looks low-effort, fly-by, not supervised ai-generated, or otherwise not yet ready for review.
2. A reviewer sets an "autoclose" label. This would automatically add a polite, standardised comment explaining:
    - The PR will be autoclosed after _n_ weeks (e.g. _4_).
    - A list of common quality issues (similar to what we used in #31822) that outlines what the contributor needs to address in order to avoid the PR being autoclosed (can contain links to the docs and the FAQs where we explain those things in detail).
    - An encouragement to comment on the PR and ping the person who set the "autoclose" once they believe they have met the quality standards and addressed the issues, or when they struggle or need clarification in a specific point.
    - A note that reviewer time is limited and we cannot provide detailed guidance.
3. Possible outcomes:
    - If the author doesn't respond or pushes commits that don't address the issues → PR is autoclosed after the timeout.
    - If the author states problems → reviewers can offer guidance at their discretion, based on capacity and fit.
    - If the author makes the required improvements:
        - ideally either the reviewer who set the label or the person on triage removes the label, which stops the autoclose action, and the PR can be reviewed and move forward as usual
        - in some cases (hopefully not too often) we might miss the deadline and the author would need to open a new PR (that's a downside on applying an the autoclose policy)

**Benefits**
- For maintainers: avoids the implicit obligation to fully review low-quality PRs and allows to focus on genuine contributions.
- For contributors: sets clear expectations from the start, and thoughtful contributors benefit because reviewers have more time for their PRs. 
- For the project: helps keep the PR queue manageable and signals that quality and preparation are expected.

The key point is that this wouldn't reduce our support for new contributors. It only shifts the expectation: authors are responsible for bringing their PRs to a reviewable state, and reviewers can decide how much help to give along the way.

**Technical feasibility**
This should be achievable with a GitHub Action, similar to those used in many open source projects to autoclose stale issues or PRs, but triggered by a label instead of inactivity.

COMMENT:
ping @scikit-learn/core-devs @scikit-learn/documentation-team for visibility

Labels: Needs Decision, RFC