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

Relative import ordering #322

Closed
tolomea opened this issue Dec 19, 2022 · 10 comments
Closed

Relative import ordering #322

tolomea opened this issue Dec 19, 2022 · 10 comments

Comments

@tolomea
Copy link

tolomea commented Dec 19, 2022

I'm looking at moving over from isort, my only point of friction is relative imports.

I know they are a topic where a lot of people have strong opinions.
Our house style uses flake8-tidy-imports to limit them to same package only, we find that for same package relative is lower cognitive load than absolute, while cross package it's more cognitive load.

I see from comments and issues that you don't personally use relative imports and that having them in their own section like isort does caused a bunch of issues.

It looks like changing the sort order to place relatives last was maybe also a feature at some point although without release notes I'm not sure if/when/why, it's quite hard to tell from the git log of classify-imports.

How do you feel about changing the sort key so that relatives get placed after absolute imports rather than before?

As an unconditional behaviour it looks like it'd be maybe a half dozen lines + tests.
Obviously conditional would be a lot more work, however it seems unlikely that anyone using relative imports particularly expects them to be first.

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

I should add that I'm happy to have a crack at a PR, just given the history I'd like to check first if it's going to get a flat no response. And if not how you feel about the optional vs always question.

@asottile
Copy link
Owner

no thanks -- the whole point of the tool is there's no bikeshedding. it does one thing and only one thing. isort for example has a fractal of options which makes it impossible to agree on a style

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

ok, but what about as unconditional, which would be my suggested option anyway.

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

I strongly agree with limited options, I like black for that as well.

@asottile
Copy link
Owner

it already is unconditional?

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

I mean always sort relative imports after absolute ones. Don't provide an option, change the opinionated style.

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

Within the existing blocks, so just a couple of lines change to each of the sort_key functions. The number field at the front that's used for distinguishing from imports could be extended to have a couple more values for relative and from relative.

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

A new value for relative, there isn't a import .bob, clearly time for me to go home for the evening.

@asottile
Copy link
Owner

see now you're bikeshedding the style

@tolomea
Copy link
Author

tolomea commented Dec 19, 2022

I viewed it as suggesting an improvement to a bit of the style that afaik you don't personally care about.

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

No branches or pull requests

2 participants