Introduction

Python import order is mostly about readability and consistency, not runtime speed. The accepted baseline comes from PEP 8, and most teams enforce it with isort so nobody has to debate formatting by hand. The practical rule is to group imports by origin, sort within each group, and let a formatter keep the file stable.

Group Imports Before Sorting Them

PEP 8 recommends three main groups in this order:

1. standard library imports
2. third-party imports
3. local application imports

Leave one blank line between groups.

Inside each group, sort imports alphabetically. Keep the statements themselves readable instead of trying to invent separate rules for every import style.

For example:

1import os
2import sys
3from pathlib import Path
4
5import requests
6from pydantic import BaseModel
7
8from myapp.config import settings
9from myapp.services.user import UserService

This is much easier to scan than a mixed list of standard library, third-party, and local imports.

How To Order import x And from x import y

The most common convention is to sort by module name within the section and keep direct imports and from imports in normal alphabetical order. In practice, that means you do not need a special human rule such as "all import lines before all from lines." Let the full statements sort in a consistent way, or better yet, let isort decide.

A manually cleaned block might look like this:

1import collections
2import os
3from pathlib import Path
4from typing import Iterable

Notice that the module path still drives readability. The goal is not to satisfy a clever sorting trick. The goal is to make dependencies easy to find.

Use One Import Per Line For Clarity

Python style is easier to maintain when each import stands on its own line. That makes diffs smaller and merge conflicts less annoying.

Prefer this:

from pathlib import Path
from typing import Iterable
from typing import Sequence

Over this:

from pathlib import Path
from typing import Iterable, Sequence

Many teams still allow multiple names from the same module if the list is short, but long import lists should usually be wrapped or split by a formatter.

Let isort Apply The Rule Consistently

The best answer for a real codebase is to stop sorting imports manually. isort understands PEP 8-style grouping and can be configured to match your formatter.

pip install isort
isort path/to/module.py

A minimal pyproject.toml configuration often looks like this:

[tool.isort]
profile = "black"
line_length = 88

With that in place, isort and black usually cooperate cleanly. This eliminates style debates and makes import formatting deterministic in CI.

Relative Imports And Special Cases

Local imports should still stay in the application section, even if they are relative:

from .models import User
from .services import build_report

If you intentionally keep an import inside a function to avoid a circular dependency or heavy startup cost, leave it there and add a short comment if the reason is not obvious.

Also be careful with wildcard imports. from module import * makes dependencies harder to track and should generally be avoided outside a few specialized cases such as package export modules.

Common Pitfalls

The most common mistake is mixing groups together and then alphabetizing the whole block. That hides the distinction between built-in modules, installed packages, and local code.

Another issue is hand-formatting imports in a way that fights the team's formatter. If the project uses isort, follow it instead of inventing a personal rule.

Developers also sometimes optimize the wrong thing. Reordering imports does not meaningfully improve performance in normal applications. The value is maintainability.

Finally, avoid leaving unused imports behind. A perfectly sorted import block is still noisy if half the imports are dead code.

Summary

• Follow PEP 8 grouping: standard library, third-party, then local imports.
• Sort imports alphabetically within each group.
• Do not overthink import x versus from x import y; use a consistent sorter.
• Prefer isort so the rule is automatic and team-wide.
• Keep imports readable, explicit, and free of unused entries.