Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

isort incompatibilites with lowercase, MixedCase, UPPERCASE #673

Closed
andersk opened this issue Nov 11, 2022 · 7 comments · Fixed by #691
Closed

isort incompatibilites with lowercase, MixedCase, UPPERCASE #673

andersk opened this issue Nov 11, 2022 · 7 comments · Fixed by #691
Assignees
Labels
isort Related to import sorting

Comments

@andersk
Copy link
Contributor

andersk commented Nov 11, 2022

isort --profile=black --ca:

import lowercase
import MixedCase
import UPPERCASE
from module import UPPERCASE, MixedCase, lowercase

ruff --select=I:

import MixedCase
import UPPERCASE
import lowercase
from module import MixedCase, UPPERCASE, lowercase
@charliermarsh
Copy link
Member

Nice, thank you.

@charliermarsh
Copy link
Member

This is described and controlled by the order_by_type option.

Do we like this? I don't feel strongly about it.

@charliermarsh
Copy link
Member

To phrase it differently: ignoring isort compatibility, would we want this behavior? (I think it's worth implementing for compatibility purposes.)

@charliermarsh charliermarsh added the isort Related to import sorting label Nov 11, 2022
@charliermarsh
Copy link
Member

Interestingly, it looks like this just applies to import from members. For import statements, isort sorts in a non-case-sensitive way (which I also find surprising! but it's probably rare to have cased module names anyway?).

@charliermarsh
Copy link
Member

(At the very least, making this clearer in #676.)

@andersk
Copy link
Contributor Author

andersk commented Nov 11, 2022

Yeah, I think compatibility is the main value.

In Zulip, the diff for combine_as_imports = true would be +51 −65: fine, if that’s likely to be the future isort default, and it is a bit more compact. The diff for order_by_type = false + case_sensitive = true would be a further +80 −78: not abhorrent, but would be nicer to avoid, if there’s no particular rationale either way.

I noticed another effect of case-sensitivity:

-from typing import Type, TypeVar, TypedDict
+from typing import Type, TypedDict, TypeVar

which would maybe a weak argument in favor, except that the effect on all-uppercase names is exactly the opposite:

-from loud_typing import TYPE, TYPED_DICT, TYPE_VAR
+from loud_typing import TYPE, TYPE_VAR, TYPED_DICT

🤷

Uppercase modules are indeed rare but do exist: Zulip uses DNS and PIL.

@charliermarsh
Copy link
Member

Haha yeah, now that I'm being forced to confront it, I find the isort behavior pretty confusing. I wish it was all just lexicographic sorting? But like most stylistic issues, I don't have a strong opinion as long as some standard is consistently enforced, and so it makes sense to me to prioritize isort compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
isort Related to import sorting
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants