`--fss` may lead to incorrect import separation for mixed multi-line and alias imports

[n0gu-furiosa]

When using --force-sort-within-sections (--fss), imports from the same module can be incorrectly separated.

Reproduction (repro.py):

from module import (
    AAAAAAAAAAAAAAAAAAAAAAAAAA,
    BBBBBBBBBBBBBBBBBBBBBBBBBB,
    CCCCCCCCCCCCCCCCCCCCCCCCCC,
)
from module import DDDDDDDDDDDDDDDDDDDDDDDDDD as d
from module import (
    EEEEEEEEEEEEEEEEEEEEEEEEEE,
    FFFFFFFFFFFFFFFFFFFFFFFFFF,
    GGGGGGGGGGGGGGGGGGGGGGGGGG,
)

Sorting this file with isort repro.py --fss results in imports from the same module being split in a seemingly meaningless way:

from module import (
    AAAAAAAAAAAAAAAAAAAAAAAAAA,
    BBBBBBBBBBBBBBBBBBBBBBBBBB,
    CCCCCCCCCCCCCCCCCCCCCCCCCC,
)
from module import (
    EEEEEEEEEEEEEEEEEEEEEEEEEE,
    FFFFFFFFFFFFFFFFFFFFFFFFFF,
    GGGGGGGGGGGGGGGGGGGGGGGGGG,
)
from module import DDDDDDDDDDDDDDDDDDDDDDDDDD as d

This happens because _with_from_imports sees those as three separate groups, and then during within-section sorting sorting.section_key determines that import (... should precede import D....

It's hard to say that isort is doing something wrong, but splitting imports from the same module is undesirable. My preferred output in this situation would be:

from module import (
    AAAAAAAAAAAAAAAAAAAAAAAAAA,
    BBBBBBBBBBBBBBBBBBBBBBBBBB,
    CCCCCCCCCCCCCCCCCCCCCCCCCC,
    EEEEEEEEEEEEEEEEEEEEEEEEEE,
    FFFFFFFFFFFFFFFFFFFFFFFFFF,
    GGGGGGGGGGGGGGGGGGGGGGGGGG,
)
from module import DDDDDDDDDDDDDDDDDDDDDDDDDD as d

I think there are a few ways to approach this:

• Add a new configuration option: Introduce a flag (e.g., --force-separate-as-imports) that operates within the _with_from_imports function to explicitly place as_imports at the end of the list.
• Normalize ( in section_key: Modify the key generation so that module import (AAAA is treated as module import AAAA for sorting purposes. This would not produce my "preferred output," but it would at least leave repro.py unchanged, avoiding multiple separated from module import ( blocks.
• No new flag, no new sort logic, just merge outputs from new_section_output: Iterate over the new section output, parse them again, and merge imports where possible. I personally think this would be the least preferred option because it doesn't integrate well with the rest of the system and would have a high maintenance cost.

I would appreciate any input from the maintainers on whether this is worth addressing and, if so, which approach is preferred. I am happy to contribute a PR if the team agrees on a direction.

[DanielNoord]

I agree with the higher maintenance cost, but also think that your preferred output is what most users would expect the output to be.

You don't think it is feasible to implement this without higher maintenance costs?

[n0gu-furiosa]

I think implementing a ad-hoc solution for this case wouldn’t be very hard.

My main concern is that this logic would live outside the core flow (parsing, section partitioning, and sorting), which makes it a bit uneasy to tell how well it would interact with existing configs (e.g. --no-inline-sort) and potentially new ones added in the future. That said, if you feel this isn’t a significant concern, I’m happy to move forward with an implementation.

On a related note, can you give your thoughts on how isort should sort the following example?

from module import A, B, C, D as d, E, F, G

Currently, vanilla isort produces (with or without --fss):

from module import A, B, C
from module import D as d
from module import E, F, G

But one could argue that this might be more intuitive:

from module import A, B, C, E, F, G
from module import D as d

If the latter output feels more appropriate, this might even be something worth promoting to option 1 in the issue description.

[DanielNoord]

Yeah, to me the final output seems more intuitive.

@staticdev what do you think?