WebAssembly, or Wasm, provides a standard way to deliver compact, binary-format applications that can run in the browser. Wasm is also designed to run at or near machine-native speeds. Developers can write code in one of the various languages that compile to Wasm as a target (e.g., Rust), and deliver that program anywhere Wasm runs.
But Wasm by itself isn’t enough. An application, especially one running in a browser, needs standardized and controllable ways to talk to the rest of the system. The WebAssembly specification doesn’t speak to any of that by design. It only describes the WebAssembly instruction set; not how programs using those instructions deal with the rest of the system.
That’s what the WASI standard provides—abstractions for using the host system, such as how to perform network and storage I/O, and using host resources like clocks or sources of entropy for PRNGs.
Until now, CPython has supported WASI, but not in a formally defined way. Nothing described how CPython would support versions of WASI (the spec), or the WASI SDK (an implementation of the spec). With PEP 816, the CPython team has formally defined how to support both the spec and the SDK going forward.
Ultimately, the new definition will make it easier to deliver Python apps in the browser or anywhere else Wasm runs. There are just a few things developers need to know to ensure they’re using Wasm correctly with Python under the new rules.
How Python has historically used Wasm
Most languages, such as Rust, compile to Wasm as a binary target. Because Python is interpreted—at least, the default CPython implementation works that way—it doesn’t compile to Wasm directly. Instead, the interpreter itself is compiled to Wasm, and Python programs are run on that Wasm version of the interpreter.
There are drawbacks to this approach. For one, it means you need a full copy of the interpreter and the standard library to run any Python program. There is as yet no mechanism to compile a Python program for Wasm that would either include a copy of the interpreter or make it self-contained.
Another big drawback: Any modules not written in pure Python can’t run in Wasm unless a Wasm-specific version of that module is compiled ahead of time. Unless you have a specially compiled version of, say, NumPy, you can’t use that module in Wasm.
Some of these issues are limitations of Python as a language. Its inherent dynamism makes it difficult to deploy a standalone program. Rust, by contrast, can compile to a single binary artifact for any supported target.
But some of these limits can also be attributed to the Wasm environment. For instance, many methods in the standard library aren’t available in Wasm enviroments because the WASI SDK doesn’t expose the needed interfaces for those methods. The more Python and other languages demand such things, the more likely they are to show up in the Wasm environment.
This is where it is useful for Python to be explicit about which versions it’ll use for both Wasm and its software development kit (or SDK) going forward. Each version of Python can then provide better guarantees about the Wasm features it supports.
Wasm support in Python: WASI and the WASI SDK
Wasm support involves two things: WASI and the WASI SDK. The difference between the two is a little like the difference between the Python language in the abstract and the CPython runtime. The former (WASI) is the spec for how Wasm programs interact with the host system, which can be implemented any number of ways. The latter (the WASI SDK) is the official implementation of that spec.
The WASI SDK is a modified version of the Clang compiler, which uses a library called wasi-libc. This gives programs written in C (and C API-compatible languages) access to WASI’s APIs for the host (storage, networking, timers, etc).
In theory, we should just be able to compile a given CPython release with the most recent WASI SDK at the time. But things aren’t that simple. For one, the SDK’s biggest component, wasi-libc, doesn’t guarantee it’ll be forward- or backward-compatible. Also, some versions of the SDK may cause buggy behavior with some versions of CPython. As developers, we want to know that this version of CPython works with this version of the SDK—or at least be able to document which bugs appear with any given combination of the two.
How future releases of CPython will use WASI
CPython has been available on Wasm since version 3.11, with Tier 2 and Tier 3 support. The more official wasip1 is the better-supported target, while the older emscripten standard is the less-supported version. But Tier 2 support has been confined to the WASI “Preview 1” set of system calls. And for the reasons already stated, the WASI SDK CPython uses is not necessarily the most recent version, either: it’s SDK version 21 for Python 3.11 and 3.12, and SDK version 24 for 3.13 and 3.14.
All of this will change with future releases of CPython, with a couple of hard rules in place for using WASI and its SDK:
- Any version of WASI or the WASI SDK supported by a given CPython version by its beta 1 release will be the version supported for the lifetime of that CPython release. For instance, if CPython 3.15 uses version 0.3 of the WASI spec and version 33 of the SDK (these are arbitrary numbers), then that version of WASI and the SDK will be supported for that version of CPython until it is formally sunsetted.
- Any changes to the version of the WASI spec or SDK used for a particular release requires approval from Python’s steering council. But this shouldn’t happen outside of some extraordinary set of circumstances—for instance, if a bug surfaced that made a given version of the SDK unusable with a given CPython release.
The benefits of WASI version guarantees for CPython
Going forward, developers can look forward to significant improvements to how Python will work with WASI:
- It won’t only be easier for CPython developers to know which versions of WASI and the SDK to target. It will also be easier for the rest of the WASI ecosystem to determine which Python versions are compatible with various WASI and SDK editions.
- Developers maintaining Python libraries with extension modules will have a better idea of how to compile those modules to Wasm for each Python point release. They will then be able to take advantage of newer WASI features sooner, knowing that a specific CPython will support them.
- Developers can add WASI support to their projects for a given version of CPython sooner in each release cycle for the interpreter, as the WASI and SDK versions should be locked down by the first beta release.
Go to Source
Author:
