isort

isort is a widely-adopted Python utility that reorders import statements into a consistent, configurable layout — grouping standard-library, third-party, and local imports into sections, alphabetizing within each, and collapsing or wrapping multi-line imports according to one of several wrap styles. It can be run as a standalone CLI (isort .), as a pre-commit hook, or invoked programmatically via its isort.api module from other tools.

Because raw import ordering is subjective, isort ships built-in compatibility profiles (black, django, google, pycharm, and others) that pre-configure its dozens of settings to match a target formatter or style guide, avoiding the diff-churn that comes from two tools disagreeing about import style. It’s part of the PyCQA (Python Code Quality Authority) family of tools alongside flake8 and pylint, and is commonly paired with Black or Ruff in a formatting pipeline.

What You Get

• A isort CLI for sorting single files, whole directories, or piped stdin, with --check/--diff modes for CI
• Built-in compatibility profiles (black, django, google, pycharm, appnexus, and more) to match a project’s formatter
• A programmatic isort.api module (sort_file, sort_code_string, check_file) for embedding in other tools/linters
• Configurable import sections, known third-party/first-party lists, and multiple line-wrap styles for long import lines
• First-class pre-commit hook support and editor/IDE plugin ecosystem (VS Code, PyCharm, vim)
• A _vendored copy of tomli and other dependencies to keep isort’s own install footprint minimal

Common Use Cases

• Running isort . (or isort --check . in CI) to enforce consistent import ordering across a Python codebase
• Wiring isort into pre-commit so import sorting happens automatically before every commit
• Pairing isort with Black or Ruff using the built-in black profile to avoid the two tools fighting over formatting
• Cleaning up import statements after large refactors or auto-generated code merges
• Embedding isort.api.sort_code_string() inside a custom linting or code-generation tool’s own formatting step

Under The Hood

Architecture — main.py handles CLI argument parsing and dispatch, api.py exposes the stable programmatic entry points, core.py/parse.py do the actual import-block parsing and classification, place.py decides which section (stdlib/third-party/first-party/local) an import belongs to using the bundled stdlibs/ module-name database, and wrap.py/wrap_modes.py handle the various supported line-wrapping styles for the final output. Tech Stack — Pure Python 3.10+ with a deliberately small dependency footprint (some dependencies are vendored under _vendored/ to avoid version-conflict issues in the tools that embed isort), packaged with a standard pyproject.toml/setuptools build. Code Quality — The test suite is split into unit, integration, and benchmark directories, giving both fine-grained correctness coverage and end-to-end regression protection against real-world codebases; the project carries full type hints (py.typed) and has been rated “Mature” (Development Status 6) on PyPI for years. API Design — Both the CLI (isort ., isort --check ., isort --profile black .) and the Python API (isort.sort_file(), isort.check_file()) are deliberately minimal for the common case, while dozens of settings remain available via pyproject.toml/setup.cfg/.isort.cfg for teams with specific import-style requirements.