python
Python services, tooling and the packaging around them.
-
One Local Endpoint for Every Agent Session
An IDE assistant, a terminal agent and a background daemon can each be configured to send code to a different endpoint, and nobody can answer where code actually goes without checking every tool individually. This article routes all of them through one local proxy that logs and can refuse requests, with a complete Docker Compose example and an honest account of what it doesn't guarantee.
-
Testing an Agent Harness Without Ever Calling the Model
A coding agent's permission decisions are ordinary deterministic code, but testing them by running the model end to end is slow, expensive and non-reproducible. Separating the decision layer from the model and recording real tool-call shapes as fixtures makes the whole thing testable with an ordinary unit-test suite, in milliseconds, with no API key required.
-
A Deterministic Daemon That Turns a Labelled Issue Into a Pull Request
Letting a model call git directly makes every commit and push as unpredictable as the model's own reasoning, which is hard to audit and harder to trust. This walks through splitting an issue-to-PR pipeline so the model only ever produces a patch, while a small deterministic daemon performs every side effect, with a complete runnable example.
-
The Transactional Outbox: Never Losing a Job You Already Committed
Committing a database change and then enqueueing a job as two separate steps leaves a gap in which the change is permanent but nothing ever runs the job and nothing notices. This works through the transactional outbox pattern and gives a complete, runnable Postgres, Redis Streams and Python implementation that survives a crash at any point in that gap.
-
Building the Dry-Run Path First, and Testing That It Sends Nothing
A dry-run flag added after the real logic is written tends to fall out of sync as the real path grows new side effects nobody remembers to gate. This describes structuring a tool so planning and execution are separate from the start, and writing a test that proves dry-run mode sends nothing.
-
Idempotent Payment Webhooks with a Deduplication Table
Payment providers deliver webhooks at least once and retry on anything but a 2xx response, so a handler that is not explicitly idempotent will eventually process the same payment twice. This covers signature verification, a deduplication table with a unique constraint, and a transactional handler that makes redelivery a no-op, with a complete example and a test that proves it.
-
Modelling an Order Lifecycle as an Explicit State Machine
When any code path can set order.status to any value, an invalid transition is caught only by whoever remembers to check for it, and eventually nobody does. This walks through modelling the lifecycle as an explicit state machine that rejects illegal transitions by construction, with a complete, tested implementation.
-
Migrating Redis Consumers from Python to C++ on Constrained Hardware
A dozen Python processes each blocked on a Redis stream look harmless until you add up their idle cost on a small device. Here is how to replace just that consume loop with a C++ equivalent, built and run through Docker so you can measure the trade-off yourself instead of taking anyone's word for it.
-
UUID Case Normalization as a Recurring Cross-Service Bug
An uppercase UUID from one service and a lowercase one from another look identical to a person and different to a dict, a cache, or a database index, which turns one entity into two without raising an error. Here is a minimal reproduction of the bug and a boundary-normalisation fix with a test that keeps it fixed.
-
Chaining Single-Purpose Redis Consumers into a Processing Pipeline
A single service that detects, tracks, calibrates and computes statistics over the same data becomes impossible to test or scale in isolation. This splits that service into four single-purpose consumers chained through Redis Streams, using consumer groups for at-least-once delivery and XAUTOCLAIM for crash recovery, in a complete example a reader can run against a local Redis container.
-
A Python CLI That Scaffolds a Project Structure You Actually Want
Starting a new service usually means recreating the same src layout, Dockerfile and ignore rules by hand, or copying them from whichever previous project is open in another tab, drifting a little further from a consistent shape each time. This builds a small, dependency-free scaffolding CLI that generates a project from a fixed template, and a test that checks the result is actually valid.
-
Replacing pip, venv, flake8, black and isort with uv and Ruff
A requirements.txt file records no lockfile, so "pip install -r requirements.txt" can resolve a different dependency tree on two machines run a day apart, and four separate lint tools mean four configuration blocks that drift out of sync. This walks through replacing pip, venv, flake8, black and isort with uv and Ruff, with a project a reader can build and lint in a few minutes.
-
Configuration Precedence: Docker Secrets, Kubernetes Secrets, Environment, .env, Default
A service that reads configuration only from environment variables forces every deployment target to shoehorn secrets into that one mechanism, and nothing in the code says which value wins when two sources disagree. Here is a small, tested resolver with a fixed precedence order, and the tests that prove it behaves the same in Compose, in Kubernetes and on a laptop.
-
An Exception Hierarchy and One Handler for FastAPI Error Responses
Raising HTTPException directly from inside route and service code gives every error path its own idea of what the response body should contain, and throws away the specific context that would make the error debuggable. This builds a small domain exception hierarchy and a single handler that turns any of them into a consistent, informative response.
-
Designing a Consistent FastAPI Response Envelope
When some endpoints return a bare object, others a list, and others a hand-rolled dict with a status field, every client has to special-case each one. This works through a generic response envelope built on Pydantic generics, a custom route class that applies it without repeating boilerplate in every endpoint, and the trade-offs that come with wrapping everything uniformly.
-
A Feature-Module Layout for a FastAPI Application That Keeps Growing
A FastAPI project that starts as one main.py and one routers.py works fine for the first few endpoints, then becomes a file everyone edits and nobody owns. This lays out a feature-module structure where each feature carries its own router, schemas and service code, with a complete runnable example and a test proving a new feature needs no change to existing files.