Skip to content

Build Independently confirmed2 publishers 2 min read Published Updated

The Python Workers queue send that needed two imports now takes a plain dict

Cloudflare made Python Workers generally available on September 21, moving binding type conversion into the runtime and adding ASGI and WSGI connectors for FastAPI, Django and Flask. Outbound TCP still goes through JavaScript's connect().

The Engineer · Build desk

Send a correction

Illustration accompanying The Python Workers queue send that needed two imports now takes a plain dict
Generated illustration

What happened

  • Cloudflare made Python Workers generally available on September 21, making Python a fully supported language across its developer platform after a two-year beta.
  • Type conversion at the RPC boundary now happens inside the Workers runtime and the Python SDK, so platform bindings accept Python objects directly.
  • New WSGI and ASGI connectors run Django, Flask and FastAPI apps, with the Workers platform doing the job a Uvicorn or Gunicorn process would normally do.
  • For outbound TCP, the documented path is still JavaScript's connect() API, not a Python socket bridge.

Why it matters

  • What's now possible capability One Python service can now take an API request through FastAPI, call an orchestration library, send inference to Workers AI, enqueue work and write to R2 with no JavaScript service sitting between those steps, according to runtimewire.
  • Who has to decide decision Porting an existing service becomes an entrypoint change plus a dependency audit, and the audit decides it: any package that needs a native socket is still work, because WebAssembly compatibility does not carry those across.
  • What it costs cost The announcements describe capabilities and not startup latency, so a team porting a service has to measure Pyodide's interpreter load against its own traffic before committing.

Pyodide is CPython compiled to WebAssembly, loaded inside a V8 isolate [3]. Workers has supported WebAssembly since 2018, and the Python beta opened in April 2024 [4]. Everything in the GA release is shaped by that sandbox.

Call a binding and a Python object has to become the object the RPC layer expects on the JavaScript side. In the beta you wrote that conversion by hand: `from pyodide.ffi import to_js`, `import js`, then `self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))` [8]. Nobody typed `dict_converter=js.Object.fromEntries` happily. GA puts the conversion inside the Workers runtime and the Python SDK, so the send is `self.env.QUEUE.send({"key": "value"})` [9]. Two imports and a wrapper call collapse into one line [20].

Gyeongjae Choi, Dominik Picheta and Hood Chatham, who authored the announcement, wrote that the old boundary "required Python developers to keep the JavaScript environment and code in mind while writing Python Workers, and it was a common source of error for both humans and AI agents" [10][11].

The framework support leans on a contract Python already had. WSGI and its asynchronous counterpart ASGI let an application stay server-agnostic, so a connector only has to hand requests over in the shape the framework expects [14]. In a Python Worker the whole wiring for a FastAPI app is `Default = asgi.entrypoint(app)`, and a Django app goes through `wsgi.entrypoint(app)` [12].

Whether existing code deploys unchanged comes down to the requirements file. Cloudflare patched asynchronous Python HTTP clients to route through the Workers Fetch API, which is what lets the OpenAI library, LangChain and the Python MCP package run at all [16][15]. Those clients had expected low-level socket behaviour the WebAssembly sandbox did not provide [16]. Database access goes through Hyperdrive, which now covers PostgreSQL and MySQL for Python Workers [6]. Anything else that opens a native socket is still a porting problem, because WebAssembly compatibility does not make every socket-dependent package portable [7].

One more detail worth knowing before you plan an architecture around this: a Python Worker can be created inside another Worker using Dynamic Workers [18]. Cloudflare's own sample in the post is a FastAPI route that awaits `env.AI.run` against the model `@cf/openai/gpt-oss-120b` [17].

What to watch

  • Whether Cloudflare publishes Pyodide cold-start times and package size limits for GA Python Workers.
  • Whether a Python socket bridge lands so outbound TCP stops going through JavaScript's connect().
  • Which Python packages get Pyodide builds, and whether Cloudflare maintains a supported package list.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence60
Adoption
Not scored
Hype gap+20
Incentives65
Confidence70

Perspective Coverage

3 publishers
Builder
Builder 70%
Operator
Operator 20%
Investor
Investor 10%
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Cloudflare made Python Workers generally available on September 21st, turning Python into a fully supported language across its developer platform and removing the JavaScript conversion layer that complicated the two-year beta.

    Reported SupportedView cited source
  2. [2]

    Cloudflare's post says GA means Python is now a first-class, fully supported language on the Cloudflare Developer Platform, connectable to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues and Workflows.

    Reported SupportedView cited source
  3. [3]

    Python Workers execute through Pyodide, a version of CPython compiled to WebAssembly and loaded inside a V8 isolate.

    Reported SupportedView cited source
  4. [4]

    Cloudflare has supported WebAssembly in Workers since 2018 and opened Python Workers to beta in April 2024.

    Reported SupportedView cited source
  5. [5]

    For outbound TCP, the current documented path is JavaScript's connect() API rather than a Python socket bridge.

    Reported SupportedView cited source
  6. [6]

    Hyperdrive support for Python Workers now covers PostgreSQL and MySQL.

    Reported SupportedView cited source
  7. [7]

    Package and runtime constraints still matter, since WebAssembly compatibility does not make every native socket-dependent Python package portable.

    Reported SupportedView cited source
  8. [8]

    In the beta, sending a Python dictionary into a Cloudflare Queue required glue code: 'from pyodide.ffi import to_js', 'import js', and 'self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))'.

    Reported SupportedView cited source
  9. [9]

    Cloudflare has encapsulated the entire type conversion process within the Workers runtime and the Python SDK, so 'self.env.QUEUE.send({"key": "value"})' now works without any JavaScript.

    Reported SupportedView cited source
  10. [10]

    Cloudflare's announcement states that the previous approach "required Python developers to keep the JavaScript environment and code in mind while writing Python Workers, and it was a common source of error for both humans and AI agents."

    Reported SupportedView cited source
  11. [11]

    Cloudflare's GA announcement was authored by senior software engineer Gyeongjae Choi, Dominik Picheta and senior systems engineer Hood Chatham.

    Reported SupportedView cited source
  12. [12]

    Cloudflare provides workers.asgi and workers.wsgi packages; a FastAPI app can be wired with 'Default = asgi.entrypoint(app)' or 'await asgi.fetch(app, request, self.env)', and a Django app with 'Default = wsgi.entrypoint(app)'.

    Reported SupportedView cited source
  13. [13]

    Cloudflare has added WSGI and ASGI connectors for frameworks including Django, Flask and FastAPI, with the Workers platform taking the role normally filled by a web server such as Uvicorn or Gunicorn and translating requests into the structures those frameworks expect.

    Reported SupportedView cited source
  14. [14]

    Python has a standard contract for how web applications communicate with web servers, WSGI and its modern asynchronous counterpart ASGI, which allows developers to build applications that are completely server-agnostic.

    Reported SupportedView cited source
  15. [15]

    Cloudflare says Python Workers can now run packages including OpenAI's Python library, LangChain and the Python Model Context Protocol package.

    Reported SupportedView cited source
  16. [16]

    Those libraries previously ran into networking limitations because their HTTP clients expected low-level socket behavior missing inside the WebAssembly sandbox; Cloudflare patched asynchronous Python HTTP clients to route requests through the Workers Fetch API.

    Reported SupportedView cited source
  17. [17]

    Cloudflare's example code is a FastAPI route that awaits env.AI.run against the model '@cf/openai/gpt-oss-120b'.

    Reported SupportedView cited source
  18. [18]

    A Python Worker can be created inside another Worker using Dynamic Workers.

    Reported SupportedView cited source
  19. [19]

    Per runtimewire, a Python application can receive an API request through FastAPI, call an orchestration library, send inference to Workers AI, place work into a Queue and store output in R2 without introducing a JavaScript service between those steps.

    Reported SupportedView cited source
  20. [20]

    The beta Queue send took three lines of Python (two imports plus the wrapped send call) and the GA version takes one.

    Derived Supported
  21. [21]

    Neither the Cloudflare GA post nor the runtimewire writeup reports a latency, cold-start or benchmark figure for Python Workers.

    Derived Supported

Sources

2 independent publishers whose own reporting we read for this story.

  1. blog.cloudflare.com

    1 article · September 21, 2026

    Python Workers are now generally available
  2. runtimewire.com

    1 article · September 21, 2026

    Cloudflare makes Python first-class in Workers, no JavaScript chaperone required
  3. simonwillison.net

    1 article · September 21, 2026

    Cloudflare Python Workers are now generally available

Topics and entities

Topics