Talip7/scikit-learn-issues-multilabel huggingface dataset:
Unexpected behavior of the HTML repr of meta-estimators

Here's a list of some unexpected behaviors of the HTML repr of meta-estimators
- `Pipeline` doesn't display its named steps

  <img width="164" height="95" alt="Image" src="https://github.com/user-attachments/assets/c368188d-544f-4bb1-bfeb-d76490f5146a" />

  This was maybe intentional ? In comparison `FeatureUnion` does for instance

  <img width="282" height="91" alt="Image" src="https://github.com/user-attachments/assets/2a6ded8c-d148-4852-a03c-0a88c1b8bc49" />

- a `Pipeline` in a meta-estimator doesn't render properly; it doesn't have the dashed border
  
  <img width="186" height="120" alt="Image" src="https://github.com/user-attachments/assets/471ce468-8597-4fbc-b718-870c4f11a1fd" />

  Another meta-estimator renders properly

  <img width="294" height="116" alt="Image" src="https://github.com/user-attachments/assets/cb467dcd-63c2-4a54-b92a-d6686b3b3bc8" />

- transformers of `ColumnTransformer` are expandable to show the selected columns, but there's no additional info. I think it should be explicit that these are the selected columns.

  <img width="274" height="106" alt="Image" src="https://github.com/user-attachments/assets/e44d47fb-c784-4631-9a73-3d274671430e" />

  Note that this could be fixed by https://github.com/scikit-learn/scikit-learn/pull/31937

- When the inner estimator of a meta-estimator is not a meta-estimator itself, it's expandable but the dropdown is not useful anymore (it's the non-html repr of the estimator basically):

  <img width="169" height="129" alt="Image" src="https://github.com/user-attachments/assets/21723076-ae7e-46e3-8d22-3561aef1b1ec" />

  Now that we have the parameter table, it's not useful anymore to have the additional repr which is redundant and less informative. I'd be in favor of removing the dropdown

- When the inner estimator of a meta-estimator is a meta-estimator itself, it's expandable but sometimes there's no dropdown or the dropdown is the non-html repr of the meta-estimator, and there's no parameter table.

  <img width="178" height="121" alt="Image" src="https://github.com/user-attachments/assets/4fbdb1fa-8f5e-4d32-9bd2-56bc4e89d891" />

  <img width="392" height="143" alt="Image" src="https://github.com/user-attachments/assets/1294de22-afcb-49c3-9256-b0cda06f352a" />

  I think that it should display the parameter table instead in both cases

COMMENT:
cc @DeaMariaLeon @glemaitre

Labels: Documentation, frontend
Unexpected behavior of the HTML repr of meta-estimators

Here's a list of some unexpected behaviors of the HTML repr of meta-estimators
- `Pipeline` doesn't display its named steps

  <img width="164" height="95" alt="Image" src="https://github.com/user-attachments/assets/c368188d-544f-4bb1-bfeb-d76490f5146a" />

  This was maybe intentional ? In comparison `FeatureUnion` does for instance

  <img width="282" height="91" alt="Image" src="https://github.com/user-attachments/assets/2a6ded8c-d148-4852-a03c-0a88c1b8bc49" />

- a `Pipeline` in a meta-estimator doesn't render properly; it doesn't have the dashed border
  
  <img width="186" height="120" alt="Image" src="https://github.com/user-attachments/assets/471ce468-8597-4fbc-b718-870c4f11a1fd" />

  Another meta-estimator renders properly

  <img width="294" height="116" alt="Image" src="https://github.com/user-attachments/assets/cb467dcd-63c2-4a54-b92a-d6686b3b3bc8" />

- transformers of `ColumnTransformer` are expandable to show the selected columns, but there's no additional info. I think it should be explicit that these are the selected columns.

  <img width="274" height="106" alt="Image" src="https://github.com/user-attachments/assets/e44d47fb-c784-4631-9a73-3d274671430e" />

  Note that this could be fixed by https://github.com/scikit-learn/scikit-learn/pull/31937

- When the inner estimator of a meta-estimator is not a meta-estimator itself, it's expandable but the dropdown is not useful anymore (it's the non-html repr of the estimator basically):

  <img width="169" height="129" alt="Image" src="https://github.com/user-attachments/assets/21723076-ae7e-46e3-8d22-3561aef1b1ec" />

  Now that we have the parameter table, it's not useful anymore to have the additional repr which is redundant and less informative. I'd be in favor of removing the dropdown

- When the inner estimator of a meta-estimator is a meta-estimator itself, it's expandable but sometimes there's no dropdown or the dropdown is the non-html repr of the meta-estimator, and there's no parameter table.

  <img width="178" height="121" alt="Image" src="https://github.com/user-attachments/assets/4fbdb1fa-8f5e-4d32-9bd2-56bc4e89d891" />

  <img width="392" height="143" alt="Image" src="https://github.com/user-attachments/assets/1294de22-afcb-49c3-9256-b0cda06f352a" />

  I think that it should display the parameter table instead in both cases

COMMENT:
The HTML display had bugs before the parameters table addition. But in some cases either Guillaume suggested not to worry about it yet, or he did not find that they were bugs. 

I need to check the dashed border and double check the last one.

Labels: Documentation, frontend
Unexpected behavior of the HTML repr of meta-estimators

Here's a list of some unexpected behaviors of the HTML repr of meta-estimators
- `Pipeline` doesn't display its named steps

  <img width="164" height="95" alt="Image" src="https://github.com/user-attachments/assets/c368188d-544f-4bb1-bfeb-d76490f5146a" />

  This was maybe intentional ? In comparison `FeatureUnion` does for instance

  <img width="282" height="91" alt="Image" src="https://github.com/user-attachments/assets/2a6ded8c-d148-4852-a03c-0a88c1b8bc49" />

- a `Pipeline` in a meta-estimator doesn't render properly; it doesn't have the dashed border
  
  <img width="186" height="120" alt="Image" src="https://github.com/user-attachments/assets/471ce468-8597-4fbc-b718-870c4f11a1fd" />

  Another meta-estimator renders properly

  <img width="294" height="116" alt="Image" src="https://github.com/user-attachments/assets/cb467dcd-63c2-4a54-b92a-d6686b3b3bc8" />

- transformers of `ColumnTransformer` are expandable to show the selected columns, but there's no additional info. I think it should be explicit that these are the selected columns.

  <img width="274" height="106" alt="Image" src="https://github.com/user-attachments/assets/e44d47fb-c784-4631-9a73-3d274671430e" />

  Note that this could be fixed by https://github.com/scikit-learn/scikit-learn/pull/31937

- When the inner estimator of a meta-estimator is not a meta-estimator itself, it's expandable but the dropdown is not useful anymore (it's the non-html repr of the estimator basically):

  <img width="169" height="129" alt="Image" src="https://github.com/user-attachments/assets/21723076-ae7e-46e3-8d22-3561aef1b1ec" />

  Now that we have the parameter table, it's not useful anymore to have the additional repr which is redundant and less informative. I'd be in favor of removing the dropdown

- When the inner estimator of a meta-estimator is a meta-estimator itself, it's expandable but sometimes there's no dropdown or the dropdown is the non-html repr of the meta-estimator, and there's no parameter table.

  <img width="178" height="121" alt="Image" src="https://github.com/user-attachments/assets/4fbdb1fa-8f5e-4d32-9bd2-56bc4e89d891" />

  <img width="392" height="143" alt="Image" src="https://github.com/user-attachments/assets/1294de22-afcb-49c3-9256-b0cda06f352a" />

  I think that it should display the parameter table instead in both cases

COMMENT:
Indeed, we saw those issues before but planned to do it after the work on the parameters. So it is probably a good time to organize how to sort each issue. @DeaMariaLeon is going to look at it and break down into pull-requests the different points mentioned earlier.

We can discussed here what we expect as behaviour if it is not straightforward.

Labels: Documentation, frontend
Unexpected behavior of the HTML repr of meta-estimators

Here's a list of some unexpected behaviors of the HTML repr of meta-estimators
- `Pipeline` doesn't display its named steps

  <img width="164" height="95" alt="Image" src="https://github.com/user-attachments/assets/c368188d-544f-4bb1-bfeb-d76490f5146a" />

  This was maybe intentional ? In comparison `FeatureUnion` does for instance

  <img width="282" height="91" alt="Image" src="https://github.com/user-attachments/assets/2a6ded8c-d148-4852-a03c-0a88c1b8bc49" />

- a `Pipeline` in a meta-estimator doesn't render properly; it doesn't have the dashed border
  
  <img width="186" height="120" alt="Image" src="https://github.com/user-attachments/assets/471ce468-8597-4fbc-b718-870c4f11a1fd" />

  Another meta-estimator renders properly

  <img width="294" height="116" alt="Image" src="https://github.com/user-attachments/assets/cb467dcd-63c2-4a54-b92a-d6686b3b3bc8" />

- transformers of `ColumnTransformer` are expandable to show the selected columns, but there's no additional info. I think it should be explicit that these are the selected columns.

  <img width="274" height="106" alt="Image" src="https://github.com/user-attachments/assets/e44d47fb-c784-4631-9a73-3d274671430e" />

  Note that this could be fixed by https://github.com/scikit-learn/scikit-learn/pull/31937

- When the inner estimator of a meta-estimator is not a meta-estimator itself, it's expandable but the dropdown is not useful anymore (it's the non-html repr of the estimator basically):

  <img width="169" height="129" alt="Image" src="https://github.com/user-attachments/assets/21723076-ae7e-46e3-8d22-3561aef1b1ec" />

  Now that we have the parameter table, it's not useful anymore to have the additional repr which is redundant and less informative. I'd be in favor of removing the dropdown

- When the inner estimator of a meta-estimator is a meta-estimator itself, it's expandable but sometimes there's no dropdown or the dropdown is the non-html repr of the meta-estimator, and there's no parameter table.

  <img width="178" height="121" alt="Image" src="https://github.com/user-attachments/assets/4fbdb1fa-8f5e-4d32-9bd2-56bc4e89d891" />

  <img width="392" height="143" alt="Image" src="https://github.com/user-attachments/assets/1294de22-afcb-49c3-9256-b0cda06f352a" />

  I think that it should display the parameter table instead in both cases

COMMENT:
This problem https://github.com/scikit-learn/scikit-learn/issues/32146#issuecomment-3450807154 seems to be fixed here https://github.com/scikit-learn/scikit-learn/pull/31937
At least it works correctly for me on jupyter notebooks and vscode jupyter plugin.

Labels: Documentation, frontend
New min dependencies broke the doc build

We didn't run a dock build before merging https://github.com/scikit-learn/scikit-learn/pull/31656 which bumps min dependencies, and it broke the CI, see https://app.circleci.com/pipelines/github/scikit-learn/scikit-learn/70723/workflows/2064650c-116a-405d-9b1d-9cd469b8804f/jobs/317740.

cc/ @GaetandeCast @ogrisel

COMMENT:
Seems related to `matplotlib.axes.Axes.fill_between` which was already causing issues on the CI for #31656 yesterday, before upgrading the min requirement from 3.6.0 to 3.6.1 for matplotlib.

Labels: Build / CI, Blocker
New min dependencies broke the doc build

We didn't run a dock build before merging https://github.com/scikit-learn/scikit-learn/pull/31656 which bumps min dependencies, and it broke the CI, see https://app.circleci.com/pipelines/github/scikit-learn/scikit-learn/70723/workflows/2064650c-116a-405d-9b1d-9cd469b8804f/jobs/317740.

cc/ @GaetandeCast @ogrisel

COMMENT:
Indeed it seems related but it's not exactly the same error. Maybe there were 2 bugs that were fixed in different matplotlib releases. Let me try with more recent versions

Labels: Build / CI, Blocker
Tree module - Broken test: test fails when changing random_state=0 to =1

In the test `tree/tests/test_tree.py::test_regression_tree_missing_values_toy`, in this [line](https://github.com/scikit-learn/scikit-learn/blob/0033630cd35d5945ea8c1b5beff6efe9583cd523/sklearn/tree/tests/test_tree.py#L2695C1-L2696C1):

```
    tree = Tree(criterion=criterion, random_state=0).fit(X, y)
```

if you change `random_state=0` to `random_state=1` all the tests with `Tree` being `ExtraTreeRegressor` fails.

It is completly logical when you look at the code: when there are missing values the random split (which is what `ExtraTreeRegressor`  does) *randomly* put them to the left or the right. The *randomly* part here is not compatible the test logic. It's a lucky 1/16 chance in the choice of the random_seed that made this test passed until now (I ran the test with 1000 seeds, and it's indeed 1/16, because it's tested on 4 arrays, hence proba = 1/2^4).

I'm willing to open a PR to fix this. My suggestion is to stop running this test on `ExtraTreeRegressor`, there are alreay many tests on `ExtraTreeRegressor`s and the issues linked in the docstring of this test aren't mentionning `ExtraTreeRegressor` anywhere.

COMMENT:
Edit: I checked git blame to see when this was introduced. It was introduced in this [commit](https://github.com/scikit-learn/scikit-learn/commit/27a903bce48bcd46af0bfdab966e4edc063bd99b) by changing the lines:

```python
    # Note: the impurity matches after the first split only on greedy trees
    if Tree is DecisionTreeRegressor:
        # Check the impurity match after the first split
        assert_allclose(tree.tree_.impurity[:2], tree_ref.tree_.impurity[:2])
```

To:


```python
    # Check the impurity match after the first split
    assert_allclose(tree.tree_.impurity[:2], tree_ref.tree_.impurity[:2])
```

The comment *"Note: the impurity matches after the first split only on greedy trees"* is indeed right, so let's revert back those changes.

Labels: module:tree
Tree module - Broken test: test fails when changing random_state=0 to =1

In the test `tree/tests/test_tree.py::test_regression_tree_missing_values_toy`, in this [line](https://github.com/scikit-learn/scikit-learn/blob/0033630cd35d5945ea8c1b5beff6efe9583cd523/sklearn/tree/tests/test_tree.py#L2695C1-L2696C1):

```
    tree = Tree(criterion=criterion, random_state=0).fit(X, y)
```

if you change `random_state=0` to `random_state=1` all the tests with `Tree` being `ExtraTreeRegressor` fails.

It is completly logical when you look at the code: when there are missing values the random split (which is what `ExtraTreeRegressor`  does) *randomly* put them to the left or the right. The *randomly* part here is not compatible the test logic. It's a lucky 1/16 chance in the choice of the random_seed that made this test passed until now (I ran the test with 1000 seeds, and it's indeed 1/16, because it's tested on 4 arrays, hence proba = 1/2^4).

I'm willing to open a PR to fix this. My suggestion is to stop running this test on `ExtraTreeRegressor`, there are alreay many tests on `ExtraTreeRegressor`s and the issues linked in the docstring of this test aren't mentionning `ExtraTreeRegressor` anywhere.

COMMENT:
Ping @adam2392: I think you're the author of both the initial lines, and the change that removed the if.

Labels: module:tree
Tree module - Broken test: test fails when changing random_state=0 to =1

In the test `tree/tests/test_tree.py::test_regression_tree_missing_values_toy`, in this [line](https://github.com/scikit-learn/scikit-learn/blob/0033630cd35d5945ea8c1b5beff6efe9583cd523/sklearn/tree/tests/test_tree.py#L2695C1-L2696C1):

```
    tree = Tree(criterion=criterion, random_state=0).fit(X, y)
```

if you change `random_state=0` to `random_state=1` all the tests with `Tree` being `ExtraTreeRegressor` fails.

It is completly logical when you look at the code: when there are missing values the random split (which is what `ExtraTreeRegressor`  does) *randomly* put them to the left or the right. The *randomly* part here is not compatible the test logic. It's a lucky 1/16 chance in the choice of the random_seed that made this test passed until now (I ran the test with 1000 seeds, and it's indeed 1/16, because it's tested on 4 arrays, hence proba = 1/2^4).

I'm willing to open a PR to fix this. My suggestion is to stop running this test on `ExtraTreeRegressor`, there are alreay many tests on `ExtraTreeRegressor`s and the issues linked in the docstring of this test aren't mentionning `ExtraTreeRegressor` anywhere.

COMMENT:
I opened a PR :)

Labels: module:tree
⚠️ CI failed on Wheel builder (last failure: Sep 07, 2025) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/17523435997)** (Sep 07, 2025)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/17539093743) on Sep 08, 2025

Labels: Needs Triage
"Improve documentation on FeatureUnion behavior with polars DataFrame output causing duplicate column names"

### Describe the issue linked to the documentation

The current documentation for FeatureUnion describes its behavior with pandas DataFrames but does not mention how it behaves when used with polars DataFrames. Specifically, FeatureUnion concatenates outputs of its transformers before the set_output wrapper renames columns based on get_feature_names_out. This works fine with pandas but causes issues with polars since polars does not allow creating a DataFrame with duplicate column names. This leads to errors when using FeatureUnion with polars outputs.

### Suggest a potential alternative/fix

The documentation should mention the behavior difference when using FeatureUnion with polars DataFrames, specifically that concatenation occurs before column renaming. This can cause duplicate column names errors in polars.

It would be helpful to add a warning or note about this limitation, and suggest possible workarounds, such as manually renaming columns or converting to pandas DataFrame before using FeatureUnion.

Including a minimal example demonstrating the issue and how to avoid it would further improve clarity for users.

COMMENT:
Thanks for raising this issue! I'll take a look and get back to you

Labels: Documentation, Needs Triage
"Improve documentation on FeatureUnion behavior with polars DataFrame output causing duplicate column names"

### Describe the issue linked to the documentation

The current documentation for FeatureUnion describes its behavior with pandas DataFrames but does not mention how it behaves when used with polars DataFrames. Specifically, FeatureUnion concatenates outputs of its transformers before the set_output wrapper renames columns based on get_feature_names_out. This works fine with pandas but causes issues with polars since polars does not allow creating a DataFrame with duplicate column names. This leads to errors when using FeatureUnion with polars outputs.

### Suggest a potential alternative/fix

The documentation should mention the behavior difference when using FeatureUnion with polars DataFrames, specifically that concatenation occurs before column renaming. This can cause duplicate column names errors in polars.

It would be helpful to add a warning or note about this limitation, and suggest possible workarounds, such as manually renaming columns or converting to pandas DataFrame before using FeatureUnion.

Including a minimal example demonstrating the issue and how to avoid it would further improve clarity for users.

COMMENT:
"Hi, I would like to work on this issue.

I've read through the description, and my understanding is that I need to add a warning note to the FeatureUnion documentation regarding its behavior with Polars DataFrames causing duplicate column names.

My plan is to locate the docstring for FeatureUnion and add the warning, along with a minimal code example to demonstrate the issue and a potential workaround, as suggested.

Could you please assign this to me?" 🙌❤️

Labels: Documentation, Needs Triage
"Improve documentation on FeatureUnion behavior with polars DataFrame output causing duplicate column names"

### Describe the issue linked to the documentation

The current documentation for FeatureUnion describes its behavior with pandas DataFrames but does not mention how it behaves when used with polars DataFrames. Specifically, FeatureUnion concatenates outputs of its transformers before the set_output wrapper renames columns based on get_feature_names_out. This works fine with pandas but causes issues with polars since polars does not allow creating a DataFrame with duplicate column names. This leads to errors when using FeatureUnion with polars outputs.

### Suggest a potential alternative/fix

The documentation should mention the behavior difference when using FeatureUnion with polars DataFrames, specifically that concatenation occurs before column renaming. This can cause duplicate column names errors in polars.

It would be helpful to add a warning or note about this limitation, and suggest possible workarounds, such as manually renaming columns or converting to pandas DataFrame before using FeatureUnion.

Including a minimal example demonstrating the issue and how to avoid it would further improve clarity for users.

COMMENT:
/take

Labels: Documentation, Needs Triage
"Improve documentation on FeatureUnion behavior with polars DataFrame output causing duplicate column names"

### Describe the issue linked to the documentation

The current documentation for FeatureUnion describes its behavior with pandas DataFrames but does not mention how it behaves when used with polars DataFrames. Specifically, FeatureUnion concatenates outputs of its transformers before the set_output wrapper renames columns based on get_feature_names_out. This works fine with pandas but causes issues with polars since polars does not allow creating a DataFrame with duplicate column names. This leads to errors when using FeatureUnion with polars outputs.

### Suggest a potential alternative/fix

The documentation should mention the behavior difference when using FeatureUnion with polars DataFrames, specifically that concatenation occurs before column renaming. This can cause duplicate column names errors in polars.

It would be helpful to add a warning or note about this limitation, and suggest possible workarounds, such as manually renaming columns or converting to pandas DataFrame before using FeatureUnion.

Including a minimal example demonstrating the issue and how to avoid it would further improve clarity for users.

COMMENT:
Thanks after completing I will update

Labels: Documentation, Needs Triage
"Improve documentation on FeatureUnion behavior with polars DataFrame output causing duplicate column names"

### Describe the issue linked to the documentation

The current documentation for FeatureUnion describes its behavior with pandas DataFrames but does not mention how it behaves when used with polars DataFrames. Specifically, FeatureUnion concatenates outputs of its transformers before the set_output wrapper renames columns based on get_feature_names_out. This works fine with pandas but causes issues with polars since polars does not allow creating a DataFrame with duplicate column names. This leads to errors when using FeatureUnion with polars outputs.

### Suggest a potential alternative/fix

The documentation should mention the behavior difference when using FeatureUnion with polars DataFrames, specifically that concatenation occurs before column renaming. This can cause duplicate column names errors in polars.

It would be helpful to add a warning or note about this limitation, and suggest possible workarounds, such as manually renaming columns or converting to pandas DataFrame before using FeatureUnion.

Including a minimal example demonstrating the issue and how to avoid it would further improve clarity for users.

COMMENT:
Great, thanks @Ravichandranayakar
Looking forward to your update. Let us know if you run into any questions.

Labels: Documentation, Needs Triage