Talip7/scikit-learn-issues-multilabel huggingface dataset:
Add an option handle_unknown="warn" in OneHotEncoder

Follow-up to https://github.com/scikit-learn/scikit-learn/pull/16881

It seems that it could be interested to log an eventual detection of new category during inference and issue a warning instead of silently ignoring them.

Therefore, it seems reasonable to add a new option `handle_unknown="warn"` to `OneHotEncoder` that should behave as `"ignore"` but should issue an additional warning.

COMMENT:
> I can work on it, if it will be approved.

It was already approved in another PR that got stalled. I think we can reasonably envisage to not have debated discussion regarding the inclusion of the feature ;)

> Should it log just the detection of the new value in any feature (like a boolean flag) or should it warn every time it sees the new value in every feature?

I would warn as much as possible since we still have the option to ignore anyway.

> Should it just log or maybe also propose a solution to mitigate an unwanted behaviours?

I would only log, meaning raise a warning. However, the documentation of the `"warn"` option could provide a discussion on how to resolve it.

Labels: Enhancement
Add a download_openml util

We should add a `download_openml` utility in `sklearn.datasets` which downloads the file, but doesn't return `X, y`, and instead returns the paths to the downloaded data file (arff or parquet), and the metadata json file.

This utility can then be internally called by `fetch_openml`.

A user, can then do something like:

```py
data_file, metadata_file = download_openml(id=..., format="parquet")
data = polars.read_parquet(data_file)
metadata = json.loads(metadata_file)
# use metadata to separate data into X and y
y = data[metadata["target_column"]
X = data.drop(metadata["target_column"])
```

This should be easy to implement, and should make a bunch of our examples closer to a real world kind of scenario.

cc @glemaitre @ogrisel @GaelVaroquaux @MarcoGorelli

COMMENT:
Sounds great - even better would be `polars.scan_parquet` if you want to do lazy preprocessing (though you'll still need to collect at some point before `.fit`...)

Would you like a channel in the Discord server to facilitate scikit-learn :handshake: Polars collaboration? The invite for the server is https://discord.gg/4UfP5cfBE7

Labels: New Feature
Add a download_openml util

We should add a `download_openml` utility in `sklearn.datasets` which downloads the file, but doesn't return `X, y`, and instead returns the paths to the downloaded data file (arff or parquet), and the metadata json file.

This utility can then be internally called by `fetch_openml`.

A user, can then do something like:

```py
data_file, metadata_file = download_openml(id=..., format="parquet")
data = polars.read_parquet(data_file)
metadata = json.loads(metadata_file)
# use metadata to separate data into X and y
y = data[metadata["target_column"]
X = data.drop(metadata["target_column"])
```

This should be easy to implement, and should make a bunch of our examples closer to a real world kind of scenario.

cc @glemaitre @ogrisel @GaelVaroquaux @MarcoGorelli

COMMENT:
I think it's important to have all relevant information included in the related issues / PRs here so that other reviewers have the context, but I've joined your discord now and happy to discuss there about things when it makes it easier.

Labels: New Feature
Add a download_openml util

We should add a `download_openml` utility in `sklearn.datasets` which downloads the file, but doesn't return `X, y`, and instead returns the paths to the downloaded data file (arff or parquet), and the metadata json file.

This utility can then be internally called by `fetch_openml`.

A user, can then do something like:

```py
data_file, metadata_file = download_openml(id=..., format="parquet")
data = polars.read_parquet(data_file)
metadata = json.loads(metadata_file)
# use metadata to separate data into X and y
y = data[metadata["target_column"]
X = data.drop(metadata["target_column"])
```

This should be easy to implement, and should make a bunch of our examples closer to a real world kind of scenario.

cc @glemaitre @ogrisel @GaelVaroquaux @MarcoGorelli

COMMENT:
I'm interested in working on this issue.

Labels: New Feature
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
I have noticed that the first line of  `numpy/__init__.pxd` says "for cython < 3.0"

Using cython > 3, the relevant file seems to be:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.cython-30.pxd#L59

But the definition is still the same:

`ctypedef unsigned int       npy_uint32`

Labels: Bug, cython
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
Thanks for the report. Indeed we need to align our types to those of numpy.

However, this is weird because we do have a linux 32-bit CI (albeit with an older gcc version) where the following test does pass:

https://github.com/scikit-learn/scikit-learn/blob/567388013bc02adbebd80a613ce47653391a12dd/sklearn/utils/tests/test_typedefs.py#L7-L24

Labels: Bug, cython
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
Anyways I believe this should be fixed by #28656:

https://github.com/scikit-learn/scikit-learn/pull/28656/files#diff-5829233c37ebf7320b24dd970725c53fbbb1cd789e2ad5157093280f7f2a388c

can you confirm @sergiopasra? I am running macos/arm64 on my local machine, so it's not that easy for me to setup a 32-bit gcc 14 environment quickly to test it myself.

Labels: Bug, cython
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
I also had a look at the v1.26.4 version of the types and I cannot understand where this "long" qualifier in the GCC error message comes from:

- https://github.com/numpy/numpy/blob/9815c16f449e12915ef35a8255329ba26dacd5c0/numpy/__init__.pxd#L280C1-L280C43

```python
    ctypedef unsigned int       npy_uint32
```

- https://github.com/numpy/numpy/blob/9815c16f449e12915ef35a8255329ba26dacd5c0/numpy/__init__.pxd#L697C1-L697C33

```python
    ctypedef npy_uint32     uint32_t
```

Also the `n_features` variable passed from the caller in `_cd_fast.pyx` is also `cdef unsigned int`...

I am really confused. Even if I don't understand the cause of this compiler error message, it's possible that #28656 fixed it anyway.

Labels: Bug, cython
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
Gentle ping to @sergiopasra. Do you know if the issue is fixed in `main`?

Labels: Bug, cython
Error compiling with GCC14 in i686

### Describe the bug

This is another error compiling with GCC14, different to the error reported in #28530
It happens when compiling in i386 in the Fedora build system. I get an "incompatible pointer type" `between `random_UINT32_t *` and  `typedefs_uint32_t *`

A function expects `random_UINT32_t *` and it gets a `typedefs_uint32_t *` The former is a `unsigned int *` and the latter a `long unsigned int *`

Both definitions seem identical, but somehow they are not in i386

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_typedefs.pxd#L18

https://github.com/scikit-learn/scikit-learn/blob/612d93da5ec8733d3d96e5592a01269a822b350f/sklearn/utils/_random.pxd#L7

And the numpy definition:

https://github.com/numpy/numpy/blob/160d2c6237aa79877f1334b0e1fde468ddcf2ccc/numpy/__init__.pxd#L54



### Steps/Code to Reproduce

Run  `python setup.py build` in i386 and with GCC14

### Expected Results

Finish compiling

### Actual Results


```
  sklearn/linear_model/_cd_fast.c: In function ‘__pyx_f_7sklearn_12linear_model_8_cd_fast_rand_int’:
  sklearn/linear_model/_cd_fast.c:20417:59: error: passing argument 1 of ‘__pyx_f_7sklearn_5utils_7_random_our_rand_r’ from incompatible pointer type [-Wincompatible-pointer-types]
  20417 |   __pyx_t_1 = __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_v_random_state); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_7_random_UINT32_t)-1) && __Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 40, __pyx_L1_error)
        |                                                           ^~~~~~~~~~~~~~~~~~~~
        |                                                           |
        |                                                           __pyx_t_7sklearn_5utils_9_typedefs_uint32_t * {aka unsigned int *}
  sklearn/linear_model/_cd_fast.c:20308:151: note: expected ‘__pyx_t_7sklearn_5utils_7_random_UINT32_t *’ {aka ‘long unsigned int *’} but argument is of type ‘__pyx_t_7sklearn_5utils_9_typedefs_uint32_t *’ {aka ‘unsigned int *’}
  20308 | static CYTHON_INLINE __pyx_t_7sklearn_5utils_7_random_UINT32_t __pyx_f_7sklearn_5utils_7_random_our_rand_r(__pyx_t_7sklearn_5utils_7_random_UINT32_t *__pyx_v_seed)
```

Full build log https://kojipkgs.fedoraproject.org//work/tasks/6630/114766630/build.log

### Versions

```shell
1.4.1.post1
```

COMMENT:
Since this is probably fixed in `main`, closing, happy to reopen if the issue persists.

Labels: Bug, cython
DOC: update FAQs to add permission using images

### Describe the issue linked to the documentation

We receive many inquiries on the mailing list if developers can have permission to use the images in scikit-learn for their work.

Add an FAQ to answer this question:
- code is under a BSD 3-clause licence, so the permission is granted
- please cite us. link to the citation page.

FAQs page:
https://scikit-learn.org/dev/faq.html

Cite us:
https://scikit-learn.org/dev/about.html#citing-scikit-learn


### Suggest a potential alternative/fix

_No response_

COMMENT:
Hey @reshamas, I am working on this issue.

Labels: Documentation
Print warning if user passed only one class into StratifiedKFold

### Describe the workflow you want to enable

StratifiedKFold and other stratified splitters were designed to balance cross validation based on target or some features.

Currently, if you pass a column with only one class (which majority of times is a user mistake) there is no warning, and it works as the usual KFold validation.

I encountered a situation when I mistakenly passed wrong target format with only one class, and StratifiedKFold didn't warn me, so this quite problematic mistake in validation went unnoticed for entire project.

### Describe your proposed solution

Print a warning if stratification column has only one unique value.

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

_No response_

### Additional context

_No response_

COMMENT:
It seems reasonable to improve a bit the situation here.

Labels: Enhancement
Print warning if user passed only one class into StratifiedKFold

### Describe the workflow you want to enable

StratifiedKFold and other stratified splitters were designed to balance cross validation based on target or some features.

Currently, if you pass a column with only one class (which majority of times is a user mistake) there is no warning, and it works as the usual KFold validation.

I encountered a situation when I mistakenly passed wrong target format with only one class, and StratifiedKFold didn't warn me, so this quite problematic mistake in validation went unnoticed for entire project.

### Describe your proposed solution

Print a warning if stratification column has only one unique value.

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

_No response_

### Additional context

_No response_

COMMENT:
I'll work on this issue.

Labels: Enhancement
Print warning if user passed only one class into StratifiedKFold

### Describe the workflow you want to enable

StratifiedKFold and other stratified splitters were designed to balance cross validation based on target or some features.

Currently, if you pass a column with only one class (which majority of times is a user mistake) there is no warning, and it works as the usual KFold validation.

I encountered a situation when I mistakenly passed wrong target format with only one class, and StratifiedKFold didn't warn me, so this quite problematic mistake in validation went unnoticed for entire project.

### Describe your proposed solution

Print a warning if stratification column has only one unique value.

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

_No response_

### Additional context

_No response_

COMMENT:
@glemaitre PR seems to solve the issue, kindly reminding to review

Labels: Enhancement