11 ms·

Interesting. Now that isort has support for black-compatibility, what’s the main difference with usort?

• jreese 5y ago
  We've written a number of words on "Why µsort", including a comparison to isort: https://usort.readthedocs.io/en/stable/why.html https://usort.readthedocs.io/en/stable/why.html The biggest reason is µsort's detection of sortable "blocks" of imports, and only sorting within those blocks to limit breaking changes, combined with use of proper parsing and CST manipulation to guarantee valid syntax after sorting.
  • wcdolphin 5y ago
    Very cool. I love the idea of one tool rather than two, I’ll check it out!
  • stdbrouw 5y ago
    FWIW, there's one particular use case where the isort behavior is incredibly useful: in eval-as-you-type data science e.g. when using Hydrogen in Atom you type an import whenever you need it but that leads to a lot of duplication and imports scattered across the file, and it's nice that isort just moves that up top on every save.
    • jreese 5y ago
      That's something we're aware of, and something we've considered, but also potentially dangerous from a safety standpoint, due to Python's dynamic nature, and how much moving imports can affect runtime semantics. Any implementation of this would need to be aware of those dangers, and also be able to provide stable and predictable behavior. At the moment, it's not a huge priority given the availability of tooling to automatically add missing imports, or the limited impact of under-sorting in the context of notebooks.