Apply hugovk's copy edit

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Author: hoodmane

.github/CODEOWNERS

@@ -655,7 +655,6 @@ peps/pep-0773.rst  @zooba
 peps/pep-0774.rst  @savannahostrowski
 peps/pep-0775.rst  @encukou
 peps/pep-0776.rst  @hoodmane @ambv
-# ...
 peps/pep-0777.rst  @warsaw
 # ...
 peps/pep-0779.rst  @Yhg1s @colesbury @mpage

peps/pep-0776.rst

@@ -16,7 +16,7 @@ Abstract
 
 `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.
+run in JavaScript runtimes including browsers and Node.js.
 
 This PEP formalizes the addition of Tier 3 for Emscripten support in Python 3.14
 which `was approved by the steering council on October 25, 2024
@@ -27,8 +27,8 @@ Pyodide wheels to be uploaded to PyPI.
 Motivation
 ==========
 
-A web browser is a universal computing platform, available on Windows, Mac,
-Linux, and every smart phone.
+A web browser is a universal computing platform, available on Windows, macOS,
+Linux, and every smartphone.
 
 `The Pyodide project <https://pyodide.org/>`__ has for years supported
 Emscripten Python. Hundreds of thousands of students have learned Python through
@@ -39,7 +39,7 @@ is also increasingly being used by Python packages to provide interactive
 documentation. This demonstrates both the importance and the maturity of the
 Emscripten platform.
 
-Emscripten and wasi are also the only supported platforms that offer any
+Emscripten and WASI are also the only supported platforms that offer any
 meaningful sandboxing.
 
 =====
@@ -69,8 +69,8 @@ Packaging Goals
 
 1. To describe Pyodide's packaging tooling
 2. To describe Pyodide's wheel abi to a similar level of detail as the manylinux
-   peps
-3. To request that Pyodide wheels be allowed for upload to pypi
+   PEPs
+3. To request that Pyodide wheels be allowed for upload to PyPI
 
 
 ===============================
@@ -93,12 +93,12 @@ specified here:
 * https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md
 
 The ``emcc`` compiler is a wrapper around ``clang``. The ``emcc`` linker is a
-wrapper around ``wasm-ld`` (also part of the llvm toolchain).
+wrapper around ``wasm-ld`` (also part of the LLVM toolchain).
 
 Emscripten support for portable C/C++ code source compatibility with Linux is
 fairly comprehensive, with certain expected exceptions to be spelled out.
 CPython already supports compilation to Emscripten, and it only requires a very
-modest number of modifications to the normal linux target.
+modest number of modifications to the normal Linux target.
 
 ----------------
 POSIX Compliance
@@ -113,15 +113,15 @@ support for ``fork()``. See `Emscripten Portability Guidelines
 Emscripten executables can be linked with threading support, however, it comes
 with several limitations:
 
-Enabling threading requires websites to be served with special security headers
-that indicate acceptance of the possibility of spectre-style information
-leakage. These headers are a usability hazard for users who are not intimately
-familiar with the web platform.
+* Enabling threading requires websites to be served with special security headers
+  that indicate acceptance of the possibility of spectre-style information
+  leakage. These headers are a usability hazard for users who are not intimately
+  familiar with the web platform.
 
-If an executable is linked with both threading and a dynamic loader, Emscripten
-prints a warning that using dynamic loading and pthreads together is
-experimental. It may cause performance problems or crashes. These problems may
-require WebAssembly standards work to resolve.
+* If an executable is linked with both threading and a dynamic loader, Emscripten
+  prints a warning that using dynamic loading and pthreads together is
+  experimental. It may cause performance problems or crashes. These problems may
+  require WebAssembly standards work to resolve.
 
 Because of these limitations, Pyodide standardizes a no-pthreads build of
 Python. We will start with support for no-pthreads builds. If there is
@@ -162,27 +162,27 @@ macOS. Upstream tools:
 * emcc is a C and C++ compiler, linker, and a sysroot with headers for the
   system libraries. The system libraries themselves are generated on the fly
   based on the ABI requested.
-* NodeJS can be used as an "emulator" to run Emscripten programs from the
-  command line. This emulation behaves best on Linux with Mac as a runner up.
-  Node is the most convenient way to test Emscripten programs.
+* Node.js can be used as an "emulator" to run Emscripten programs from the
+  command line. This emulation behaves best on Linux with macOS as a runner up.
+  Node.js is the most convenient way to test Emscripten programs.
 * It is possible to run Emscripten programs inside of any web browser. Browser
   automation tools like selenium, playwright, or pupeeteer can be used to test
   features that are browser-only.
 
 Pyodide's tools:
 
 * ``pyodide build`` can be used to cross compile Python packages to run on
-  Emscripten. Cross compilation works best on Linux, sometimes on Macs, and is
+  Emscripten. Cross compilation works best on Linux, sometimes on macOS, and is
   unsupported on Windows.
 * ``pyodide venv`` can make a virtual environment that runs in Pyodide.
-* ``pytest-pyodide`` can test Python code against various JS runtimes.
+* ``pytest-pyodide`` can test Python code against various JavaScript runtimes.
 
 cibuildwheel supports building wheels to target Emscripten using ``pyodide build``.
 
 In the short term, Pyodide's packaging tooling will stay in the Pyodide
 repository. It is an open question where Pyodide's packaging tooling should live
 in the long term. Two sensible options would be for it to remain under the
-``pyodide`` organization or be moved into the ``pypa`` organization.
+``pyodide`` organization or be moved into the ``pypa`` organization on GitHub.
 
 
 --------------------------------
@@ -240,7 +240,7 @@ Emscripten file system. There are several possible approaches to this:
   embeds the files into a custom archive format that cannot be processed with
   standard tooling.
 
-* For Node, use the NODEFS to mount a native directory with the files into the
+* For Node.js, use the NODEFS to mount a native directory with the files into the
   Emscripten file system. This is the most efficient option but is Node only. It
   is closely analogous to what wasi does.
 
@@ -278,21 +278,21 @@ replace them in a ``preRun`` hook.
 
 Making ``stdin`` work correctly in the browser poses an additional challenge
 because it is not allowed to block for user input in the main thread of the
-browser. If Emscripten is run in a webworker and served with the shared memory
+browser. If Emscripten is run in a web worker and served with the shared memory
 headers, it is possible to receive input using shared memory and atomics. It is
 also possible for a ``stdin`` device to block in a simpler and more efficient
 manner using stack switching using the experimental JavaScript Promise
 Integration API.
 
 Pyodide replaces the standard I/O devices in order to fix the line buffering
-behavior. When Pyodide is run in node, ``stdin``, ``stdout``, and ``stderr`` are
+behavior. When Pyodide is run in Node.js, ``stdin``, ``stdout``, and ``stderr`` are
 by default connected to ``process.stdin``, ``process.stdout``, and
 ``process.stderr`` and so the standard streams work as a tty out of the box.
 Pyodide also ensures that ``shutil.get_terminal_size`` returns results
 consistent with ``process.stdout.rows`` and ``process.stdout.columns``. Pyodide
 currently has no support for stack switching ``stdin``.
 
-Currently, the Emscripten Python node runner uses the default I/O that
+Currently, the Emscripten Python Node.js runner uses the default I/O that
 Emscripten provides. The web example uses ``Atomics`` for ``stdin`` and has
 custom ``stdout`` and ``stderr`` handlers, but they exhibit the undesirable line
 buffering behavior. We will upstream the standard streams behaviors from
@@ -311,7 +311,7 @@ Main Thread Synchronous Loading Limit
 
 In the main browser thread, a dynamic library can only be loaded synchronously
 if it is at most 4 kilobytes. This excludes most nontrivial dynamic libraries.
-This limit is not present in Node and can be avoided by using a web worker. If
+This limit is not present in Node.js and can be avoided by using a web worker. If
 stack switching is available, then it is possible to make ``dlopen()`` stack
 switch in order to instantiate a dynamic library synchronously.
 
@@ -394,12 +394,12 @@ very useful. Compiling and linking with ``-g2`` (or a higher debug setting)
 ensures that WebAssembly symbols are included and they will appear in the
 traceback.
 
-Because Emscripten Python currently has no JS API and no foreign function
-interface, the situation is much simpler. The Python node runner wraps the call
+Because Emscripten Python currently has no JavaScript API and no foreign function
+interface, the situation is much simpler. The Python Node.js runner wraps the call
 to ``bootstrapEmscriptenExecutable()`` in a try/catch block. If an exception is
 caught, it displays the JavaScript exception and calls ``_Py_DumpTraceback()``.
 It then exits with code 1. We will stick with this approach until we add either
-a JS API or foreign function interface, which is out of scope for this PEP.
+a JavaScript API or foreign function interface, which is out of scope for this PEP.
 
 =============
 Specification
@@ -448,15 +448,14 @@ Removed Modules
 ---------------
 
 The following modules are removed from the standard library to reduce download
-size and since they currently wouldn't work in the WebAssembly VM,
+size and since they currently wouldn't work in the WebAssembly VM.
 
 - curses
 - dbm
 - ensurepip
 - fcntl
 - grp
 - idlelib
-- lib2to3
 - msvcrt
 - pwd
 - resource
@@ -496,7 +495,7 @@ name is justified. This is consistent with the return value from ``os.uname()``.
 
 There is also ``sys._emscripten_info`` which includes the Emscripten version and
 the runtime (either ``navigator.userAgent`` in a browser or ``"Node js" +
-process.version`` in Node).
+process.version`` in Node.js).
 
 ---------------
 Signals Support
@@ -508,7 +507,7 @@ 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,
+* If Emscripten is run in a web worker 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
@@ -596,7 +595,7 @@ CI Resources
 ------------
 
 Pyodide can be built and tested on any Linux with a reasonably recent version of
-Node. Anaconda has offered to provide physical hardware to run Android
+Node.js. Anaconda has offered to provide physical hardware to run Emscripten
 buildbots, maintained by Russell Keith-Magee.
 
 CPython does not currently test Tier 3 platforms on GitHub Actions, but if this
@@ -610,12 +609,12 @@ Existing Package Support
 ========================
 
 Pyodide currently maintains ports of 255 different packages at the time of this
-writing, including major scientific Python packages like numpy, scipy, pandas,
-polars, scikit-learn, opencv, pyarrow, and Pillow as well as general purpose
-packages like aiohttp, requests, pydantic, cryptography, and orjson.
+writing, including major scientific Python packages like NumPy, SciPy, pandas,
+Polars, scikit-learn, OpenCV, PyArrow, and Pillow as well as general purpose
+packages like aiohttp, Requests, Pydantic, cryptography, and orjson.
 
-About 60 packages are also testing against Pyodide in their CI, including numpy,
-pandas, awkward-cpp, scikit-image, statsmodels, pyarrow, hypothesis, and PyO3.
+About 60 packages are also testing against Pyodide in their CI, including NumPy,
+pandas, awkward-cpp, scikit-image, statsmodels, PyArrow, Hypothesis, and PyO3.
 
 Emscripten Wheel Format
 =======================
@@ -650,19 +649,18 @@ Pyodide ABI, it is not necessary to use the Pyodide distribution itself.
 The ``pyodide build`` tool knows how to create wheels that match our ABI. As an
 alternative,
 `the auditwheel-emscripten tool <https://github.com/ryanking13/auditwheel-emscripten>`__
-
 is capable of performing basic compatibility checks, vendoring shared libraries,
 and retagging the wheel from ``emscripten_<version>`` to ``pyodide_<abi>``. Unlike
-with manylinux, there is no need for a docker container to build the
+with manylinux, there is no need for a Docker container to build the
 ``pyodide_<abi>`` wheels. All that is needed is a Linux machine and appropriate
-versions of Python, node, and Emscripten.
+versions of Python, Node.js, and Emscripten.
 
 
 ------
 PEP 11
 ------
 
-PEP 11 will be updated to indicate that Emscripten is supported. Specifically
+:pep:`11` will be updated to indicate that Emscripten is supported. Specifically
 the triples ``wasm32-unknown-emscripten_xx_xx_xx``.
 
 Russell Keith-Magee will serve as the initial core team contact for these ABIs.
@@ -676,7 +674,7 @@ Future Work
 Improving Cross Builds in the Packaging Ecosystem
 -------------------------------------------------
 
-Python now supports four non-self-hosting platforms: iOS, Android, wasi, and
+Python now supports four non-self-hosting platforms: iOS, Android, WASI, and
 Emscripten. All of them will need to build packages via cross builds. Currently,
 ``pyodide-build`` allows building a very large number of Python packages for
 Emscripten, but it relies on a giant pile of hacks. In the long run, we would
@@ -695,7 +693,7 @@ JavaScript API for Bootstrapping
 ================================
 
 Currently we offer no stable API for bootstrapping Python. Instead, we use one
-collection of settings for the Node cli entrypoint and a separate collection of
+collection of settings for the Node.js CLI entrypoint and a separate collection of
 settings for the browser demo.
 https://github.com/python/cpython/tree/98fa4a49fecbac3c990a25ce5d300592dad31be0/Tools/wasm/emscripten/node_entry.mjs
 https://github.com/python/cpython/blob/98fa4a49fecbac3c990a25ce5d300592dad31be0/Tools/wasm/emscripten/web_example/python.worker.mjs
@@ -719,7 +717,7 @@ mapping between the JavaScript object model and the Python object model and a
 calling convention that allows high level bidirectional integration.
 
 Asyncio
-========
+=======
 
 Most JavaScript primitives are asynchronous. The JavaScript thread that Python
 runs in already has an event loop. It it not too difficult to implement a Python