Isort: case_sensitive option does not apply to import lists

[johnthagen]

By default, isort does not treat case when sorting module names, but it does not carry this convention over to items imported from modules.

Consider the following code:

# mod.py
class Ball:
    pass


def a() -> None:
    pass

# No.py
class Dog:
    pass


def c() -> None:
    pass

# main.py
from mod import Ball, a
from No import Dog, c

Tested using isort 5.0.2 with the following config in pyproject.toml:

[tool.isort]
profile = "black"
src_paths = ["main.py", "mod.py"]

Running isort does not change main.py, but it seems like the case_sensitive = false default convention should carry over to items in import lists to keep everything consistent. Thus, main.py would be reformatted to:

# Now both module names and items are sorted consistently relative to casing.
from mod import a, Ball
from No import c, Dog

PyCharm only has one setting "Sort case-insensitively" which applies to both module names and items imported from modules, so this conflicts with isort, which does case-sensitivity differently based on the type of item being sorted.

[johnthagen]

Pinging @east825 to make sure I haven't overlooked anything from the PyCharm side related to this. I thought I recall that PyCharm used isort internally at one point.

[timothycrosley]

Note that you can turn of isort's type determination by setting order_by_type to False: https://timothycrosley.github.io/isort/docs/configuration/options/#order-by-type

[johnthagen]

@timothycrosley Thanks for the tip! (isort is really awesome by the way, thank you for maintaining it!)

What does "type" mean in "order_by_type"? I first thought it meant class vs function, so I changed the classes to functions:

def Dog() -> None:
    pass


def c() -> None:
    pass

def Ball() -> None:
    pass


def a() -> None:
    pass

But main.py was still formatted with capital identifiers first:

from mod import Ball, a
from No import Dog, c

Does isort assume items will be named as PEP8 compliant names? (I think this is a totally fair assumption, but perhaps the docs for order_by_type could be made a little more explicit that really isort is checking for capital letters to indicate the type?)

[johnthagen]

@timothycrosley I see there are both:

• https://timothycrosley.github.io/isort/docs/configuration/options/#dont-order-by-type
• https://timothycrosley.github.io/isort/docs/configuration/options/#order-by-type

Is there a preference on which should be used? Is one deprecated?

[east825]

Pinging @east825 to make sure I haven't overlooked anything from the PyCharm side related to this. I thought I recall that PyCharm used isort internally at one point.

Thanks for summoning me) No, we actually don't use isort internally because, similarly to the case with our home-brewed formatter, we need finer granularity of changes, e.g. when only an individual import statement needs to be adjusted during a quick fix. But we try to keep up with the most commonly used options of the tool covering various widely used code styles. We don't have any equivalent of "--order-by-type" at the moment, however, and we intentionally decided not to implement identical behavior in PY-20159 (back then I thought it's due to "--fass" option). I also agree with @johnthagen here that the meaning of "type" in this context is somewhat confusing (I'd rather assume that it's about "from" imports vs plain, qualified imports).

[timothycrosley]

@johnthagen some clarification on order_by_type: This is determined only by casing. This is actually a fairly reasonable way to do it I believe because 1) It's very complicated and error prone to try to determine what the actual types will be in a language as dynamic as Python and 2) isort lives in the context of commonly used coding standards, primarily within the Python community most of those take heavy inspiration if not being entirely derived from Pep8. In those standards, while you can say make a function with a capital letter, you are breaking another rule - that another linter is likely catching.

The rules are:

CONSTANT
Class
function or variable

All done by casing.

Only one of the options is available from the configuration file order_by_type, --dont-order-by-type is just to enable the same option to be easily set to False from the CLI since it defaults to True.

[timothycrosley]

@east825, I will note that isort does fully support just taking a single import or section of code, completely devoid of context by design. Which is what enables it to be used by other editors such as vscode.

[johnthagen]

@timothycrosley Thanks for the information, I think this issue can be closed. I'd still recommend the docs be updated:

Order imports by type in addition to alphabetically

To, perhaps:

Order imports by type, which is determined by case, in addition to alphabetically

[timothycrosley]

That's a great call!

I've updated the documentation on CLI (will take effect in next release) and on the website here: https://timothycrosley.github.io/isort/docs/configuration/options/#order-by-type

Thanks!

~Timothy

[east825]

@timothycrosley Huh, cool, thanks. I didn't know about that. Honestly, I thought that the context is mandatory at least to properly put blanks between import groups.