This and PEP-783 do remind me a bit of the story of watt (1) and serde_derive, where the latter was published containing a to WebAssembly compiled proc macro with the former as WebAssembly runtime (2).

It tried amonst others to improve isolation and long compile times in a fairly foundational Rust library which can be found in many dependency trees. I found it a cool proof of concept at the time.

Having a WebAssembly binary embedded in a library was relatively unpopular in the Rust community (3). serde_derive 1.0.184 restored the uncompiled source version, but the release notes mention they hope that crates.io (Rust equivalent of PyPi) will add WebAssembly support in the future.

One of the reasons why this wasn't very popular was that WebAssembly is much harder to inspect than Rust source code (4).

I'm not a PyPi expert. The PEP itself seems to permit adding WebAssembly to a wheel (a python package). The PEP literally mentions "There are no security implications in this PEP" (security for whom?). In 2022 the supply chain attack surface was notably smaller since powerful enough LLM's didn't exist yet, yet it was for many a concern to include WebAssembly to package s in another ecosystem back then.

I do think other forms of binaries were already permitted, such as precompiled C/C++ libraries, so if that's true, then this is indeed relatively not that big of a security concern, but _no_ security implications seems to be a bit much.

I do see the added advantage to reduce friction of loading pre-compiled webassembly from PyPi directly instead of going through alternative packaging registries though.

(1) https://crates.io/crates/watt

(2) https://github.com/serde-rs/serde/commit/1afae183b06ffe47d05...

(3) https://github.com/serde-rs/serde/issues/2538

(4) https://old.reddit.com/r/rust/comments/15wx2xe/precompiled_b...

(5) https://peps.python.org/pep-0783/