Python House Style Audit

Overview

House style for Python, framed as an audit: rather than carrying a rulebook while writing code, sweep the target (a diff, file, package, or repo) for violations and report them. The audit has two tiers: mechanical checks delegated to ruff, and judgment checks no linter can express. Frontier coding agents already write reasonable Python, so the checks below are limited to the residual house preferences worth checking.

Every default below is a preferred starting point. If a default conflicts with project constraints or worsens the outcome, follow the project and state the tradeoff and compensating controls (tests, observability, migration, rollback).

When to Use

• A Python change is complete and about to be committed or shipped: audit the diff as part of wrapping up.
• Asked to review, audit, sanity-check, or clean up Python code, or whether it meets standards.
• Choosing among reliability, configuration, typing/validation, boundary, or concurrency approaches: the matching tier 2 section is the house default.
• Deciding which validation checks a Python change needs.
• A project has no lint policy and needs one bootstrapped (tier 1 carries the baseline).