Document first_party and relative being the same section vs isort

[thatch]

Now that we normalize whitespace between sections, this means that we remove a blank line that already-sorted code likely has.

import first_party.submodule import foo
from .submodule import bar

[pmeier]

Since this issue is about documenting the behavior I'm guessing it is intentional? I grew fond of the split between first party and local. Local imports are usually used for functionality that is not publicly exposed or at least not in the same location. Having a split between these two sections makes clear.

[thatch]

Yes, it's intentional, mainly for simplicity. The real-world examples I've seen of mixing absolute first-party and relative imports have all seemed pretty strange to mix (relative gets you shorter and easier to vendor, while absolute is more explicit).

Do you have an example of mixed imports that's not from people copy-pasting?

I don't know if this is helpful for torchvision but you can configure the categories on the open-source version to keep your absolute imports separate:

[tool.usort]
categories = ["future", "standard_library", "third_party", "my_torchvision", "first_party"]
first_party_detection = false

[tool.usort.known]
my_torchvision = ["torchvision"]

[pmeier]

Yes, it's intentional, mainly for simplicity.

Simplicity of implementation or something else? I imagine detecting relative imports should be quite easy since they always start with a dot.

Do you have an example of mixed imports that's not from people copy-pasting?

I can only give you a toy one: I usually draw the line between absolute and relative imports for public and private functionalities. Given a setup like

foo/
├── bar.py
├── _baz.py
├── __init__.py
└── qux.py

the content of qux.py could look like

from foo.bar import spam

from ._bar import ham

If someone inspects the code, they can see at a glance that foo.bar.spam is publicly available, whereas foo._bar.ham is not. Agreed, this is nothing major, so that wouldn't stop me from using usort.

I don't know if this is helpful for torchvision but you can configure the categories on the open-source version to keep your absolute imports separate:

So does that mean that now only relative imports get sorted into the first_party category?

[thatch]

So does that mean that now only relative imports get sorted into the first_party category?

Yes, that's what first_party_detection = false does. With just that, torchvision imports would be lumped in with other third_party ones which is what the my_torchvision part is about. (The name is arbitrary.)

I see your toy example, and while I'm generally against boolean flags if you want to send a PR I can review.

[pmeier]

if you want to send a PR I can review.

I'm kinda packed right now, so I'll live with the workaround for now.