21–30 of 175 posts
It may be a stupid question, but is there already some DOM access or a dedicated package that allows writing web applications in this compiled python?
https://blog.pyodide.org/posts/react-in-python-with-pyodide/
Similar examples for raw DOM manipulation should be available for Pyodide as well. It has bindings to all JS code, so it can do everything that JS can do.
So I had a look at the repo/branches at https://github.com/wasmerio/py2wasm . This might be a nit, but in the spirit of OSS: if I'd done this work, I'd have contributed it to upstream Nuitka. I definitely would not have forked a whole new GitHub repo and given it a completely different name. What's the rationale for creating a new project and calling it py2wasm? Am I missing something?
So I had a look at the repo/branches at https://github.com/wasmerio/py2wasm . This might be a nit, but in the spirit of OSS: if I'd done this work, I'd have contributed it to upstream Nuitka. I definitely would not have forked a whole new GitHub repo and given it a completely different name. What's the rationale for creating a new project and calling it py2wasm? Am I missing something?
Reading the blog post- they are contributing it upstream
Earlier quoted context omitted.
Last we checked for one of our use cases around sandboxing, key pydata libraries were slowly moving there, but it takes a village. At that time, I think our blockers were Apache Arrow, Parquet readers, and startup time. There were active issues on all three. The GPU & multicore thing is a different story.as that is more about Google & Apple than WASM wrt browsers, and I'd be curious about the CUDA story serverside. W…
Pyarrow is giving a headache trying to get it compiled with Emscripten
So I had a look at the repo/branches at https://github.com/wasmerio/py2wasm . This might be a nit, but in the spirit of OSS: if I'd done this work, I'd have contributed it to upstream Nuitka. I definitely would not have forked a whole new GitHub repo and given it a completely different name. What's the rationale for creating a new project and calling it py2wasm? Am I missing something?
We already opened a PR into Nuitka to bring the relevant changes upstream: https://github.com/Nuitka/Nuitka/pull/2814
We envision py2wasm being a thin layer on top of Nuitka, as also commented in the article (not a fork as it is right now, although forking got us into the proof of concept a bit faster!).
From what we gathered, we believe that there's usefulness on having py2wasm as a separate package, as py2wasm would also need to ship the precompiled Python distribution (3.11) for WASI (which will not be needed for the other Nuitka use cases), apart of also shipping other tools that are not directly relevant for Nuitka
It's could be a new interpreter, or maybe a version of CPython that uses WasmGC structs for all Python objects, or a compiler similar to this but that targets WasmGC directly.
I want the opposite. The Python VM is everywhere. Can't I just run my WASM on Python? (The WASM runtime must be pure Python, installing C/C++ extensions is against the spirit of this.)
> py2wasm converts your Python programs to WebAssembly, running them at 3x faster speeds This is clearly written in the article, but I hope that the impatient readers will understand that this is 3 times faster than the CPython wasm, not the native CPython.
i'd be curious to see this benchmark extended, as in my own experience toying with python-like interpreters, you get ~2x slowdown (like their end result) from just compiling to wasm/wasi with clang and running in any 'fast' runtime (e.g. node or wasmtime).