Python Patterns
This skill is for day-to-day Python code quality: readability, correctness, maintainability.
If you are doing asyncio-heavy work, prefer python-async-patterns. If the task is profiling, GIL/free-threading, or experimental JIT, use python-performance.
When to activate
- Writing/refactoring Python modules, libraries, services
- Reviewing PRs for idioms, clarity, and footguns
- Introducing typing or improving error handling
- Designing lightweight data models and APIs
- Choosing threads vs processes vs subinterpreters (not asyncio)
Core principles (high signal)
- Readability beats cleverness.
- Be explicit at boundaries (I/O, parsing, network). Keep inner code simple.
- Prefer small, typed functions with clear names.
- Use context managers for resource safety.
- Raise specific exceptions and preserve causes (
raise ... from e).
Outcome expectations
- Code is readable; intent is clear from names and structure, not comments.
- All public APIs have type annotations; error boundaries are explicit.
- Resource cleanup is deterministic (via context managers, no
__del__).
- Exceptions are domain-specific and chain causes; no silent failures.
Recommended workflow
- Design module interfaces with clear input/output types and error contracts.
- Use context managers for all resource acquisition.
- Validate at I/O boundaries; raise specific errors with cause chaining.
- Apply ruff, mypy (on public APIs), and pytest baseline in CI.
- Review code for footguns (mutable defaults, bare
except, type hiding).
Quick review checklist
- No mutable default arguments;
None sentinel used
is None / is not None (not == None)
- Specific
except clauses; no bare except:
- Types: public functions/classes have annotations; 3.12+ type-parameter syntax;
T | None not Optional[T]
- Files/paths use
pathlib.Path (Path.walk 3.12+); not os.path string soup
- Iteration uses comprehensions/generators only when simple
- CPU-bound fan-out uses executors from
concurrency.md, not unbounded Thread spawns
Resources
Load on demand:
references/typing.md — load for annotations, PEP 695 generics, Protocols, 3.14 deferred evaluation
references/errors.md — load for exception hygiene, ExceptionGroup / except*, finally control flow
references/data-models.md — load for dataclasses, copy.replace, StrEnum, t-strings (3.14)
references/iteration.md — load for comprehensions, generators, itertools.batched, match
references/resources.md — load for context managers and pathlib
references/concurrency.md — load for threads, concurrent.futures, queues, multiprocessing start methods, InterpreterPoolExecutor
references/layout-tooling.md — load for pyproject.toml, ruff/mypy/pytest, removed stdlib modules
references/performance.md — one-screen "don't micro-optimize here"; real measurement is python-performance
1---2name: python-patterns3description: Pythonic patterns for readable, robust Python: typing, error handling, data modeling, iteration, resource management, threading/process/subinterpreter primitives, project layout, and tooling. Use when writing or reviewing Python code and APIs. For measurement/GIL/JIT use python-performance; for asyncio orchestration use python-async-patterns.4license: MIT5---67# Python Patterns89This skill is for **day-to-day Python code quality**: readability, correctness, maintainability.1011If you are doing asyncio-heavy work, prefer `python-async-patterns`. If the task is profiling, GIL/free-threading, or experimental JIT, use `python-performance`.1213## When to activate1415- Writing/refactoring Python modules, libraries, services16- Reviewing PRs for idioms, clarity, and footguns17- Introducing typing or improving error handling18- Designing lightweight data models and APIs19- Choosing threads vs processes vs subinterpreters (not asyncio)2021---2223## Core principles (high signal)2425- Readability beats cleverness.26- Be explicit at boundaries (I/O, parsing, network). Keep inner code simple.27- Prefer small, typed functions with clear names.28- Use context managers for resource safety.29- Raise specific exceptions and preserve causes (`raise ... from e`).3031---3233## Outcome expectations3435- Code is readable; intent is clear from names and structure, not comments.36- All public APIs have type annotations; error boundaries are explicit.37- Resource cleanup is deterministic (via context managers, no `__del__`).38- Exceptions are domain-specific and chain causes; no silent failures.3940---4142## Recommended workflow43441. Design module interfaces with clear input/output types and error contracts.452. Use context managers for all resource acquisition.463. Validate at I/O boundaries; raise specific errors with cause chaining.474. Apply ruff, mypy (on public APIs), and pytest baseline in CI.485. Review code for footguns (mutable defaults, bare `except`, type hiding).4950---5152## Quick review checklist5354- No mutable default arguments; `None` sentinel used55- `is None` / `is not None` (not `== None`)56- Specific `except` clauses; no bare `except:`57- Types: public functions/classes have annotations; 3.12+ type-parameter syntax; `T | None` not `Optional[T]`58- Files/paths use `pathlib.Path` (`Path.walk` 3.12+); not `os.path` string soup59- Iteration uses comprehensions/generators only when simple60- CPU-bound fan-out uses executors from `concurrency.md`, not unbounded `Thread` spawns6162---6364## Resources6566Load on demand:6768- `references/typing.md` — load for annotations, PEP 695 generics, Protocols, 3.14 deferred evaluation69- `references/errors.md` — load for exception hygiene, `ExceptionGroup` / `except*`, `finally` control flow70- `references/data-models.md` — load for dataclasses, `copy.replace`, `StrEnum`, t-strings (3.14)71- `references/iteration.md` — load for comprehensions, generators, `itertools.batched`, `match`72- `references/resources.md` — load for context managers and pathlib73- `references/concurrency.md` — load for threads, `concurrent.futures`, queues, multiprocessing start methods, `InterpreterPoolExecutor`74- `references/layout-tooling.md` — load for `pyproject.toml`, ruff/mypy/pytest, removed stdlib modules75- `references/performance.md` — one-screen "don't micro-optimize here"; real measurement is `python-performance`