Python Code Review Patterns

Stack-specific rules loaded by dh:code-reviewer when pyproject.toml or *.py files are detected.

Read Review principles before applying these checks; it defines authority, applicability, evidence, and blocking criteria.

When available, load /python-engineering:standards-for-python-development; it owns the shared Python policy and contextual defaults. If that plugin is unavailable, use the checks below with the target's supported Python versions, contracts, and active tooling. Report the unavailable policy reference without making Python-engineering a prerequisite for review.

Type Annotations

• Check that public parameter and return annotations communicate the supported contract; apply the project's annotation gate, including explicit None returns where required.
• Contain justified Any, broad object, and unchecked casts at explicit dynamic or external boundaries with typed outputs. An explanatory comment alone does not establish safety, and replacing Any with broad object alone does not strengthen the contract.
• Match data shapes to their purpose: typed mappings where mapping behavior is required, typed value objects for internal data, and runtime validation where external data needs it. Do not require TypedDict for every cross-module value or migrate a coherent dataclass/Pydantic/mapping design solely for uniformity.
• Prefer native generics and union syntax for new code when the supported Python floor permits them; do not report supported existing syntax as a correctness defect.
• Check that a Protocol or ABC models a real substitutable contract; preserve the project's coherent choice.