mir-backend-pythonlisted

Make It Right (Python runtime tier). CPython/PyPy 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 (threads give no CPU parallelism), async-vs-sync 'coloring', blocking the event loop, choosing asyncio vs threads vs multiprocessing vs a worker queue, fork-safety of connection pools, serverless cold starts, and dropped-task exceptions. 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-library mechanics (those live in the framework module).
anantbhandarkar/make-it-right · ★ 12 · API & Backend · score 83

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.11+ (the notes hold for PyPy except where GIL specifics differ). Load order: `mir-backend` → `mir-backend-python` → `<framework module>`. ## The CPython footguns AI walks into (framework-agnostic) ### 1. The GIL — threads are NOT CPU parallelism Python threads share one interpreter lock, so **CPU-bound work does not run in parallel across threads** — it serializes and you pay context-switch overhead on top. Threads only help **I/O-bound** work (the GIL releases during blocking I/O). - CPU-bound (parsing, crypto, image/ML compute) → `multiprocessing` / `ProcessPoolExecutor`, a native extension that releases the GIL, or offload to a separate service. Never "add threads" expecting speedup. - I/O-bound → threads or asyncio are fine. - This is the runtime-level reason the runtime-map says "SKIP Python for heavily CPU-bound / microsecond-latency paths." ### 2. Async/sync "coloring" — pick one model per path and don't mix carelessly An `async def` function can only be awaited from async context; a sync function that calls blocking I/O must not run on the