@tiran already made the request of the SC to consider bumping both WebAssembly-related platforms to tier 3 now that we have a stable buildbot funded by MS and both he and I will support the platform. But since this is the first platform being proposed for tier 3 consideration, we figured being transparent here by letting it be more widely known made sense.
Obviously if anyone has questions about this you should feel free to ask! Otherwise if the SC approves the promotion there will be a separate announcement about that.
Since it is the first time a platform is promoted with new PEP 11 definition, we think it is a good idea to start with tier 3. My tier 3 request is for 3.11 and main. We may request tier 2 for 3.12+ in the future.
Of note, the SC also discussed what it’d take to promote this from tier 3 to tier 2 beyond the base requirements listed in PEP 11. Mostly we want some time (several months) spent in Tier 3 proving platform and buildbot stability with a low amount of hiccups, both infrastructure and developer related, relating to the platform.
So that if there are pain points they can be addressed before granting it release-blocking tier 2 status.
The first requirement, Must have a reliable buildbot, is a proxy for The test suite reliably passes. The way that’s done with WebAssembly’s many missing features is that the relevant tests are skipped.
Other platforms work the same way, of course. But existing tier-3 platform specifics are (hopefully at this point) well documented, and I would like WebAssembly to get to that point before it joins the tier.
That is, every missing module should have a “platform availability” entry in the docs mentioning WA. And for the modules WA has, every item (function, class, …) that works differently or is unavailable should also get one.
It would be nice to have a comprehensive list of all these in one place, too – that would be new for WA, but compared to platforms Python grew up on, WA’s missing pieces feel much more spread out across diverse modules.
That’s my personal opinion, not a requirement from the SC (yet).
Yes, this is an important point. It’s all too easy to assume that because WA is “supported” that means your reasonably portable Python code will run there. Not so if “reasonably supported” includes network or process operations. (Are there docs at all that explain what you can expect to work on WA? Does tempfile work? urllib? suprocess? I have no idea.)
The README in the Tools/wasm directory has a rough overview of what is missing. The document started as a brain dump and some points are probably out of date. The available features depend on the WASM platform (Emscripten or WASI) and the runtime. Browsers are more confined than NodeJS. WASI runtime have different properties.
By the way, the common acrynom for WebAssembly is WASM. Never seen WA before.
What about our current “Unix” and “Linux” definitions? Or modules that don’t work if an external library isn’t available (e.g. uuid)? I’m assuming our listing for FreeBSD is accurate, but I honestly don’t know.
I think there’s a wider question of how specific we want to get with this for all of the platforms we document.
Considering the rest of the documentation lists platform support if possible, I assume we would go with a similar approach. That will be easier with WASI since that’s a standard itself compared to whether we document emscripten for Node, for the browser, or both independently.
For os and socket module I’m going to document each case where a function is either missing or behaves differently. For other modules I’ll include a short snippet that links to a central document. See PR https://github.com/python/cpython/pull/95452.
It’s easier for wasi snapshot preview 1. With the recent progress on WIT and introduction of new WASI component model, it will become trickier.