Linting Passed

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

@jjerphan hopefully not many people would have issues since this is limited to the imports section, but we can work on the docs if issues arise.

Came here while dealing with conflicts that I think are due to isort. In particular what happened is that code like this:

from sklearn.preprocessing import (
    Binarizer,
    KernelCenterer,
    MaxAbsScaler,
    MinMaxScaler,
    Normalizer,
    PowerTransformer,
    QuantileTransformer,
    RobustScaler,
    StandardScaler,
    add_dummy_feature,
    maxabs_scale,
    minmax_scale,
    normalize,
    power_transform,
    quantile_transform,
    robust_scale,
    scale,
)

has turned into the following:

from sklearn.preprocessing import Binarizer
from sklearn.preprocessing import KernelCenterer
from sklearn.preprocessing import Normalizer
from sklearn.preprocessing import normalize
from sklearn.preprocessing import StandardScaler
from sklearn.preprocessing import scale
from sklearn.preprocessing import MinMaxScaler
from sklearn.preprocessing import minmax_scale
from sklearn.preprocessing import QuantileTransformer
from sklearn.preprocessing import quantile_transform
from sklearn.preprocessing import MaxAbsScaler
from sklearn.preprocessing import maxabs_scale
from sklearn.preprocessing import RobustScaler
from sklearn.preprocessing import robust_scale
from sklearn.preprocessing import add_dummy_feature
from sklearn.preprocessing import PowerTransformer
from sklearn.preprocessing import power_transform
from sklearn.preprocessing._data import _handle_zeros_in_scale
from sklearn.preprocessing._data import BOUNDS_THRESHOLD
from sklearn.metrics.pairwise import linear_kernel

Is this expected? From the diff/example in the original issue #22853 it looked like these "grouped imports" (better name?) would be preserved.

I have two issues with this:

1. it makes resolving the conflict very hard (I can't "just" accept the incoming change, I need to also delete code outside of the conflict and then double check that the new imports that the PR wants to add are still added).
2. I find the new style visually very not pleasing. Beyond what I posted above which I find tedious to read (hello java!) it also moves imports from sklearn.utils._testing above imports from sklearn.preprocessing which I dislike because "more important/relevant imports should come first" or however best to describe the "style" of putting imports from stdlib first, then big global packages, then local stuff, then private things, etc.

For (1): is there a tool I can use? Can I somehow accept both changes and then run ruff to have it re-sort and remove duplicate imports?

For (2) are there config options we can use (and debate endlessly ;) ) that influence how isort does its business? I can't make a rational argument for why I prefer the "pre isort" style, but aesthetically I find it much more pleasing and "normal".

it makes resolving the conflict very hard (I can't "just" accept the incoming change, I need to also delete code outside of the conflict and then double check that the new imports that the PR wants to add are still added).

Accepting both incoming and current and then running ruff --fix is a good solution for that.

For (2) are there config options we can use (and debate endlessly ;) ) that influence how isort does its business? I can't make a rational argument for why I prefer the "pre isort" style, but aesthetically I find it much more pleasing and "normal".

To me, the reasoning is the same as we had for black. Some people prefer black formatting, some people prefer another formatting convention. In the end, aesthetic doesn't really matter here. The goal is just that we don't have to think about it.

Thanks for the tip for (1). Grumpy man Tim says "I've never had to think about imports until today" - back to productive work now instead of arguing on the internet :D