Some time ago I shared a strict Python project setup. I’ve since reworked and simplified it, and this is the new version.

pystrict-strict-python – an ultra-strict Python project template using uv, ruff, and basedpyright, inspired by TypeScript’s --strict mode.

Compared to my previous post, this version:

• focuses on a single pyproject.toml as the source of truth,
• switches to basedpyright with a clearer strict configuration,
• tightens the ruff rules and coverage settings,
• and is easier to drop into new or existing projects.

What it gives you

• Strict static typing with basedpyright (TS --strict style rules):
• No implicit Any
• Optional/None usage must be explicit
• Unused imports / variables / functions are treated as errors
• Aggressive linting & formatting with ruff:
• pycodestyle, pyflakes, isort
• bugbear, security checks, performance, annotations, async, etc.
• Testing & coverage:
• pytest + coverage with 80% coverage enforced by default
• Task runner via poethepoet:
• poe format → format + lint + type check
• poe check → lint + type check (no auto-fix)
• poe metrics → dead code + complexity + maintainability
• poe quality → full quality pipeline
• Single-source config: everything is in pyproject.toml

Use cases

• New projects:
  Copy the pyproject.toml, adjust the [project] metadata, create src/your_package + tests/, and install with:

```bash uv venv .venv\Scripts\activate # Windows # or: source .venv/bin/activate

uv pip install -e ".[dev]" ```

Then your daily loop is basically:

bash uv run ruff format . uv run ruff check . --fix uv run basedpyright uv run pytest

• Existing projects:
  You don’t have to go “all in” on day 1. You can cherry-pick:
• the ruff config,
• the basedpyright config,
• the pytest/coverage sections,
• and the dev dependencies,

and progressively tighten things as you fix issues.

Why I built this v2

The first version worked, but it was a bit heavier and less focused. In this iteration I wanted:

• a cleaner, copy-pastable template,
• stricter typing rules by default,
• better defaults for dead code, complexity, and coverage,
• and a straightforward workflow that feels natural to run locally and in CI.

Repo

👉 GitHub link here

If you saw my previous post and tried that setup, I’d love to hear how this version compares. Feedback very welcome:

• Rules that feel too strict or too lax?
• Basedpyright / ruff settings you’d tweak?
• Ideas for a “gradual adoption” profile for large legacy codebases?