It would be useful to add a WASM runtime to the standard library. Some useful code is written in C, Ruts, or other languages that are usually compiled to native code. That code could be compiled to WASM and executed at a moderate speed on all platforms instead of having to compile separate C extensions for all platforms your Python code might need to run on.
These runtime’s APIs are simple enough that it might be possible to have different WASM interpreters (depending on which Python implementation you are using) while keeping the same Python interface.
That’s a big ask. Maintaining such a thing wouldn’t be cheap, even if we relied on an external package (note how keeping libffi up for ctypes is a semi-regular pain point).
This all ties into a bigger discussion as to whether the stdlib should grow, stay the same, or shrink long-term.
My impression is that a WASM interpreter would have less churn than libffi. The only “weird” part is a single file per platform of assembly code to call C functions from WASM, that knows how to pass arguments in registers and on the stack - much more limited in scope than libffi. If you only wanted to expose Python functions from WASM you might not even need that. But you’d certainly find yourself fielding requests for C implementations of new things like https://wasi.dev/
Once you had the basic interpreter it wouldn’t matter if an interesting C or Rust algorithm was available in the standard library or not, as long as you didn’t mind it running at 1/12th the speed of native on a non-jitted WASM implementation. And it would be sandboxed.
They’re working on a C embedding API. When it is ready you will be able to embed many WASM implementations with the same API. https://github.com/WebAssembly/wasm-c-api
WebAssembly has unlimited prospects, but writing it to the standard library is also too radical for now, this comes from 1) wasm itself was not widely used 2) and it was not fully finalized (the unstable wasi, GC and multi thread .eg.)
The complaint is very real, but on the other hand, ctypes makes Python the perfect glue language. I think this is a long-term consideration, about “Add Webassembly WASM runtime to the standard library”.
I’m a big fan of cffi instead of ctypes. Could imagine a cffi-for-wasm to get higher level access to those libraries.
It would be a fun project to write a multiple-backends WASM extension module for Python, a client of the WASM embedding API, outside of the standard library.
Hi, there’s already some support for ffi on wasm that as been tested on an alternative wasm python implementation ( it could load a big part of PySDL2 with ctypes->ffi ) thanks to Brion Vibber’s work on libffi-wasm. It may be possible to add the cffi parser around that.
+1 for a runtime but only if as configurable as @mohanson’s pywasm for the system interface layer around a Wasm3 core which is really portable.
@dholth this is such a great idea! Congrats on the work on pywasm, looks great.
I’m a bit familiar with the ecosystem and maintain bunch of libraries (graphene, graphql, promises, snapshottest, validate_email, …) that I think would benefit from it.
As I’m now working in Wasmer, I’d be happy to champion the process to integrate and maintain a wasm runtime inside the Python standard library.
portability of those libraries across any operating system
real sandboxing of Python code coming from unsecure sources.
instrumenting/profiling/benchmarking wasm binaries with Python tools and in a consistent manner accross platforms.
running Python testsuites against a wasm-python from a decent host <3.
@saghul maybe you have any thoughts/advices about wasm3 vs other runtimes to share ? https://github.com/wasm3/wasm3/pull/120 seems a python bindings offering on its way.
I agree with @mohansen that it would be too radical to put WASM in the standard library just yet. However it would be great to have a project that focused on supporting more than one back end - that was more Python-centric than particular-WASM-implementation centric.
From time to time someone will ask to use a new C library in Python standard library or standard library adjacent code, especially if the library would be too complicate or too slow to implement in Python. If they can’t pass the incredibly high barrier of including this new C library in the standard library, then the proposed feature will be shot down. Although wheels mitigate this problem somewhat, it is difficult to maintain built code for every platform.
Once you have WASM as a given that changes. If you can compile your new algorithm to WASM then you can argue for your new feature for its merits and not against the limitations of Python. Only later would you have to consider whether it was worth the additional effort of including native code. This should allow Python to innovate much more quickly than it does today.
Integrating another runtime is not a small undertaking. There’s keeping up with the standards, security issues, etc. And then there’s the discussion of why WASM and not some other runtime?
So I would say that integrating WASM as a package in the stdlib is out of scope for it.