isort provides lots of features to enable configuring how it sections imports
and how it sorts imports within those sections.
You can change the section order with sections option from the default
of:
FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDERto your preference (if defined, omitting a default section may cause errors):
sections=FUTURE,STDLIB,FIRSTPARTY,THIRDPARTY,LOCALFOLDERYou also can define your own sections and their order.
Example:
known_django=django
known_pandas=pandas,numpy
sections=FUTURE,STDLIB,DJANGO,THIRDPARTY,PANDAS,FIRSTPARTY,LOCALFOLDERwould create two new sections with the specified known modules.
The no_lines_before option will prevent the listed sections from being
split from the previous section by an empty line.
Example:
sections=FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER
no_lines_before=LOCALFOLDERwould produce a section with both FIRSTPARTY and LOCALFOLDER modules combined.
IMPORTANT NOTE: It is very important to know when setting known sections that the naming
does not directly map for historical reasons. For custom settings, the only difference is
capitalization (known_custom=custom VS sections=CUSTOM,...) for all others reference the
following mapping:
known_standard_library:STANDARD_LIBRARYextra_standard_library:STANDARD_LIBRARY# Like known standard library but appends instead of replacingknown_future_library:FUTUREknown_first_party:FIRSTPARTYknown_third_party:THIRDPARTYknown_local_folder:LOCALFOLDER
This will likely be changed in isort 6.0.0+ in a backwards compatible way.
isort classifies each imported module before sorting it into a section. It uses these checks in order, stopping at the first match:
- A forced separate pattern that matches the
start of the module name puts the import in that separate section. isort
appends
*to a pattern that does not end with one, sodjango.contribalso matchesdjango.contrib.authanddjango.contribfoo. - An import starting with a dot, such as
from .utils import helper, goes inLOCALFOLDER. - A matching
known_*setting selects its configured section. This includes the standard library list for the configured Python version. isort checks the full module name before its parent names, so a setting formypackage.specialcan override one formypackage. Aknown_*setting is ignored when its section is not listed in sections. - A module or package found under source paths goes in
FIRSTPARTY. This includes Python modules, extension modules, packages and directories. Namespace packages are checked for the imported submodule. - Otherwise, the import goes in the default section,
which is
THIRDPARTYunless configured differently.
With the default configuration, this means:
| Import | Section | Reason |
|---|---|---|
from __future__ import annotations |
FUTURE |
Included in known_future_library |
import os |
STDLIB |
Included in the standard library list |
import mypackage |
FIRSTPARTY |
Found in the configured source paths |
import external_package |
THIRDPARTY |
No earlier rule matches |
from . import utils |
LOCALFOLDER |
Starts with a dot |
By default, isort searches the configuration directory and its src
subdirectory for first-party imports. Without a configuration file, this is
based on the directory used to resolve the configuration. Running isort from a
different directory, or selecting a different settings file, can therefore
change which imports are considered first-party.
For a project with its packages under lib, configure that directory explicitly:
[tool.isort]
src_paths = ["lib"]Relative source paths are resolved from the configuration directory. A source path may also name the package directory itself. In that case, both the package and importable modules inside that directory can be classified as first-party.
To classify a package independently of where isort runs or whether its source is present, use an explicit setting:
[tool.isort]
known_first_party = ["mypackage"]
known_third_party = ["external_package"]These settings take precedence over source-path detection. isort does not need
to import a package or find it in an installed environment to classify it.
Use isort --verbose path/to/file.py to see each import's classification and
isort --show-config path/to/file.py to check the settings and their sources.
Some projects prefer to have import sections uniquely titled to aid in
identifying the sections quickly when visually scanning. isort can
automate this as well. To do this simply set the
import_heading_{section_name} setting for each section you wish to
have auto commented - to the desired comment.
For Example:
import_heading_stdlib=Standard Library
import_heading_firstparty=My StuffWould lead to output looking like the following:
# Standard Library
import os
import sys
import django.settings
# My Stuff
import myproject.testisort also makes it easy to sort your imports by length, simply by
setting the length_sort option to True. This will result in the
following output style:
from evn.util import (
Pool,
Dict,
Options,
Constant,
DecayDict,
UnexpectedCodePath,
)It is also possible to opt-in to sorting imports by length for only
specific sections by using length_sort_ followed by the section name
as a configuration item, e.g.:
length_sort_stdlib=1
By default isort places straight (import y) imports above from imports (from x import y):
import b
from a import a # This will always appear below because it is a from import.However, if you prefer to keep strict alphabetical sorting you can set force sort within sections to true. Resulting in:
from a import a # This will now appear at top because a appears in the alphabet before b
import bYou can even tell isort to always place from imports on top, instead of the default of placing them on bottom, using from first.
from b import b # If from first turnrf on, all from imports are placed before non-from imports.
import a