mir-backend-pythonlisted

Make It Right (Python runtime tier). CPython runtime reliability footguns that are shared across EVERY Python backend framework (FastAPI, Django, Flask, Celery) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GIL and the free-threaded build (PEP 703/779, officially supported since 3.14 but not the default), async-vs-sync 'coloring', blocking the event loop, choosing asyncio vs threads vs multiprocessing vs subinterpreters vs a worker queue, fork-safety of connection pools and the 3.14 forkserver default change, lazy annotations (PEP 649/749), serverless cold starts, dropped-task exceptions, and runtime-level security (unsafe deserialization, archive extraction, shell arguments, SSRF, packaging supply chain). TRIGGER when the backend runtime is Python — sits between mir-backend (generic) and the framework module (e.g. mir-backend-python-fastapi). SKIP for Node/JVM/Go/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-l
anantbhandarkar/make-it-right · ★ 15 · AI & Automation · score 81

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-python · Make It Right (Python runtime) The middle tier. `mir-backend` decides **what is correct** (any language). The framework module (e.g. `mir-backend-python-fastapi`) knows the **library's mechanics**. This tier owns what's true for **all Python backends because they run on CPython** — the concurrency model and process model that FastAPI, Django, Flask, and Celery all inherit. **Runtime assumed:** CPython 3.12+. Verified 13 Aug 2026: **3.14 is the current stable line** (first released 7 Oct 2025); 3.15 is in prerelease, due 1 Oct 2026; 3.13 is in bugfix; 3.12 and 3.11 are security-only; **3.10 reaches end-of-life in Oct 2026** — if the project is on it, an upgrade plan is a Gate 4 risk row, not a "later"; 3.9 died 31 Oct 2025. Load order: `mir-backend` → `mir-backend-python` → `<framework module>`. ## The CPython footguns AI walks into (framework-agnostic) ### 1. The GIL — still on by default, but "is there a GIL" is now a build choice Default CPython builds hold one interpreter lock, so **CPU-bound work does not run in parallel across threads** — it serializes and you pay context-switch overhead on top. That has not changed. What changed: CPython 3.14 promoted the **free-threaded build** from experimental to officially supported (PEP 779). It is a separate binary (`python3.14t`), not the default interpreter. | Situation | Do threads give CPU parallelism? | |---|---| | Default `python3.14` | No. GIL is on. | | Free-threaded `python3.14t` | Yes. | | Fr