Python Workers are now generally available

Posted by torutofu 1 day ago

Comments

Comment by illia-v 1 day ago

> we contributed upstream to ensure these HTTP clients can route requests directly through the JavaScript `fetch` API in WebAssembly environments

Some context from an urllib3 maintainer:

urllib3 received and merged large contributions adding Pyodide/Emscripten support a few years ago, and later JSPI support, which is what made this work for Requests.

As far as I know, the funding for this work went to the external contributor who implemented it, not to the urllib3 maintainers. We reviewed and merged the changes, and the project is now responsible for maintaining the resulting backend.

This matters because the Emscripten backend is still considered experimental in urllib3, and is explicitly out of scope in our security policy.

CVE-2025-50182 is one example of the problems we've run into. urllib3's redirect controls did not have the expected behavior when requests were routed through `fetch`. There are potentially many more differences like this because browser/`fetch` networking semantics are quite different from urllib3's normal backend.

I'm glad the work was contributed upstream and is useful to Pyodide and Cloudflare. But I think there is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers who have to support it afterwards.

Comment by syrusakbary 1 day ago

I think this showcases the other issue I commented a few years ago [1].

Pyodide and Cloudflare don't use the real network stack for http requests (they patched the functions to use JS `fetch` underneath). They also patched Python's async event loop to use JS event loop.

This has a major downside: incompatibility issues. JS event loop is preemptive (async functions get called regardless of you calling await on them) while Python is lazy (async functions only execute when you await them).

In my belief, the network semantics should be preserved. When the behavior differs issues start arising.

[1] https://news.ycombinator.com/item?id=39907240

Comment by hoodchatham 21 hours ago

> JS event loop is preemptive

I think the word you want is "eager". Preemptive usually refers to things like signal handlers: when the signal is received the handler "preempts" normal execution without waiting for an explicit yield point.

In any case, with the WebLoop, Python coroutines stay lazy. The fundamental primitive a Python event loop needs to implement is call_later() which maps fairly cleanly to `setTimeout()`.

The reason we want to use the JS event loop is that the JS event loop is where all the actual I/O events in a JavaScript runtime happen. If you create a second event loop and run it, it will block actual IO on the JS event loop. So making uvloop work would be pointless.

Comment by syrusakbary 18 hours ago

> I think the word you want is "eager".

Yup, thanks for the correction! (and appreciate the extra insight!)

Comment by hoodchatham 21 hours ago

> Pyodide and Cloudflare don't use the real network stack for http requests

Pyodide in browsers _can't_ use the real network stack because of fundamental security principles of browsers. With direct networking you could get around the CORS restrictions.

Thanks to Gyeongjae Choi's work, Pyodide in Node/Cloudflare can use direct sockets. See this section of the blog post: https://blog.cloudflare.com/python-workers-ga/#using-postgre...

Comment by meagher 18 hours ago

> I'm glad the work was contributed upstream and is useful to Pyodide and Cloudflare. But I think there is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers who have to support it afterwards.

Any of the upstream maintainers consider blocking merge unless Cloudflare signs a support contract?

Not an easy process to navigate, but if you find an internal champion that can help make the case, maintenance can be funded. For critical deps, companies are generally down to budget some financial support if you ask and know how to work the process.

Comment by illia-v 5 hours ago

[dead]

Comment by pbreit 1 day ago

It always seemed so strange to me that "native" http clients were so lousy or many cases even non-existent considering that that's half of development these days.

Comment by syrusakbary 1 day ago

Great work from the Cloudflare team!

I was very excited when they first launched Python Workers two years ago. Even though we have competing products at Wasmer, I think Cloudflare work is always exciting and inspiring.

I went back to the feedback I posted in the original launch thread [1]. It's great to see that they have made meaningful progress since then, particularly around package support: PyEmscripten is now standardized through PEP 783.

That said, some of the main architectural concerns I raised at the time are still present:

  * Being tied to use only one version of Python/Pyodide (the one that Workerd embeds)
  * Architecturally tied to the JS/v8 world, which may show some challenges as they aim to reduce cold start times (in my opinion, it will be quite hard for them to achieve <100ms startup time with their current architecture).

In the benchmark we published earlier this year [2], a minimal Python application started in around 60ms on Wasmer Edge versus around 900ms on Cloudflare Workers (backing my concerns from 2024). Those numbers are now several months old, and I hope Cloudflare has improved them significantly since then.

The GA announcement doesn't seem to include updated cold-start numbers. Could someone from the Cloudflare team share the current p50/p95 cold-start times for Python Workers, ideally both with and without native user packages? (for example, one with FastAPI and other without any dependencies).

[1] https://news.ycombinator.com/item?id=39907120

[2] https://wasmer.io/posts/wasm-clouds-the-world-after-containe...

Comment by dom96 1 day ago

(I'm one of the authors of this post)

> Being tied to use only one version of Python/Pyodide (the one that Workerd embeds)

This isn't quite the case, you can choose between different versions using compatibility flags. For example, `python_workers_314` is the compat flag for Python 3.14[1]. You've also got compat flags for 3.13 and 3.12. Though it is worth noting that by using those older versions you will also be using older Pyodide versions too, which have fewer features (for example they lack JSPI support).

> Architecturally tied to the JS/v8 world, which may show some challenges as they aim to reduce cold start times

That is indeed a challenge. But our memory snapshot implementation has improved the cold starts significantly already and we will be working to reduce these even further. We also have sharding these days which reduces cold start frequency a lot. We wrote about cold starts (and sharding) in a previous blog post[2] which includes some numbers.

1 - https://developers.cloudflare.com/workers/configuration/comp...

2 - https://blog.cloudflare.com/python-workers-advancements/

Comment by syrusakbary 1 day ago

Thanks for chiming in!

> it is worth noting that by using those older versions you will also be using older Pyodide versions too

Yeah, I think this summarizes properly the issue I mentioned. Basically compat flags are a global version that affects not only the Python version used but workerd as well. I believe you'll see some architectural issues from this design. Following up on your example, users will not be able to use a previous version of Python that has JSPI included, unless you update the old workerd as well (please correct me if I'm wrong), which will make certain things a challenge as workerd evolves.

> We wrote about cold starts (and sharding) in a previous blog post[2] which includes some numbers

Thanks for sharing. On that blogpost [2] Cloudflare Python Workers startup time was reported to be about 1.027 seconds, which is way behind the numbers we have at Wasmer for cold starts in Python apps (60ms, or 16x faster). That's why I was asking if you guys remeasured and have better timings now :)

Comment by dsign 1 day ago

This is the tech at Cloudflare of course, but I swear that my first interpretation of the title was "We have replaced all our python coders with AI and they (the coders) are out and generally available" :-)

Comment by Joeboy 1 day ago

Yeah I initially read it as a headline about the grim state of the software dev jobs market.

Comment by FartyMcFarter 1 day ago

Yep - I immediately thought this was going to be some "Python SWE on the cloud for hire" service.

Comment by asdff 18 hours ago

Two more weeks

Comment by manquer 22 hours ago

Have we come back full circle back to GAE [1], launched in 2008 with Python 2.5 support ...

[1] https://googleappengine.blogspot.com/2008/04/introducing-goo...

Comment by stevefan1999 14 hours ago

Indeed. I still remember deploying GAE apps with Java WAR and Python Django as a kid 13 years ago. Then Heroku and now fly.io and Render. For me I went Docker and Kubernetes. Back then GAE has a really good free tier, so I used it to deploy a HTTP proxy to bypass school network

Comment by latchkey 17 hours ago

It is ok, other hosting companies are allowed to have their own implementations of good ideas.

Comment by stefan_lec 1 day ago

How do these perform for cold-starts? I remember one of the disadvantages of using web assembly for Workers was more spin-up time, but maybe they figured out a way around that.

Comment by dom96 1 day ago

We’ve got some cold start numbers in our previous blog post: https://blog.cloudflare.com/python-workers-advancements/.

There is still more to do here and it’s what we will be focusing on next.

Comment by aeyes 1 day ago

The cold start numbers on that blog post show that its faster than AWS Lambda but your linked benchmark page [1] shows that Lambda is not only much faster but also much more consistent.

[1] https://cold.picheta.me/#bare

Comment by dom96 1 day ago

It looks like that link is incorrect, it should be pointing at https://cold.picheta.me/#packages.

Comment by hbcondo714 1 day ago

Thanks, we've been using firecracker VMs with AWS MicroVM[1] and Fly.io Sprites[1] but interested in using Workers instead

[1] https://news.ycombinator.com/item?id=48642510

[2] https://news.ycombinator.com/item?id=46557825

Comment by amenghra 1 day ago

In many cases, the cold-start time might not be visible to users. E.g. if you serve your static content from a CDN, maybe you have stale content in local storage you can show while fetching updated data. If it all happens on a sub-100ms timescale, it should feel quite instant?

Comment by simonw 1 day ago

Pyodide is such a cool piece of the Python ecosystem. I hope Cloudflare consider throwing some money their direction: https://opencollective.com/pyodide/contribute

Comment by codingglass 1 day ago

100% agree. Hiring Hood a couple years ago was great money spent on that project (not that they shouldn't throw more cash at it =) )

Comment by simonw 1 day ago

Hah, I'd missed that Hood Chatham is one of the authors of the linked announcement! I think that counts as a solid level of sponsorship for Pyodide.

Comment by dom96 1 day ago

Gyeongjae, who is one of the authors too, is also a Pyodide core developer. Definitely couldn't have got Python Workers this far without both of their help.

Comment by codingglass 5 hours ago

Oh for sure! Met him at PyCon a few years ago, also an awesome contributor.

Comment by 22 hours ago

Comment by spicypixel 1 day ago

One day it’ll be similarly beautifully trivial to use go too. I hope.

Comment by vira28 1 day ago

Agree. Until then I will wait.

Still a welcome move that they finally added support from Python.

Comment by OutOfHere 1 day ago

Afaik, it's not possible to run Go on WASM.

Comment by ncruces 1 day ago

The Go compiler supports wasm/js (browser) and wasm/wasip1 (WASI) out-of-the-box.

Comment by karmakaze 1 day ago

They should support Mojo which might be a great fit for edge compute.

Comment by dangoodmanUT 10 hours ago

I haven't empirically tested, but considering how much heavier pyodide is than a v8 runtime, this likely eats in 10's of MBs more into the worker memory allocation.

Comment by victorbjorklund 1 day ago

Elixir next ;) with clustering across workers (kind of kidding because elixir probably does not make sense for CF workers)

Comment by xnx 22 hours ago

Amazing how PHP and Perl were so derided, and then ultimately reinvented.

Comment by pjc50 14 hours ago

? They competed with Python, and were generally (although PHP not entirely, due to WP) out-competed.