PEP 776: Emscripten support

[hoodmane]

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

---

📚 Documentation preview 📚: https://pep-previews--4307.org.readthedocs.build/pep-0776/

[hugovk]

Thanks for the PEP and work on Emscripten!

I've edited the top post with the new PEP checklist, please could you work through it and check things off?

You can use PEP number 776.

[hoodmane]

formally confirmed their approval

What form does this formal confirmation take? Comment here? cc @ambv @freakboy3742.

[hoodmane]

content displays as intended in the rendered HTML

The preview link shows pep-0776 as a 404 for me: https://pep-previews--4307.org.readthedocs.build/pep-0776/
Am I doing something wrong?

[hoodmane]

Lowercase name seemed to be the problem.

[hugovk]

Revert 871a223 but keep the newline before the bullet list:

WebAssembly does not have native support for signals. Furthermore, on a
non-pthreads build, the address space of the WebAssembly module is not shared,
so it is impossible for any thread capable of seeing an interrupt to write to
the eval breaker while the Python interpreter is running code. To work around
this, there are two possible solutions:

* If Emscripten is run in a webworker and served with the shared memory headers,
  it is possible to use shared memory outside of the WebAssembly address space
  as a signal buffer. A signal handling UI thread can write the desired signal
  into the signal buffer. The interpreter can periodically check the state of
  this signal buffer in the eval breaker code. Checking the signal buffer is
  slow compared to checking the eval breaker in native platforms, so we do only
  do it once every 50 times through the eval breaker. See
  `Python/emscripten_signal.c <https://github.com/python/cpython/blob/2bef8ea8ea045d20394f0daec7a5c5b1046a4e22/Python/emscripten_signal.c>`__
* Using stack switching, we can occasionally switch the stack and allow the
  JavaScript event loop to go around, then check the state of a signal buffer.
  This requires the experimental JavaScript Promise Integration API, and would
  be best used with the techniques for optimizing long tasks described
  `in this article <https://web.dev/articles/optimize-long-tasks>`__

Emscripten Python has already implemented the solution based on shared memory,
and it is in use in Pyodide.

[hoodmane]

@hugovk I think this can be merged now. I will address the remaining feedback in followup PRs. Thanks everyone!

[JelleZijlstra]

@AA-Turner I saw you are intending to review, but I'd rather merge this now since Hugo and I already approved and I prefer for PEPs not to get stuck in the ready-but-not-yet-merged state. If you have feedback, we can always update the PEP text later.

[AA-Turner]

I'm about halfway through (mainly editorial points, but nothing major so far). Happy for you to merge now though.

I agree we should avoid PEPs being "ready but not merged" (several have been as drafts in PRs for days/weeks(!)), but this PR was only opened this morning -- I had an unexpectedly busy day, so was late on a full read-through.

A

[willingc]

Thanks @hoodmane. Very well written and happy to see this continue to move forward. I remember the early days of pyodide and iodide at Mozilla.

[AA-Turner]

Sorry again for the delay, almost entirely editorial points.

[AA-Turner]

Pyodide (or the relationship to Emscripten) isn't defined here, perhaps a link?

[AA-Turner]

This sentence read a little breathlessly. I also would suggest removing the paragraph break afterwards.

Also, later on the PEP mentions the "Rust emscripten target" -- is this part of the emscripten project? Should the support for Rust/non-C native languages be mentioned here?

Suggested change

	`Emscripten <https://emscripten.org/>`__ is a complete open source compiler
	toolchain which compiles C/C++ code into WebAssembly/JavaScript executables that
	run in JavaScript runtimes including browsers and Node.js.
	`Emscripten <https://emscripten.org/>`__ is a complete open source compiler
	toolchain. It compiles C/C++ code into WebAssembly/JavaScript executables,
	for use in JavaScript runtimes, including browsers and Node.js.

[AA-Turner]

I've read a couple of times and I'm unclear on the distinction between "Emscripten Python" and "Pyodide". Is there a reference for a disambiguation? The only mention of Python on the emscripten intro page references Pyodide.

[freakboy3742]

Nice work @hoodmane!

Formally confirming that I'm OK with the places where I've been referred to here (as PEP 11 contact, and as buildbot maintainer on Anaconda-provided hardware).

A couple of other comments inline; plus a high-level comment on the discussion forum about the formal relationship between Pyodide and CPython as projects.

[freakboy3742]

The discussion around PEP 730 and PEP 738 concluded that platform was a better place for a public API for this sort of data (recognising that there may be a need to have it embedded in sys as a compiled property). There's probably space for an emscripten_ver() analog to mac_ver(), ios_ver() and android_ver().

[freakboy3742]

I've commented on this on the discussion thread; but tl;dr, I've got concerns about using pyodide_<abi> as the naming here, even if in practice we end up using Pyodide's specification.

[freakboy3742]

To confirm - are the wildcards going to be part of the PEP 11 spec, or will be updating PEP11 each time a new specific emscripten version is added to the test pool?

[hoodmane]

I was hoping to keep the wild cards. Maybe I should give a concrete example here or otherwise clarify that they are standing in for a version number. Also, we don't support all emscripten versions, so we should probably add where we plan to indicate this.

[freakboy3742]

It's not a blocker on this PEP, but for public visibility - I'm hoping to kick start a discussion about this very shortly.

[hoodmane]

Thanks for the copy edits and suggestions @AA-Turner!

[hugovk]

Thanks all, let's merge!

(Edit: annoyingly, we need to resolve all the review comments to do that.)

[hugovk]

The PEP is now published at https://peps.python.org/pep-0776/