hoodchatham (u/hoodchatham)

hoodchatham commented on Python on the Edge: Fast, sandboxed, and powered by WebAssembly wasmer.io/posts/python-on... · Posted by u/baalimago

simonw · 3 months ago

OK got there in the end! I didn't time it but felt like around 10 minutes or more.

It did give me one warning message:

  % wasmer run python/python
  Python 3.13.0rc2 (heads/feat/dl-dirty:152184da8f, Aug 28 2025, 23:40:30) [Clang 21.1.0-rc2 (git@github.com:wasix-org/llvm-project.git 70df5e11515124124a4 on wasix
  Type "help", "copyright", "credits" or "license" for more information.
  warning: can't use pyrepl: No module named 'msvcrt'
  >>>

hoodchatham · 3 months ago

It says the same thing in the pyodide repl for what it's worth.

hoodchatham commented on When Is WebAssembly Going to Get DOM Support? queue.acm.org/detail.cfm?... · Posted by u/jazzypants

jauntywundrkind · 5 months ago

Law of question marks on headlines holds here: no / never seems to be the answer.

Article l also discussed ref types, which do exist and do provide... Something. Some ability to at least refer to host objects. It's not clear what that enables or what it's limitstions are.

Definitely some feeling of being rug-pulled in the shift here. It felt like there was a plan for good integration, but fast forward half a decade+ and there's been so so much progress and integration but it's still so unclear how WebAssembly is going to alloy the web, seems like we have reams of generated glue code doing so much work to bridge systems.

Very happy that Dan at least checked in here, with a state of the wasm for web people type post. It's been years of waiting and wondering, and I've been keeping my own tabs somewhat through twists and turns but having some historical artifact, some point in time recap to go look at like this: it's really crucial for the health of a community to have some check-ins with the world, to let people know what to expect. Particularly for the web, wasm has really needed an update State of the Web WebAssmebly.

I wish I felt a little better though! Jco is amazing but running a js engine in wasm to be able to use wasm-components is gnarly as hell. Maybe by 2030 wasm & wasm-components will be doing well enough that browsers will finally rejoin the party & start implementing new.

hoodchatham · 5 months ago

Reference types makes wasm/js interoperability way cleaner and easier. wasm-gc added a way to test a function pointer for whether it will trap or not.

And JSPI is a standard since April and available in Chrome >= 137. I think JSPI is the greatest step forward for webassembly in the browser ever. Just need Firefox and Safari to implement it...

hoodchatham commented on Show HN: Online Python Compiler with Libraries cliprun.com/online-python... · Posted by u/andycloke

metadat · 9 months ago

  import requests 
  
  r = requests.get('https://theonion.com')
  
  print(r.text)

Hmm, I wonder if you could use subprocess to fetch and run any binary. What kind of sandbox is this running in, and what are the limits?

Running arbitrary untrusted code seems like a potential security issue.

Edit: @porridgeraisin Got it, thanks! Does this mean outbound http requests only work with domains that support arbitrary requests via `Access-Control-Allow-Origin: *` ?

hoodchatham · 9 months ago

Yes, it has all the normal CORS restrictions. If you're curious, the PR that added support for this is here: https://github.com/urllib3/urllib3/pull/3195

hoodchatham commented on A possible future of Python in the browser lukasz.langa.pl/f37aa97a-... · Posted by u/milliams

svilen_dobrev · 10 months ago

very interesting. So all the declarative stuff, like various type descriptions and preconditions and such, can be precompiled.. (and i am not talking about type-hints/annotations). Maybe some of the meta-programming stuff too.

i was thinking some weeks ago that it may be time to "fork" python - as language - in a way to preserve the initial simplicity and clarity it did have and is losing faster and faster. But, nevermind. Will have to live with whatever there is.

edit: looking at the code, some things might be optimized but no idea if these are on critical path (like, that switch-by sq_idx, or 6 lines.append.. ), or whether func-calls are as expensive in Spy as they are in Cpy. But anyway, squeezing few percents is not the point.. if one needs magnitudes.

hoodchatham · 10 months ago

The actual code example he made runs about 100 times faster in Spy/emscripten than in Pyodide.

hoodchatham commented on Python Cloudflare Workers blog.cloudflare.com/pytho... · Posted by u/jasoncartwright

panqueca · 2 years ago

Does this architecture supports uvloop?

hoodchatham · 2 years ago

Pyodide uses its own event loop which just subscribes to the JavaScript event loop. My suspicion is that this will be more efficient than using uvloop since v8's event loop is quite well optimized. It also allows us to await JavaScript thenables from Python and Python awaitables from JavaScript, whereas I would be worried about how this behaves with separate event loops. Also, porting uvloop would probably be hard.

hoodchatham commented on Python Cloudflare Workers blog.cloudflare.com/pytho... · Posted by u/jasoncartwright

syrusakbary · 2 years ago

> pyodide /package versions will be controlled by the compatibility date

That's exactly the issue that I'm mentioning. Ideally you should be able to pin any Python version that you want to use in your app: 2.7, 3.8 or 3.9 regardless of a Workerd compatibility date. Some packages might work in Python 3.11 but not in 3.12, for example.

Unfortunately, Python doesn't have the full transpiler architecture that JS ecosystem has, and thus "packaging" Python applications into different "compatibility" bundles will prove much more challenging (webpack factor).

> Could you expand on why you believe V8 will be a limiting factor?

Sure thing! I think we probably all agree that V8 is a fantastic runtime. However, the tradeoffs that make V8 great for a browser use case, makes the runtime more challenging for Edge environments (where servers can do more specialized workloads on trusted environments).

Namely, those are:

  * Cold starts: V8 Isolates are a bit heavy to initialize. On it's current form it can add up from ~2-5ms in startup just by initializing an Isolate
  * Snapshots can be quite heavy to save and restore
  * Not architected with the Edge use case in mind: there are many tricks that you can do if you skip the JS middleware and go all in into a Wasm runtime, that are hard to do with the current V8/Workerd architecture.

In any case, I would love to be proven wrong on the long term and I cheer for <100ms cold starts when running Python in Cloudflare Workers. Keep up the good work!

hoodchatham · 2 years ago

Are people maintaining wasi ports of Python 2.7 and 3.8?

hoodchatham commented on Python Cloudflare Workers blog.cloudflare.com/pytho... · Posted by u/jasoncartwright

pelletier · 2 years ago

I'm curious to see how the limitation of using pyodide packages only will play out for non-trivial builds. Thinking of all the non-pure python code out there that need to be manually rebuilt to support a non-trivial production app.

Maybe Cloudflare's adoption will help bring more packages into the fold, and if it's an 80/20 rule here, would be good enough.

hoodchatham · 2 years ago

I certainly think there's an 80/20 rule here. Most packages are not very hard to port, and generally the ones that are hard to build use features like threads and multiprocessing, graphics cards, raw sockets, green threads, or other capabilities that have no obvious analogue in a webassembly runtime.

As we mention in the blog post, the biggest issues are around supporting server and request packages since they are clearly useful in cloudflare workers but are difficult to port because they frequently use raw sockets and some form of concurrency.

hoodchatham commented on RustPython rustpython.github.io/... · Posted by u/BerislavLopac

jsheard · 2 years ago

> I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application.

Indeed, the web demo takes about 5 seconds to cold-start on my beefy PC, between downloading the 22MB WASM blob and compiling it. It also grows the WASM heap to 160MB after running the simple Fibonacci example, and WASM heaps can't (yet) be shrunk, so the only way to reclaim any of that memory is to discard the whole instance and start over.

It's cool that it works, but not very practical.

hoodchatham · 2 years ago

As far as I'm aware, even discarding the instance isn't good enough, since v8 doesn't seem to reclaim the Wasm Linear Memory ever. I think the only thing you can do is start it in a worker and then terminate the entire worker.

hoodchatham commented on Python HTTP library 'urllib3' now works in the browser github.com/urllib3/urllib... · Posted by u/SethMLarson

hoodchatham · 2 years ago

aiohttp is still work in progress but it works with a monkey patch. https://github.com/aio-libs/aiohttp/pull/7803

hoodchatham commented on PyScript: Run Python in your HTML pyscript.net/... · Posted by u/gripfx

hoodchatham · 4 years ago

> Why?

This isn't good for most web use cases but there are some major new use cases that it enables.

Pyodide is in Python documentation all over the place, for instance on https://numpy.org/

Python has many libraries that JS is missing. Particularly the scientific computing ecosystem has a lot of very well supported Python packages but fewer JavaScript packages. They also can benefit a lot from connection to a UI.

Two key use cases for this stuff are Python education and scientific computing. Students have a hard time installing Python locally. Generally scientists want to share their results broadly, but they probably did their analysis in Python.

Here's another example of a good use case: https://www.socialfinance.org.uk/blogs/analysing-sensitive-d...

hoodchatham · 4 years ago

To be clear these are all use cases of Pyodide. PyScript only was released two days ago so it's harder to point to real world uses.