• Python Workers reached general availability on September 21, 2026, after roughly two years in preview, with Cloudflare wiring the runtime into Workers AI, R2, D1, and Hyperdrive bindings.
• The runtime compiles CPython to WebAssembly via Pyodide and runs it inside Cloudflare's V8-based workerd engine — a genuinely different execution model from a Linux-process Python deployment, not just a rebrand of the preview.
• Both the multiprocessing and threading standard-library modules are non-functional in the WebAssembly VM, which rules out concurrent inference batching, process-pool embedding generation, and much of the numerical Python ecosystem that leans on those primitives.
• Package compatibility runs through PEP 783's new PyEmscripten build target, so any C-extension-based ML library needs an Emscripten-built wheel — a pure-Python package alone is not sufficient.
• Cloudflare's GA announcement supplies no cold-start, throughput, or memory-limit benchmarks, leaving latency-sensitive AI-inference-routing decisions unverifiable from the primary source alone.

Cloudflare took Python Workers out of preview on September 21, 2026, roughly two years after first previewing the feature, declaring Python 'a first-class, fully supported language on the Cloudflare Developer Platform' and wiring it into bindings for Workers AI, its own hosted inference platform, alongside R2, D1, and Hyperdrive. For teams shipping AI features, that binding is the actual news — a native Python path to call models without routing through JavaScript glue. The mechanism behind it, unchanged since preview, is what limits how far that goes: Python code is compiled to WebAssembly via Pyodide and executed inside workerd, the same V8-based runtime that powers Cloudflare's JavaScript Workers.

What shipped, and why it's on our beat

GA means Cloudflare now supports standard Python web frameworks — FastAPI running async, Django and Flask over WSGI — as production Workers, wired directly into Workers AI for inference calls plus R2, D1, and Hyperdrive for storage and database connection pooling. That combination is the pitch for AI teams specifically: a single Python service can receive a request, call a hosted model through Workers AI, and persist the result, all inside Cloudflare's edge network without a separate compute tier. Local development runs through a pywrangler CLI, distributed on PyPI as workers-py, which simulates the stack via a 123MB workerd binary.

The mechanism: a WASM sandbox, not native CPython

Running CPython compiled to WebAssembly inside workerd is architecturally distinct from a normal Python process, and Cloudflare's documentation is explicit that this comes with real constraints rather than none. Package compatibility now runs through PEP 783's PyEmscripten build target: a C-extension-based package needs a wheel built for that platform tag, not merely a pure-Python one, to install at all. That requirement sits upstream of every AI/ML library that ships compiled extensions, which is most of the serious ones.

The consequential catch for AI pipelines

Cloudflare's own stdlib documentation confirms both the multiprocessing and threading standard-library modules are non-functional inside the WebAssembly VM. That directly forecloses the concurrency patterns AI pipelines commonly lean on — process-pool batch inference, multi-threaded embedding generation, parallel preprocessing across CPU cores. A single synchronous or async call out to Workers AI per request still works fine; a job that wants to fan out across processes to embed a batch of documents does not, full stop, regardless of how the code is restructured.

What Cloudflare didn't publish

Cloudflare's GA announcement includes no cold-start numbers, no throughput benchmarks, and no memory or CPU ceiling figures. That omission matters more for AI workloads than for a generic API: teams deciding whether to route model-calling glue code through a WASM-sandboxed Python Worker versus a native runtime are making a latency-sensitive call with no published data to check it against. Until Cloudflare or a third party publishes reproducible numbers, any performance comparison remains unconfirmed.

Who should ship this, who should wait

Teams building lightweight, single-call glue around Workers AI — a FastAPI endpoint that calls a hosted model and writes the response to D1 or R2 — get a legitimate, now-supported Python path with less operational overhead than standing up a separate service. Teams running parallel inference batching, multi-process embedding pipelines, or ML libraries with unported C extensions should not treat this as a migration target; the WASM sandbox forecloses exactly those patterns, GA label or not.

The verdict

Signal, with an asterisk: Python Workers GA is a real, usable option for edge-deployed, single-call AI glue code tightly bound to Cloudflare's own Workers AI, R2, and D1 stack — that part holds up on the primary documentation. It is Noise for anyone reading 'generally available' as 'run your Python AI pipeline here unchanged' — multiprocessing and threading are permanently off the table, C-extension ML packages depend on an immature PyEmscripten wheel ecosystem, and Cloudflare has published no performance numbers to back the latency story its edge pitch depends on.