# Add a WebAssembly WASM runtime **URL:** \ **Category:** Ideas\ **Created:** [April 20, 2020, 10:49pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957 "2020-04-20T22:49:08Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [April 20, 2020, 10:49pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/1 "2020-04-20T22:49:08Z")
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. [https://github.com/bytecodealliance/wasm-micro-runtime](https://github.com/bytecodealliance/wasm-micro-runtime) is one runtime. If it was incorporated into a Python extension module I think you’d want to poke around here: [https://github.com/bytecodealliance/wasm-micro-runtime/tree/master/core/iwasm/common/arch](https://github.com/bytecodealliance/wasm-micro-runtime/tree/master/core/iwasm/common/arch) to be able to expose Python functions to the runtime, without having to fake it with cffi or ctypes style techniques. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [April 21, 2020, 12:41am UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/2 "2020-04-21T00:41:57Z")
There’s also [GitHub - wasmerio/wasmer-python: 🐍🕸 WebAssembly runtime for Python](https://github.com/wasmerio/python-ext-wasm) if you want access to WebAssembly from within Python. > [@dholth](#): > > It would be useful to add a WASM runtime to the standard library. 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. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [April 21, 2020, 1:30am UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/3 "2020-04-21T01:30:55Z")
I had success with this pure-Python WASM implementation. It is not as fast as other implementations. [https://github.com/mohanson/pywasm](https://github.com/mohanson/pywasm) 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/](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](https://github.com/WebAssembly/wasm-c-api) I know that the road to a huge stdlib is paved with “only less than 100kb” dependencies, but [https://github.com/bytecodealliance/wasm-micro-runtime#iwasm-vm-core](https://github.com/bytecodealliance/wasm-micro-runtime#iwasm-vm-core) says its interpreter is 85kb. ---
**Author:** ![mohanson](https://avatars.discourse-cdn.com/v4/letter/m/e274bd/32.png) [@mohanson](https://discuss.python.org/u/mohanson)\ **Post date:** [May 14, 2020, 3:39pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/4 "2020-05-14T15:39:11Z")
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.) > [@brettcannon](#): > > note how keeping libffi up for ctypes is a semi-regular pain point 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”. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [May 14, 2020, 3:52pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/5 "2020-05-14T15:52:59Z")
Hi @mohanson! 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. ---
**Author:** ![pmp-p](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pmp-p/32/7632_2.png) [@pmp-p](https://discuss.python.org/u/pmp-p)\ **Post date:** [May 27, 2020, 3:02pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/6 "2020-05-27T15:02:36Z")
> [@dholth](#): > > Could imagine a cffi-for-wasm to get higher level access to those libraries. 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**. ---
**Author:** ![syrusakbary](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/syrusakbary/32/2267_2.png) [@syrusakbary](https://discuss.python.org/u/syrusakbary)\ **Post date:** [May 31, 2020, 12:04am UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/7 "2020-05-31T00:04:33Z")
@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](https://wasmer.io/), I’d be happy to champion the process to integrate and maintain a wasm runtime inside the Python standard library. Thoughts @brettcannon? ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [June 1, 2020, 7:52am UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/8 "2020-06-01T07:52:43Z")
What would be the benefits of a WASM runtime living in the standard library, rather than as an independent project? ---
**Author:** ![pmp-p](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pmp-p/32/7632_2.png) [@pmp-p](https://discuss.python.org/u/pmp-p)\ **Post date:** [June 1, 2020, 5:58pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/9 "2020-06-01T17:58:49Z")
I see various benefits at least : - sandboxing external libraries “safe wheels”. - 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](https://github.com/wasm3/wasm3/pull/120) seems a python bindings offering on its way. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [June 1, 2020, 7:14pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/10 "2020-06-01T19:14:36Z")
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. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [June 1, 2020, 7:38pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/11 "2020-06-01T19:38:54Z")
> [@syrusakbary](#): > > Thoughts @brettcannon? 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. ---
**Author:** ![dholth](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dholth/32/952_2.png) [@dholth](https://discuss.python.org/u/dholth)\ **Post date:** [June 1, 2020, 8:03pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/12 "2020-06-01T20:03:29Z")
I wonder how Python’s bytecode compares to WASM’s. ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [September 18, 2026, 4:13pm UTC](https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/14 "2026-09-18T16:13:07Z")