5 ms·

Try isort instead https://github.com/PyCQA/isort https://github.com/PyCQA/isort

by ziml77 5y ago

luhn 5y ago
It also has a built-in "black" profile, so it only takes one line of config to get it to play nicely with Black. https://pycqa.github.io/isort/docs/configuration/black_compatibility.html https://pycqa.github.io/isort/docs/configuration/black_compa...
progval 5y ago
isort also kind of has this bad behavior when using 'import as': $ cat foo.py from x import a, b, d, e from x import c as C $ isort foo.py Fixing /tmp/foo.py $ cat foo.py from x import a, b from x import c as C from x import d, e
- jreese 5y ago
  This is something µsort actually gets right: $ usort diff foo.py --- a/foo.py +++ b/foo.py @@ -1,2 +1 @@ -from x import a, b, d, e -from x import c as C +from x import a, b, c as C, d, e https://usort.readthedocs.io https://usort.readthedocs.io
jreese 5y ago
Give µsort a try instead; it's focused on providing more safety when applying sorting to large codebases, and is designed to pair well with black out of the box: https://usort.readthedocs.io https://usort.readthedocs.io https://ufmt.omnilib.dev https://ufmt.omnilib.dev
- Spiritus 5y ago
  For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.
  - jreese 5y ago
    I suspect you are fighting the tide of common practice in the Python community. In your example, switching from `import foo` to `from foo import bar` is changing the entire nature of the import. Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. And similar to black, having a tool be consistent and predictable across projects and modules is more important than bikeshedding every possible opinion.
    - Spiritus 5y ago
      > I suspect you are fighting the tide of common practice in the Python community. I hope not! > Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. For me it's the opposite. My brain skips over the irrelevant parts (i.e. import/from). Not moving the import also produces better git diffs

Try isort instead https://github.com/PyCQA/isort https://github.com/PyCQA/isort

by ziml77 5y ago

Try isort instead https://github.com/PyCQA/isort https://github.com/PyCQA/isort

luhn 5y ago

It also has a built-in "black" profile, so it only takes one line of config to get it to play nicely with Black. https://pycqa.github.io/isort/docs/configuration/black_compatibility.html https://pycqa.github.io/isort/docs/configuration/black_compa...

progval 5y ago

isort also kind of has this bad behavior when using 'import as': $ cat foo.py from x import a, b, d, e from x import c as C $ isort foo.py Fixing /tmp/foo.py $ cat foo.py from x import a, b from x import c as C from x import d, e

jreese 5y ago
This is something µsort actually gets right: $ usort diff foo.py --- a/foo.py +++ b/foo.py @@ -1,2 +1 @@ -from x import a, b, d, e -from x import c as C +from x import a, b, c as C, d, e https://usort.readthedocs.io https://usort.readthedocs.io

jreese 5y ago

Give µsort a try instead; it's focused on providing more safety when applying sorting to large codebases, and is designed to pair well with black out of the box: https://usort.readthedocs.io https://usort.readthedocs.io https://ufmt.omnilib.dev https://ufmt.omnilib.dev

Spiritus 5y ago
For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.
- jreese 5y ago
  I suspect you are fighting the tide of common practice in the Python community. In your example, switching from `import foo` to `from foo import bar` is changing the entire nature of the import. Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. And similar to black, having a tool be consistent and predictable across projects and modules is more important than bikeshedding every possible opinion.
  - Spiritus 5y ago
    > I suspect you are fighting the tide of common practice in the Python community. I hope not! > Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. For me it's the opposite. My brain skips over the irrelevant parts (i.e. import/from). Not moving the import also produces better git diffs