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
Comments
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. |
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 |
ok, but what about as unconditional, which would be my suggested option anyway. |
I strongly agree with limited options, I like black for that as well. |
it already is unconditional? |
I mean always sort relative imports after absolute ones. Don't provide an option, change the opinionated style. |
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. |
A new value for relative, there isn't a |
see now you're bikeshedding the style |
I viewed it as suggesting an improvement to a bit of the style that afaik you don't personally care about. |
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.
The text was updated successfully, but these errors were encountered: