Talip7/scikit-learn-issues-multilabel huggingface dataset:
Implement row-wise prediction skipping

### Describe the workflow you want to enable

In lines like:

```python
model.predict_proba(df)
```

I know that certain rows do not need the probability to be predicted. So I would need to:

- Filter the dataframe
- Store the indexes at which I do not want evaluation
- Evaluate the filtered dataframe
- Put back the whole dataframe with the probabilities of the dropped data as -1, NaN or some other reasonable value.

### Describe your proposed solution

I would like to have a `skip_at` argument like:

```python
indexes=numpy.array[1, 20, 40])

probabilities = model.predict_proba(df, skip_at=indexes)
```

Such that probabilities is NaN at 1, 20 and 40 do not get added and **specially** the model does not waste time evaluating the probability there.

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

_No response_

### Additional context

_No response_

COMMENT:
Thank you for the suggestion, @acampove.

It seems like the intention behind `skip_at` is to move the filtering, placeholder insertion, and reintegration logic into `predict_proba` itself, so that users don’t have to handle it manually each time.

While I can see why that would be convenient, it comes with some downsides:

* It adds extra complexity to the method signature and implementation.
* It breaks the standard expectation that `predict_proba` returns a valid class probability for each input sample. I.e., an array of floats in 0, 1 for every row, not `NaN`, -1, etc.
* Most importantly, changing the public API is extremely taxing to end-users.

Since this kind of row filtering is easy to implement externally using [Pandas masks](https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.mask.html), and gives users full control over how to handle skipped entries (e.g. insert `NaN`, -1, or leave them blank), it may be better to keep this logic outside the core API.

If this pattern comes up frequently, a utility function or a short example in the documentation might be a better way to support it without complicating estimator interfaces.

As a result, I’m closing this issue.

Labels: API
Attribute docstring does not show properly when there is a property with the same name

### Describe the issue linked to the documentation

When a @property is documented by a docstring and when the corresponding fitted attribute with the same name is also documented in the docstring of the class, the documentation only displays the first line of the docstring of the @property. The name of the property is also not properly rendered.
For example `estimators_samples_` of `BaggingClassifier` is displayed like this in the documentation:

![Image](https://github.com/user-attachments/assets/e062a3ca-541b-413d-884b-3bc31d1f54a2)

Although its docstring is:

![Image](https://github.com/user-attachments/assets/825ec69d-32b5-44d0-a1dd-39de378e5c93)

And the docstring of the `@property` is:

![Image](https://github.com/user-attachments/assets/72a1a343-aba9-43e3-b53a-67339e5e4689)

This was probably introduced here : #30989 

### Suggest a potential alternative/fix

One solution is to remove the docstring of the property, in which case the docstring of the attribute will be rendered properly. But it would have to be done in all such cases. I discovered it while working on RandomForestClassifier.feature_importances_ that suffers from the same issue.

Cc: @antoinebaker @lesteve What do you think would be the right way to document an attribute coming from a property?

COMMENT:
The same issue exists in other places like `n_features_in_` for `Pipeline`.

I think it makes sense to have the documentation at the `@property` instead of top level docstring. It would also be nice to add a test to `test_docstrings.py` or `test_docstring_parameters.py` to make sure a property is documented only once.

Labels: Documentation
Attribute docstring does not show properly when there is a property with the same name

### Describe the issue linked to the documentation

When a @property is documented by a docstring and when the corresponding fitted attribute with the same name is also documented in the docstring of the class, the documentation only displays the first line of the docstring of the @property. The name of the property is also not properly rendered.
For example `estimators_samples_` of `BaggingClassifier` is displayed like this in the documentation:

![Image](https://github.com/user-attachments/assets/e062a3ca-541b-413d-884b-3bc31d1f54a2)

Although its docstring is:

![Image](https://github.com/user-attachments/assets/825ec69d-32b5-44d0-a1dd-39de378e5c93)

And the docstring of the `@property` is:

![Image](https://github.com/user-attachments/assets/72a1a343-aba9-43e3-b53a-67339e5e4689)

This was probably introduced here : #30989 

### Suggest a potential alternative/fix

One solution is to remove the docstring of the property, in which case the docstring of the attribute will be rendered properly. But it would have to be done in all such cases. I discovered it while working on RandomForestClassifier.feature_importances_ that suffers from the same issue.

Cc: @antoinebaker @lesteve What do you think would be the right way to document an attribute coming from a property?

COMMENT:
Hi @adrinjalali, can I take up this issue?

Labels: Documentation
Attribute docstring does not show properly when there is a property with the same name

### Describe the issue linked to the documentation

When a @property is documented by a docstring and when the corresponding fitted attribute with the same name is also documented in the docstring of the class, the documentation only displays the first line of the docstring of the @property. The name of the property is also not properly rendered.
For example `estimators_samples_` of `BaggingClassifier` is displayed like this in the documentation:

![Image](https://github.com/user-attachments/assets/e062a3ca-541b-413d-884b-3bc31d1f54a2)

Although its docstring is:

![Image](https://github.com/user-attachments/assets/825ec69d-32b5-44d0-a1dd-39de378e5c93)

And the docstring of the `@property` is:

![Image](https://github.com/user-attachments/assets/72a1a343-aba9-43e3-b53a-67339e5e4689)

This was probably introduced here : #30989 

### Suggest a potential alternative/fix

One solution is to remove the docstring of the property, in which case the docstring of the attribute will be rendered properly. But it would have to be done in all such cases. I discovered it while working on RandomForestClassifier.feature_importances_ that suffers from the same issue.

Cc: @antoinebaker @lesteve What do you think would be the right way to document an attribute coming from a property?

COMMENT:
This is not a good first issue @agrawal-prakhar , but if you think you can tackle the issue, sure, go ahead. Please carefully read our contributor guidelines first.

Labels: Documentation
Attribute docstring does not show properly when there is a property with the same name

### Describe the issue linked to the documentation

When a @property is documented by a docstring and when the corresponding fitted attribute with the same name is also documented in the docstring of the class, the documentation only displays the first line of the docstring of the @property. The name of the property is also not properly rendered.
For example `estimators_samples_` of `BaggingClassifier` is displayed like this in the documentation:

![Image](https://github.com/user-attachments/assets/e062a3ca-541b-413d-884b-3bc31d1f54a2)

Although its docstring is:

![Image](https://github.com/user-attachments/assets/825ec69d-32b5-44d0-a1dd-39de378e5c93)

And the docstring of the `@property` is:

![Image](https://github.com/user-attachments/assets/72a1a343-aba9-43e3-b53a-67339e5e4689)

This was probably introduced here : #30989 

### Suggest a potential alternative/fix

One solution is to remove the docstring of the property, in which case the docstring of the attribute will be rendered properly. But it would have to be done in all such cases. I discovered it while working on RandomForestClassifier.feature_importances_ that suffers from the same issue.

Cc: @antoinebaker @lesteve What do you think would be the right way to document an attribute coming from a property?

COMMENT:
> I think it makes sense to have the documentation at the `@property` instead of top level docstring.

Can you explain a bit why? For me it makes more sense to have the documentation in the main docstring, because we document everything there. It also avoids the problem that attributes we document in the main docstring and a properties docstring get rendered differently - which I think isn't useful, the "propertyness" is an implementation detail.

I'm not sure if #30989 caused this. The goal of that PR was to skip documenting properties that are fitted attributes. To avoid having it listed once in the Attributes section and then once again in the Properties section.

The fact that `estimators_samples_` is rendered differently to `estimators_` or `classes_` and uses the docstring from the property makes me think that we need to dive deeper into the way autodoc works. If you inspect the HTML generated it looks different for `estimators_` and `estimators_samples_` - with the HTML for the former looking like it was recognised as something to cross-reference or some such. A bit surprising that the whole part of the docstring gets replaced :-/

<img width="517" height="265" alt="Image" src="https://github.com/user-attachments/assets/58562595-28be-46b2-b717-4d83b3f78631" />

Labels: Documentation
Attribute docstring does not show properly when there is a property with the same name

### Describe the issue linked to the documentation

When a @property is documented by a docstring and when the corresponding fitted attribute with the same name is also documented in the docstring of the class, the documentation only displays the first line of the docstring of the @property. The name of the property is also not properly rendered.
For example `estimators_samples_` of `BaggingClassifier` is displayed like this in the documentation:

![Image](https://github.com/user-attachments/assets/e062a3ca-541b-413d-884b-3bc31d1f54a2)

Although its docstring is:

![Image](https://github.com/user-attachments/assets/825ec69d-32b5-44d0-a1dd-39de378e5c93)

And the docstring of the `@property` is:

![Image](https://github.com/user-attachments/assets/72a1a343-aba9-43e3-b53a-67339e5e4689)

This was probably introduced here : #30989 

### Suggest a potential alternative/fix

One solution is to remove the docstring of the property, in which case the docstring of the attribute will be rendered properly. But it would have to be done in all such cases. I discovered it while working on RandomForestClassifier.feature_importances_ that suffers from the same issue.

Cc: @antoinebaker @lesteve What do you think would be the right way to document an attribute coming from a property?

COMMENT:
A property might or might not have a setter, so to me that makes it different from a simple attribute, therefore sensible to document differently. But I don't have a very strong opinion on this. It's more like, I'd document as a property if it were me, but as long as there's a consistent and "one way to document" the thing exists across the codebase with a test, I'm happy.

Labels: Documentation
scikit-learn API reference on the website not rendering LaTeX correctly

### Describe the bug

On the API reference on the web, formulas are shown as: 

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

Instead of 

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />

(Unless it's expected!)  

### Steps/Code to Reproduce

Please see https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.ElasticNet.html 



### Expected Results

I think the formulas should look like mathematical formulas, not like LaTeX:

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />



### Actual Results

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

### Versions

```shell
All releases on the website
```

COMMENT:
This has been a long discussion where we never came to a conclusion: should we do latex in docstrings or should they be limited to the rst files?

I'd say, in cases where there's already latex syntax in the docstring, I'm happy to have the markers for them to be rendered correctly. This at least is an easy decision. So your PR fixing it is welcome 😊

Labels: Documentation
scikit-learn API reference on the website not rendering LaTeX correctly

### Describe the bug

On the API reference on the web, formulas are shown as: 

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

Instead of 

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />

(Unless it's expected!)  

### Steps/Code to Reproduce

Please see https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.ElasticNet.html 



### Expected Results

I think the formulas should look like mathematical formulas, not like LaTeX:

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />



### Actual Results

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

### Versions

```shell
All releases on the website
```

COMMENT:
I tried something similar in #30322 a while back.

TL;DR: I used raw strings `r"""` in an attempt to render LaTeX properly in the docstrings, but ended up wrestling with `numpydoc` and PEP-8 formatting rules, and it ultimately turned into a dead end.

I eventually agreed with [#30322 (comment)](https://github.com/scikit-learn/scikit-learn/pull/30322#discussion_r1853092000): it's probably best to leave the docstrings as they are and instead include LaTeX formatting in the User Guide.

That said, I do think there's still some useful work that can be done on LaTeX improvement in the User Guide.

My [branch](https://github.com/virchan/scikit-learn/tree/documentation_improvement/latex_linear_model) is still up, so @DeaMariaLeon, feel free to experiment with it if it helps!

Labels: Documentation
scikit-learn API reference on the website not rendering LaTeX correctly

### Describe the bug

On the API reference on the web, formulas are shown as: 

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

Instead of 

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />

(Unless it's expected!)  

### Steps/Code to Reproduce

Please see https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.ElasticNet.html 



### Expected Results

I think the formulas should look like mathematical formulas, not like LaTeX:

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />



### Actual Results

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

### Versions

```shell
All releases on the website
```

COMMENT:
Thank you so much @virchan for sharing what you did and the TL;DR.

Labels: Documentation
scikit-learn API reference on the website not rendering LaTeX correctly

### Describe the bug

On the API reference on the web, formulas are shown as: 

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

Instead of 

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />

(Unless it's expected!)  

### Steps/Code to Reproduce

Please see https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.ElasticNet.html 



### Expected Results

I think the formulas should look like mathematical formulas, not like LaTeX:

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />



### Actual Results

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

### Versions

```shell
All releases on the website
```

COMMENT:
@DeaMariaLeon I think i used towards #31593 instead of fixes #31593, so the issue is not close even after merging automatically, could you please close this issue.

Labels: Documentation
scikit-learn API reference on the website not rendering LaTeX correctly

### Describe the bug

On the API reference on the web, formulas are shown as: 

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

Instead of 

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />

(Unless it's expected!)  

### Steps/Code to Reproduce

Please see https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.ElasticNet.html 



### Expected Results

I think the formulas should look like mathematical formulas, not like LaTeX:

<img width="232" alt="Image" src="https://github.com/user-attachments/assets/8f45c9d9-3ff9-48ae-b904-d6d1286f9f89" />



### Actual Results

`a * ||w||_1 + 0.5 * b * ||w||_2^2`

### Versions

```shell
All releases on the website
```

COMMENT:
@dbXD320 I think using "towards" was correct, as this issue refers to the whole website. The file I mention here was **one** example only. 
So, I'm leaving this issue open unless a core developer (a member of the scikit-learn team) wants to close it.

Labels: Documentation
Can't create exe-file with this module

### Describe the bug

```py
from sklearn.neighbors import NearestNeighbors

--hidden-import=sklearn.neighbors

File "C:\Python\lib\site-packages\PyInstaller\lib\modulegraph\modulegraph.py", line 2537, in _scan_bytecode
    for inst in util.iterate_instructions(module_code_object):
  File "C:\Python\lib\site-packages\PyInstaller\lib\modulegraph\util.py", line 13, in iterate_instructions
    yield from (i for i in dis.get_instructions(code_object) if i.opname != "EXTENDED_ARG")
  File "C:\Python\lib\site-packages\PyInstaller\lib\modulegraph\util.py", line 13, in <genexpr>
    yield from (i for i in dis.get_instructions(code_object) if i.opname != "EXTENDED_ARG")
  File "C:\Python\lib\dis.py", line 338, in _get_instructions_bytes
    argval, argrepr = _get_const_info(arg, constants)
  File "C:\Python\lib\dis.py", line 292, in _get_const_info
    argval = const_list[const_index]
IndexError: tuple index out of range
```

Project output will not be moved to output folder

### Steps/Code to Reproduce

```py
from sklearn.neighbors import NearestNeighbors
points = np.array([[pt.x, pt.y, pt.z] for pt in face_centers])
if len(points) < 2:
      return 0
nbrs = NearestNeighbors(n_neighbors=2, algorithm='auto').fit(points)
```

### Expected Results

I expected to create exe-file with this module imported using pyInstaller

### Actual Results

```py
File "C:\Python\lib\dis.py", line 292, in _get_const_info
    argval = const_list[const_index]
IndexError: tuple index out of range
```

Project output will not be moved to output folder

### Versions

```shell
sklearn: 1.4.2
          pip: 21.3.1
   setuptools: 60.2.0
        numpy: 1.26.4
        scipy: 1.15.3
```

COMMENT:
The issue seems to be coming from `PyInstaller`, not scikit-learn. Try a clean installation environment, maybe with `mamba` or `conda`, making sure you use `conda-forge` channel. Or if using `pip`/`pypi` packages, use `uv` to create your environments.

Closing for now as this doesn't seem to be something we can fix.

Labels: Bug, Needs Triage
⚠️ CI failed on Wheel builder (last failure: Jun 17, 2025) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/15697733135)** (Jun 17, 2025)

COMMENT:
From the logs, looks like a timeout, closing to see if it happens again.

Labels: Needs Triage
is_classifier returns False for custom classifier wrappers in scikit-learn 1.6.1, even with ClassifierMixin and _estimator_type

### Describe the bug

#### Describe the bug

Since upgrading to scikit-learn 1.6.1, the utility function `is_classifier` always returns `False` for custom classifier wrappers, even if they inherit from `ClassifierMixin` and explicitly define `_estimator_type = "classifier"`.

This was not the case in previous versions (<=1.5.x), and breaks many downstream code patterns relying on `is_classifier`, as well as certain custom scorer usages and checks.


### Steps/Code to Reproduce

```python
import sklearn
print("scikit-learn version:", sklearn.__version__)

from sklearn.base import BaseEstimator, ClassifierMixin, is_classifier
from sklearn.ensemble import RandomForestClassifier

class BinCls(BaseEstimator, ClassifierMixin):
    _estimator_type = "classifier"
    def __init__(self, model=None):
        self.model = model

    def fit(self, X, y):
        self.model.fit(X, y)
        self.classes_ = self.model.classes_
        return self

    def predict(self, X):
        return self.model.predict(X)

    def predict_proba(self, X):
        return self.model.predict_proba(X)

rng = RandomForestClassifier()
clf = BinCls(rng)
print("is_classifier(clf) =", is_classifier(clf))  # Expect True, but gets False


### Expected Results

print("is_classifier(clf) =", is_classifier(clf))  # Expect True, but gets False

### Actual Results

print("is_classifier(clf) =", is_classifier(clf)) # Expect True, but gets False

### Versions

```shell
System:
    python: 3.12.9 | packaged by Anaconda, Inc. | (main, Feb  6 2025, 18:49:16) [MSC v.1929 64 bit (AMD64)]
executable: C:\Users\Greg\anaconda3\envs\ml_trade\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.6.1
          pip: 25.0
   setuptools: 72.1.0
        numpy: 2.1.3
        scipy: 1.15.2
       Cython: 3.1.1
       pandas: 2.2.3
   matplotlib: 3.10.0
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: mkl
    num_threads: 4
         prefix: mkl_rt
       filepath: C:\Users\Greg\anaconda3\envs\ml_trade\Library\bin\mkl_rt.2.dll
        version: 2023.1-Product
threading_layer: intel

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: vcomp
       filepath: C:\Users\Greg\anaconda3\envs\ml_trade\vcomp140.dll
        version: None
```

COMMENT:
We fixed a couple of things related to tags in the last version.

Here, what you observe is a bug in the code that you provide:

```python
class BinCls(BaseEstimator, ClassifierMixin):
```

The mixin should always go to the left of the base class for the inheritance to work:


```python
class BinCls(ClassifierMixin, BaseEstimator):
```

`is_classifier` in the past was relaying on `_estimator_type` and it was therefore working. Now, we rely on the mixin that set the tags and it is therefore important that the inheritance is done properly.

Labels: Bug, Needs Triage
Allow batch based metrics calculation of sklearn.metrics

### Describe the workflow you want to enable

I have a lot of data and need to calculate metrics such as accuracy_score, jaccard_score, f1_score, recall, precision etc.

### Describe your proposed solution

 When I try to calculate these it can literally take days, so i created a small solution which can batch and avg in the end, or for the weighted metrics it can do a weighted avg of each, this accelerated the calculation to just a couple of minutes, because I have a 32 core CPU. I'm willing to contribute with the proper guidance as I'm unfamiliar with the codebase, but I think many people can benefit from this. I'm unsure if there is already a work around of this present in the codebase, but if there is one do let me know, thanks a lot.

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

_No response_

### Additional context

_No response_

COMMENT:
Could you please explain more the situation? Where's the bottleneck? Calculating `.predict`? Or after that? Or that the data doesn't fit in your memory.

We'd need to have more details to be able to move forward. I'd be happy to give you pointers on where you could contribute then.

Labels: Performance, help wanted, module:metrics, Needs Investigation