One of the painful aspects of WASM is there's no blocking calls. You can't say "wait for the next event;" instead you must return to the outermost event loop, and wait to be called back.<p>How does Python-in-WASM work around that? For example, how does `for line in sys.stdin:` work if you can't actually block on stdin?<p>Emscripten has some support for this via the "asyncify" transform, which layers additional control flow to enable return all the way up the call stack, and then "rewind" back down into it. But this bloats the code (and is also buggy) so maybe it's not being used.
Although it's only Python 2.7, cpython-based games have been running in the web browser for years.<p><a href="https://beuc.itch.io/the-question-web" rel="nofollow">https://beuc.itch.io/the-question-web</a><p>(I'm the lead developer of Ren'Py, though Sylvain Beucler did most of the work. He also has a 3.8 port here: <a href="https://www.beuc.net/python-emscripten/python/dir?ci=tip" rel="nofollow">https://www.beuc.net/python-emscripten/python/dir?ci=tip</a> )
It's a pity WASM and all the tech around it wasn't available 20 years ago when Javascript was added to the browser, we'd all be using python now and node.js wouldn't exist at all ;)
Guido responded and wondered if this could be integrated into github.dev for Python work in the browser without remote compute. That’s a very cool idea, but I wonder if this would work any better with the usual suspects (pandas, numpy, mathplotlib) than the other attempts like pyodide which make more modifications to CPython.
What is the novelty here?<p>E.g. we have <a href="https://github.com/pyodide/pyodide" rel="nofollow">https://github.com/pyodide/pyodide</a> and other examples.<p>The cool part here is Emscripten, which has been around for a long time.
I imagine the biggest downside of this approach is simply the size of the CPython implementation. Does anyone know how big it is when compiled to WASM?<p>I wonder if anyone has tried the same approach using MicroPython.
This is it. This is the beginning of a revolution. Prepare your fork-picks.<p>Jokes aside, JS ecosystem really needs a competitor. Web developers have been cutting corner after corner for decades, with ever increasing disregard for performance and memory consumption.<p>Now with both Python and Rust in the browser, things may change for the better.
<a href="https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript" rel="nofollow">https://www.destroyallsoftware.com/talks/the-birth-and-death...</a>
Just a matter of time now.
This looks exciting. If anyone knows how to, perhaps they can report how much space this uses in the browser? Some benchmarks? Someday soon I hope we can use this for developing code on the browser to aid with web applications.
Very cool, I did some experiments with libxml on a WASI environment a few years ago (<a href="https://github.com/matiasinsaurralde/wasm-libxml2" rel="nofollow">https://github.com/matiasinsaurralde/wasm-libxml2</a>).