Your Python Toolchain Is Costing You Real Money — And You're Probably Fine With That
Let's be honest. Most Python teams in 2026 are still running flake8, black, isort, and Poetry side by side like it's 2021. Three separate lint processes, a formatter that argues with your import sorter, a dependency manager with a 40-second install time, and a pyproject.toml that looks like it was configured by a committee. Nobody chose this setup deliberately — it just accumulated, sprint by sprint, like technical debt usually does.
The uncomfortable question: how much CI time does your team burn per week on tooling that has already been replaced by something an order of magnitude faster?
The Numbers Are Not in Your Favor
Ruff — a Python linter and formatter written in Rust — lints the entire CPython repository (680 000+ lines) in under 0.5 seconds. Flake8 takes 30–40 seconds on the same codebase. That's not a benchmark cherry-picked from a blog post. That's reproducible on your machine, today.
Do the math for your team. If lint runs on every PR and your pipeline takes 35 seconds just for code quality checks — across 10 engineers, 4 PRs a day — you're burning roughly 23 minutes of CI compute daily on a solved problem. Ruff collapses that to under a minute. Ruff replaces flake8, black, and isort as a single binary with zero configuration conflicts, because there's only one tool making decisions.
That's not hype. That's arithmetic.
Poetry Had Its Moment. uv Is What Happens Next.
uv is the dependency manager that Poetry should have been. Faster resolution, a readable lockfile, native PEP 735 support for dependency groups, and a single binary that also replaces pipx for tool management. The migration from Poetry to uv involves exactly three things: reformatting pyproject.toml to standard [project.dependencies], replacing poetry install with uv sync --frozen, and updating your CI cache path from Poetry's global store to ~/.cache/uv.
The result is reproducible builds that don't require Poetry to be installed anywhere — just uv. On a cold CI runner, uv sync on a medium-sized FastAPI service completes in under 8 seconds. Poetry on the same project: 45–60 seconds. This is the kind of improvement that makes DevOps people genuinely happy, which is rare enough to be worth mentioning.
Pyright Strict Mode Is Not a Punishment — It's a Safety Net You Didn't Know You Needed
The moment you enable Pyright strict mode on a real codebase, you get a red wall of errors. Most teams turn it off and go back to typeCheckingMode = "basic" within an hour. That's the wrong move. The errors it surfaces — untyped decorators, missing return annotations, unknown member types from third-party libraries — are real bugs waiting to happen in production, not style pedantry.
The trick is incremental adoption. Enable strict per-module, not globally. Fix reportMissingTypeArgument first — it's mechanical and automatable. Use ParamSpec to type decorators properly instead of reaching for Any. Add stub packages for boto3, requests, redis from PyPI rather than sprinkling # type: ignore everywhere and hoping for the best.
The Distroless Angle Nobody Talks About
Combining uv with a distroless Docker base image produces Python containers below 80 MB with no shell, no package manager, and no attack surface beyond what your application actually needs. The multi-stage Dockerfile pattern — uv in the builder stage, gcr.io/distroless/python3-debian12 as runtime — is reproducible, auditable, and passes most enterprise security scans without extra hardening. It also forces the architectural discipline of proper logging and tracing instead of docker exec debugging, which is where containerized services should be anyway.
The full write-up covers all of this in detail — real pyproject.toml configs you can copy directly, the exact Dockerfile with uv sync and nonroot user, Pyright strict error categories ranked by fix complexity, private PyPI index configuration in uv, and a minimal microservice template that ditches setup.py, requirements.txt, and every other config file that doesn't belong in a modern Python project.
Full article with configs, Dockerfiles, and Pyright fixes: the complete version is available on https://krun.pro/python-modern-toolchain/ — written for developers who've already heard the pitch and want the implementation details.
