✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: 501adad. Link to the linter CI: here}

I don't get that "E" and "F" rules were dropped but there still are "E***" and "F***" exceptions.
I feel like we should enable back all of them

#31015 changed from select to extend-select as well, according to the ruff doc select default is E4, E7, E9, and F:

[tool.ruff.lint]
# On top of the default `select` (`E4`, E7`, `E9`, and `F`), enable flake8-bugbear (`B`) and flake8-quotes (`Q`).
extend-select = ["B", "Q"]

Not sure how often ruff change its defaults and whether we want to use extend-select (trust ruff defaults and extend them) or select (have full controls for our rules).

The F rules are part of the default ruff rules, no need to explicitly select them when using extend-select:

A list of rule codes or prefixes to enable, in addition to those specified by select.

From select:

Default value: ["E4", "E7", "E9", "F"]

Additionally, Conflicting lint rules should be avoided when using Ruff as a formatter. Specifically about E501:

While the line-too-long (E501) rule can be used alongside the formatter, the formatter only makes a best-effort attempt to wrap lines at the configured line-length. As such, formatted code may exceed the line length, leading to line-too-long (E501) errors.

I recommend using extend-select because it automatically avoids E Conflicting lint rules. The default list of rules ["E4", "E7", "E9", "F"] has been pretty stable for a very long time - by Ruff standards at least 😄

But the formatter doesn't split long strings. In some cases like the ones identified in this PR it's acceptable but if I write something like

warnings.warn(
    "a very looo ... ooong string"
)

it's pretty bad to keep as is imo. To me it's a regression compared to our previous state when we didn't have to care about that, while now I have to split them manually, and be extra careful when reviewing PRs that they don't introduce such behavior.

Just don't split strings. See for example what the Linux kernel coding style has to say about user-visible strings:

Coding style is all about readability and maintainability using commonly available tools.

The limit on the length of lines is 80 columns and this is a strongly preferred limit.

Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them.

I can revert ruff format if you dislike it that much. I'll also look into settings that might help.

This is C code and the motivation is to be able to grep. I think that breaking strings in Pyhon like this

"this is the beginning "
"and this is the end"

means implicit concatenation and the intrepreter treats it a 1 line string.

On the other hand, it also says

Coding style is all about readability

and having a string that spans 3 screens is really not readable at all.

I can revert ruff format if you dislike it that much. I'll also look into settings that might help.

I have no issue with ruff formatting. I'd just like to have a way to enforce the 88 chars limits, even on strings.

It's the formatter's job to break lines. Unfortunately, unlike black, ruff currently doesn't process strings the way you would like. This is tracked in issue astral-sh/ruff#6936.

Until the above issue is addressed, you could indeed re-enable E501. The risk is that formatting could result in unsolvable E501 issues — although I doubt it happens in practice.

I'm in favor of enabling E501

To try to clarify the situation, there are a few different things:

1. linting: if this PR is merged the ruff check will complain if a line containing a long string and the line goes over 88 characters. IMO this was an oversight of MNT black → ruff format #31015 and this PR fixes it.
2. autoformatting: our pre-commit black hook has not formatted automatically lines with long strings since slightly more than a year and MNT upgrade black version #28802 was merged to upgrade the black version. black --preview does not format long strings automatically since 24.1.0. You need to explicitly do black --preview --enable-unstable-feature string_processing ¹. Maybe some people had custom workflows to do it in their editor, but if that's the case I think this was overriding our pyproject.toml.

3. it would be nice to find more info about possible edge cases where ruff format autoformats in a way that make ruff check unhappy because the line is too long i.e. MNT Make ruff check line-too-long (E501) #31214 (comment). I don't think I needed to correct any such issues in this PR, where the full scikit-learn code was autoformatted, so my guess is that it will happen very rarely. If that ever happens we can always use # noqa: E501².