I'm stepping down as sponsor of Emscripten

I asked if any other core dev wants to take over at Looking for a new sponsor for `wasm32-unknown-emscripten` .

I’m not a core dev so I can’t help with that part, but you did also mention the lack of build bot. I have room to add one of those if that would be of value?


I left a comment about your generous offer!

1 Like

No one stepped forward, so building for Emscripten will raise an error under Python 3.13.


Thanks for your support and work in the past, we appreciate it! It’s unfortunate that no other sponsor was interested in supporting the emscripten platform. From the Pyodide side, we can also provide a buildbot, but I don’t know if it would be relevant if there is no sponsor.

cc @hoodmane @ryanking13


Regarding the build time error from PEP 11

At the same time, the CPython source code must be changed to produce a build-time error if somebody tries to install CPython on this platform. On platforms using autoconf, configure must fail. This gives potential users of the platform a chance to step forward and offer maintenance.

Could you please explain what’s the link between having a sponsor for a platform and the "offer of maintenance [by users] " indicated in the last sentence to avoid the error? And what exactly this offer of maintenance involves? I mean in Pyodide we will continue to build CPython with emscripten, we can patch out that error. Is there anything more constructive we can/should do?

1 Like

Good question! It’s a bit ambiguous since that part of the PEP is a hold-over from before there were tiers and thus the concept of sponsors. I’ve asked the SC for clarification in Clarifying PEP 11 around dropping support · Issue #226 · python/steering-council · GitHub .

1 Like

I think maintenance is more than a buildbot, it’s also proactive participation in discussions and pull requests that impact the specific platform, and reactive action when the buildbot reports a failure that needs a code fix or a test skip.

This gives potential users of the platform a chance to step forward and offer maintenance.

I think the meaning here is: without a clear failure, people interested in the platform could think that it’s supported and/or works well, but will encounter problems later and find out there is no core-dev support. So making configure fail is a clear message that this build is not expected to work, and you should contact python-dev to see if things can change (with commmunity-provided patches and a core-dev sponsor), or take the responsibility yourself to remove that and do other changes and extensive testing to build for an unsupported platform.

But on the steering council ticket, GvR indicated that it’s not very helpful or nice to add that sort of explicit failure (paraphrased). It is true that people have worked for example on android or wasm support for years outside of the cpython repo, and having to patch out lines added just to make configure fail was probably not hard but maybe a little annoying.

I agree, the hard fail is not very helpful. But requiring some kind of --unsupported-platform=emscripten option to bypass the hard fail would be fine by me.

1 Like

FWIW, I should have posted here, not on the SC ticket. It’s just one opinion. Steve’s idea sounds fine as a compromise.

Wouldn’t a simple configure warning or even compile time warning be more helpful ? After all, the intent of the hard coded notice is to make it clear that a platform is not supported anymore and find new volunteers.

BTW: I find it a bit strange that we only have this requirement for platforms which were supported once and then are no longer actively supported. We don’t have any such errors or warnings for platforms which were never actively supported (under PEP 11), e.g. OpenBSD or Solaris.

1 Like

I believe the original intent was to signal to users that the guarantees have shifted w/o accidentally continuing to believe things are officially supported. A warning might make sense, but does configure do such things?

The letter of the PEP is:

On platforms using autoconf, configure must fail. This gives potential users of the platform a chance to step forward and offer maintenance.

Potential users have stepped forward and offered maintenance. IMO, the build-time error has served its purpose and can be removed now.

(Of course, if the SC goes with this reading, the PEP should be clarified.)

I don’t think that would be helpful to users. From their point of view, I don’t see a significant difference between Tier 3 and unsupported platform.

Come to think of it, PEP 11 is written for core devs. What are the intended implications for users? I don’t think the intent was to block them from building on an unsupported platform (regardless of what the PEP currently says).

But there’s still no core dev, so what does non-tier support look like? We don’t fix platform-specific bugs? Can we still remove code? What about filed bugs?

I actually haven’t added any error. The issue is open and I was waiting to hear from the SC before doing anything.

IMO: The PyIodide team is free to fix bugs, and I’d even merge them if the issue isn’t too specific to Emscripten`.

We are allowed to remove code and reject changes “if they cause a maintenance burden or obstruct general improvements” (per the PEP). As always, use your best judgement when doing that.

IMO, the happy path would be to onboard someone from the Pyodide team as a core dev. If/when that does happen, any removals will need to be reverted. More importantly, before that happens, any removals will make it harder for such a person to join.

Personally, I’d be happy to merge small additions with a #ifdef or skipIf(is_emscripten) that makes it clear that this is for an unsupported platform. Or ones that fix a POSIX quirk that doesn’t appear on tiered platforms (for example, this one found on BSD: #109697).

Bigger blocks of code, and Devguide instructions, would be better moved to PyIodide spaces.

For filed issues, if we close them it would be good to let PyIodide team know about them. We could add them to Unsupported platforms · GitHub perhaps?

Or point the OP to Pyodide for them to file there.

I think that’s up to triagers since I didn’t even know that board existed. But if the issues are left open I will probably have to rename the WebAssembly label to WASI so it doesn’t get used for Emscripten issues.

IMO, the happy path would be to onboard someone from the Pyodide team as a core dev.

I think of the three of us (@rth, @ryanking13 and I), I’m the most likely to have the bandwidth for this. It would be good for us to be in more consistent contact. We’re all a bit busy and communication is hard so I tend to default to doing tasks that don’t require communication.

For this to make sense I’d have to pick up some non-emscripten-related tasks in order to become conversant with the way things work.

More importantly, before that happens, any removals will make it harder for such a person to join.

For instance, if Emscripten related PRs are not accepted, there will be a bit less for us to do. For instance I’d still like to add ctypes support for the Emscripten build. Though this is a pretty small task in any case.


  • Pyodide is quite popular with users, so it makes sense to keep an eye on it, and
  • supporting more exotic interpretations of POSIX makes CPython more portable to new platforms.

Feel free to ping me on any Emscripten-related PRs you need reviewed. IMO, your time is better spent there than on unrelated tasks. (Of course, this way you won’t become a core dev as fast.)

1 Like

I interface python with browser since 2016 so here’s my views after a while and trying to reduce overengineering in that process.

The only thing needed is proper ctypes support for browser from cpython-wasm to load a - minimal - bridge to call , in case of javascript :

window['eval']() and returns a value from it with window['JSON'].stringify().

A nice side effect is that it allows CPython to load dynamic modules.

Everything else could end up as opiniated and/or as a maintenance burden.

That bridge could well be a json based one that could fit well under 100 lines ( mostly python side ).

It could be emscripten (c/c++ emval/embind) because libffi support is already there, but it does not need strictly to be pyodide.

There are other bridges available :
A good example of that is https://cowasm.org/ which does support dynamic loading but does not use emscripten/pyodide at all.

There’s one in C-emscripten already mentionned by @tiran in another thread and used in production by a pygame-ce web runtime ( statically linked into pymain to keep ctypes optionnal if needed ).

To be clear, I’ll be happy to help with things like:

  • Improving CPython project processes (figuring out how community support for a platform should work)
  • PR Reviews (especially: small fixes; removing code that’s been moved to a third-party project; adding hooks that enable a third-party project to do its thing)

I am not interested in making sure Python works in the browser [1]. That’s your job. But if CPython is blocking you, or if you see a better way to cooperate, please talk to me.

I will assume @hoodmane, @rth, @ryanking13 can speak for Pyodide, and @pmp-p is interested in Emscripten too. So let’s ping y’all and wait for your opinions when it comes to Emscripten/browser support.

Could you send a PR adding your GitHub usernames to the Experts index? I think it’s the perfect place. (Some of the text there might imply that only core devs should be on the list. IMO, that would be an issue in CPython project process, which I just volunteered to fix.)

  1. Well: I am, but strictly as a user/fan. Sorry, I need to draw that line. ↩︎

1 Like