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]

Thanks for the copy edits @hugovk and @encukou!

[ambv]

I formally confirm sponsorship.

[rth]

Thanks a lot @hoodmane !

I'm not sure about PEP review process, and if you would rather not get comments here, sorry about that.

Still a few comment below :)

[rth]

It would be good if there was a link to some page where these ABI versions are going to be tracked maybe?

[hoodmane]

I've been meaning to add to Pyodide a policies page, which would be a good place to refer to for this. I think the most contentious part of this PEP is likely to be who/what organization chooses the ABI and what it is called...

[hugovk]

I'm not sure about PEP review process, and if you would rather not get comments here, sorry about that.

These wording comments are generally fine here, thanks.

This first review is mainly for structure and formatting. Once merged, the PEP will be discussed in depth with the community on discuss.python.org (should we do this, how should we do it, etc).

[hugovk]

@hoodmane Ping when you're ready to merge.

[JelleZijlstra]

I left some editorial comments.

[JelleZijlstra]

So why aren't they removed too?

[hoodmane]

Uh... that is a good question. This language was added to the Pyodide docs in this PR:
pyodide/pyodide#4078

I just confirmed is true of both Pyodide and Emscripten Cpython. I think the removals are mainly targeted at large modules whereas pty and tty are only a few kilobytes so nobody ever bothered to remove them. If we think they should be removed, I can add language to that effect.

[JelleZijlstra]

Yeah I don't feel strongly, this just stood out as an oddity while reading

[hoodmane]

Thanks for the copy edit @JelleZijlstra!

[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]

Suggested change

	which `was approved by the steering council on October 25, 2024
	which `was approved by the Steering Council on October 25, 2024

[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]

Optional, throughout: To use intersphinx (would need corresponding definition in conf.py)

Suggested change

	`Emscripten
	<https://emscripten.org/docs/introducing_emscripten/about_emscripten.html>`__
	:ref:`Emscripten <emscripten:about-emscripten>`

[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.

[AA-Turner]

A PEP specifies, rather than requesting -- if this PEP is accepted and implemented, Pyodide wheels will be permitted:

Suggested change

	3. To request that Pyodide wheels be allowed for upload to PyPI
	3. For Pyodide wheels to be allowed for upload to PyPI

[AA-Turner]

Is this an accurate rephrasing?

Suggested change

	Emscripten is a POSIX-based platform. It uses the WebAssembly binary format,
	specified here:
	* https://webassembly.github.io/spec/core/binary/index.html
	* https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md
	Emscripten is a POSIX-based platform. It uses the `WebAssembly binary format`_,
	including the `dynamic linking extension`_.
	.. _WebAssembly binary format: https://webassembly.github.io/spec/core/binary/index.html
	.. _dynamic linking extension: https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md

[AA-Turner]

The second sentence seems to repeat the first

Suggested change

	Because of these limitations, Pyodide standardizes a no-pthreads build of
	Python. We will start with support for no-pthreads builds. If there is
	sufficient demand, a pthreads build with no dynamic loader could be added later.
	Because of these limitations, Pyodide standardizes a no-pthreads build of
	Python. If there is sufficient demand, a pthreads build with no dynamic loader
	could be added later.

[AA-Turner]

Suggested change

	Packages
	~~~~~~~~
	Third-party packages
	~~~~~~~~~~~~~~~~~~~~