coddpiece is a relational-algebra teaching library for Python. You build an algebra expression by method-chaining; it compiles that expression to real SQL and runs it on any DB-API 2.0 connection, including the sqlite3 module that already ships with Python. The thesis is simple: learn the algebra first, and most of SQL’s apparent complexity turns out to be surface syntax over

checked is a small, standard-library-only package for state objects whose constraints are enforced on every assignment, not just at construction. You declare fields with annotations, attach rules, and from then on the object cannot hold a value that violates them. If you have used Pydantic, you are reading that sentence with a raised eyebrow, because it sounds like Pydantic.

Cygnet is a small, fierce, PostgreSQL-only ORM for async Python, and its whole personality is that it refuses to hide the SQL. Most ORMs exist so you never have to think about the query; Cygnet exists for the opposite kind of person, the one who already knows what SQL they want and would just like some help writing it without

Poveglia is named after the Venetian island that served as a quarantine station for ships arriving with plague aboard, holding the dangerous cargo offshore until it was known to be safe. The library does the same for the files your users upload: it quarantines them at the door and runs them through a pipeline of classifiers before any of it

django-pgware is the successor to django-pglocks, and it absorbs two siblings on the way: django-pg-set (temporarily setting GUCs) and pg-hush-django (keeping sensitive query parameters out of the logs). Three small single-purpose packages I’d maintained separately are now one distribution, one version, one test matrix. The import root stays django_pg_utils, so existing call sites change a prefix and nothing

waxsql generates SQL the way a bowl of wax fruit fills a centerpiece: it looks real, it nourishes nothing, and it will never spoil. Every query it produces is type-correct against a real PostgreSQL schema and computationally pointless, which is exactly what you want when you are fuzzing a query rewriter, beating on a parser, or generating a reproducible workload

I am putting this here to remind myself that unless you actively delete them, .pyc files from .py files that no longer exist can hang out and cause all kinds of weird and exciting problems, and part of your deploys should be to delete all .pyc files.