Merge branch 'main' into some-pfmoore-comments

Author: hoodmane

.github/CODEOWNERS

@@ -658,6 +658,7 @@ peps/pep-0776.rst  @hoodmane @ambv
 peps/pep-0777.rst  @warsaw
 # ...
 peps/pep-0779.rst  @Yhg1s @colesbury @mpage
+peps/pep-0780.rst  @lysnikolaou
 # ...
 peps/pep-0789.rst  @njsmith
 # ...

peps/pep-0751.rst

@@ -235,7 +235,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   file).
 - Tools supporting dependency groups MUST also support extras.
 - Tools SHOULD explicitly set this key to an empty array to signal that the
-  inputs used to generate the lock file had no extras (e.g. a ``pyproject.toml``
+  inputs used to generate the lock file had no dependency groups (e.g. a ``pyproject.toml``
   file had no ``[dependency-groups]`` table), signalling that the lock file
   is, in effect, multi-use even if it only looks to be single-use.
 
@@ -361,6 +361,7 @@ consistent order. Usage of inline tables SHOULD also be kept consistent.
   contains.
 - Tools MAY choose to not support version control systems, both from a locking
   and/or installation perspective.
+- Tools MAY choose to only support a subset of the available VCS types.
 - Tools SHOULD provide a way for users to opt in/out of using version control
   systems.
 - Installation from a version control system is considered originating from a
@@ -1094,7 +1095,7 @@ use-cases based on extras and dependency groups. It is up to the tool(s) you use
 that decide whether multi-use lock files are possible. All tools dealing with
 lock files at least support single-use lock files. Neither type of lock file
 is better or worse than the other, it just changes how much can be written down
-in a single file (which can influence how manageable).
+in a single file.
 
 Lock files that follow this PEP can be installed by any installer that
 implements the specification. This allows users of a lock file to perform an
@@ -1269,7 +1270,7 @@ Recording the creation date of the lock file
 ============================================
 
 To know how potentially stale the lock file was, an earlier proposal suggested
-recording the creation date of the lock file. But for some same merge conflict
+recording the creation date of the lock file. But for the same merge conflict
 reasons as storing the hash of the file contents, this idea was dropped.
 
 
@@ -1315,7 +1316,7 @@ Drop recording the package version
 ==================================
 
 The package version is optional since it can only be reliably recorded when an
-sdist of wheel file is used. And since both sources record the version in file
+sdist or wheel file is used. And since both sources record the version in file
 names it is technically redundant.
 
 But in discussions it was decided the version number is useful for auditing
@@ -1470,7 +1471,9 @@ Acknowledgements
 
 Thanks to everyone who participated in the discussions on discuss.python.org.
 Also thanks to Randy Döring, Seth Michael Larson, Paul Moore, and Ofek Lev for
-providing feedback on a draft version of this PEP before going public.
+providing feedback on a draft version of this PEP before going public. Thanks to
+Randy Döring of Poetry, Charlie Marsh of uv, and Frost Ming of PDM for providing
+feedback on behalf of their respective projects.
 
 
 =========

peps/pep-0755.rst

@@ -154,8 +154,9 @@ Grant Ownership
 ---------------
 
 The owner of a grant may allow any number of other organizations to use the
-grant. The grants behave as if they were owned by the organization. The owner
-may revoke this permission at any time.
+grant. The grants behave as if they were owned by the organization, i.e. even
+the owner cannot upload packages to the namespace. The owner may revoke this
+permission at any time.
 
 The owner may transfer ownership to another organization at any time without
 approval from PyPI admins. If the organization is a paid organization, the

peps/pep-0765.rst

@@ -2,7 +2,7 @@ PEP: 765
 Title: Disallow return/break/continue that exit a finally block
 Author: Irit Katriel <irit@python.org>, Alyssa Coghlan <ncoghlan@gmail.com>
 Discussions-To: https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348
-Status: Accepted
+Status: Final
 Type: Standards Track
 Created: 15-Nov-2024
 Python-Version: 3.14
@@ -11,6 +11,7 @@ Post-History: `09-Nov-2024 <https://discuss.python.org/t/an-analysis-of-return-i
 Replaces: 601
 Resolution: https://discuss.python.org/t/71348/111
 
+.. canonical-doc:: :external+py3.14:ref:`finally`
 
 Abstract
 ========

peps/pep-0768.rst

@@ -2,11 +2,12 @@ PEP: 768
 Title: Safe external debugger interface for CPython
 Author: Pablo Galindo Salgado <pablogsal@python.org>, Matt Wozniski <godlygeek@gmail.com>, Ivona Stojanovic <stojanovic.i@hotmail.com>
 Discussions-To: https://discuss.python.org/t/pep-768-safe-external-debugger-interface-for-cpython/73969
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Created: 25-Nov-2024
 Python-Version: 3.14
 Post-History: `11-Dec-2024 <https://discuss.python.org/t/pep-768-safe-external-debugger-interface-for-cpython/73969>`__
+Resolution: `17-Mar-2025 <https://discuss.python.org/t/pep-768-safe-external-debugger-interface-for-cpython/73969/57>`__
 
 Abstract
 ========

peps/pep-0770.rst

@@ -153,26 +153,19 @@ can projects begin using the new features. Even with this careful approach it's
 not guaranteed that tools won't break on new metadata versions and fields.
 
 To avoid this delay, simplify overall how to include SBOMs, and to give
-flexibility to build backends and tools, this PEP proposes a new top-level table
-in ``pyproject.toml``, ``[dist-info.files]``, to safely add data to a Python
-package through a registry of reserved names that
-avoids the need for new metadata fields and versions.  This mechanism allows
-build backends and tools to begin using the features described in this PEP
-immediately after acceptance without the head-of-line blocking on other
-projects adopting the PEP.
-
-A new top-level table was chosen over using the ``[project]`` table because,
-as described in :pep:`621`, the ``[project]`` table is used for storing core
-metadata and this mechanism doesn't use core metadata.
+flexibility to build backends and tools, this PEP proposes using a subdirectory
+under ``.dist-info`` to safely add data to a Python package while avoiding the
+need for new metadata fields and versions. This mechanism allows build backends
+and tools to begin using the feature described in this PEP immediately after
+acceptance without the head-of-line blocking on other projects adopting the PEP.
 
 Storing files in the ``.dist-info`` or ``.data`` directory
 ----------------------------------------------------------
 
 There are two top-level directories in binary distributions where files beyond
 the software itself can be stored: ``.dist-info`` and ``.data``.
 This specification chose to use the ``.dist-info`` directory for storing
-subdirectories and files from the new ``[dist-info.files]`` top-level table
-for two reasons:
+subdirectories and files.
 
 Firstly, the ``.data`` directory has no corresponding location in the installed
 package, compared to ``.dist-info`` which does preserve the link between the
@@ -231,37 +224,18 @@ Specification
 
 The changes necessary to implement this PEP include:
 
-* Explicitly reserving all subdirectory names in the ``.dist-info`` directory.
-* A new registry of reserved subdirectory names in the ``.dist-info`` directory.
-* An optional top-level table, ``[dist-info.files]``, added to
-  `project source metadata <770-spec-project-source-metadata_>`_,
-* An optional ``sboms`` key in the new ``[dist-info.files]`` table,
+* Explicitly reserving the subdirectory ``.dist-info/sboms``.
 * `Additions <770-spec-project-formats_>`_ to the built distribution (wheel),
   and installed project specifications
 
 In addition to the above, an informational PEP will be created for tools
 consuming included SBOM documents and other Python package metadata to
 generate complete SBOM documents for Python packages.
 
-.. _770-spec-dist-info-subdirs:
-
-Reserving all subdirectory names in ``.dist-info``
---------------------------------------------------
-
-This PEP explicitly reserves all subdirectory names in the ``.dist-info``
-directory for future usage.
-
-Build backends MUST NOT create subdirectories in the ``.dist-info`` directory
-beyond the names in the `registry <770-spec-dist-info-subdirs-registry>`_
-to avoid collisions with future reserved names.
-
-Build frontends and publishing tools MAY warn users if any ``.dist-info``
-subdirectories aren't in the registry.
-
 .. _770-spec-dist-info-subdirs-registry:
 
-Registry of reserved ``.dist-info`` subdirectory names
-------------------------------------------------------
+Reserving the ``.dist-info/sboms`` directory
+--------------------------------------------
 
 This PEP introduces a new registry of reserved subdirectory names allowed in
 the ``.dist-info`` directory for the :term:`distribution archive`
@@ -278,88 +252,7 @@ Subdirectory name PEP / Standard
 ================= ==============
 
 See :ref:`770-backwards-compat` for a complete methodology for
-creating this initial set of values to avoid backwards incompatibility issues.
-
-.. _770-spec-project-source-metadata:
-
-Project source metadata
------------------------
-
-This PEP specifies changes to the project's source metadata
-in the ``pyproject.toml`` file:
-
-Add new ``[dist-info.files]`` table
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A new optional ``[dist-info.files]`` table is added for specifying paths
-in the project source tree relative to ``pyproject.toml`` to file(s) which
-should be included in the built project to a subdirectory of ``.dist-info``.
-
-This new table has only one defined optional key: ``sboms``. The value of the
-``sboms`` key MUST be an array of valid glob patterns, as specified below:
-
-* Alphanumeric characters, underscores (``_``), hyphens (``-``) and dots (``.``)
-  MUST be matched verbatim.
-* Special glob characters: ``*``, ``?``, ``**`` and character ranges: ``[]``
-  containing only the verbatim matched characters MUST be supported. Within
-  ``[...]``, the hyphen indicates a locale-agnostic range (e.g. a-z, order based
-  on Unicode code points). Hyphens at the start or end are matched literally.
-* Path delimiters MUST be the forward slash character (``/``). Patterns are
-  relative to the directory containing ``pyproject.toml``, therefore the leading
-  slash character MUST NOT be used.
-* Parent directory indicators (``..``) MUST NOT be used.
-
-Any characters or character sequences not covered by this specification are
-invalid. Projects MUST NOT use such values. Tools consuming this field SHOULD
-reject invalid values with an error.
-
-Literal paths (e.g. ``bom.cdx.json``) are treated as valid globs which means
-they can also be defined.
-
-Build tools:
-
-* MUST treat each value in the array as a glob pattern, and MUST raise an error
-  if the pattern contains invalid glob syntax.
-* MUST include all files matched by a listed pattern in all distribution
-  archives under the ``.dist-info/sboms`` directory.
-* MUST raise an error if any individual user-specified pattern does not match
-  at least one file.
-
-If the ``sboms`` key is present and is set to a value of an empty array,
-then tools MUST NOT include any SBOM files and MUST NOT raise an error.
-
-Examples of valid SBOM files declarations:
-
-.. code-block:: toml
-
-    [dist-info.files]
-    sboms = ["bom.json"]
-
-    [dist-info.files]
-    sboms = ["sboms/openssl.cdx.json", "sboms/openssl.spdx.json"]
-
-    [dist-info.files]
-    sboms = ["sboms/*"]
-
-    [dist-info.files]
-    sboms = []
-
-Examples of invalid SBOM files declarations:
-
-.. code-block:: toml
-
-    [dist-info.files]
-    sboms = ["..\bom.json"]
-
-Reason: ``..`` must not be used. ``\\`` is an invalid path delimiter, ``/``
-must be used.
-
-.. code-block:: toml
-
-    [dist-info.files]
-    sboms = ["bom{.json*"]
-
-Reason: ``bom{.json*`` is not a valid glob.
+avoiding backwards incompatibilities with selecting this directory name.
 
 .. _770-spec-project-formats:
 
@@ -368,12 +261,6 @@ SBOM files in project formats
 
 A few additions will be made to the existing specifications.
 
-:term:`Project source trees <Project source tree>`
-  Per :ref:`770-spec-project-source-metadata` section, the
-  `Declaring Project Metadata specification <pyprojecttoml_>`__
-  will be updated to add the ``[dist-info.files]`` table
-  and optional ``sboms`` key.
-
 :term:`Built distributions <Built distribution>` (:term:`wheels <wheel>`)
   The wheel specification will be updated to add the new registry of reserved
   directory names and to reflect that if the ``.dist-info/sboms`` subdirectory
@@ -420,10 +307,10 @@ SBOM standards, versions, or fields.
 Backwards Compatibility
 =======================
 
-Reserved ``.dist-info`` subdirectories registry
------------------------------------------------
+Reserved ``.dist-info/sboms`` subdirectory
+------------------------------------------
 
-The new registry of reserved ``.dist-info`` subdirectories represents
+The new reserved ``.dist-info/sboms`` subdirectory represents
 a new reservation that wasn't previously documented, thus has the potential to
 break assumptions being made by already existing tools.
 
@@ -521,23 +408,6 @@ Typically tools can automatically annotate bundled dependencies when those
 dependencies come from a "packaging ecosystem" (such as PyPI, Linux distros,
 Crates.io, NPM, etc).
 
-For packages which cannot be automatically annotated and if the package author
-wishes to provide an SBOM the approach will be to generate or author SBOM files
-and then include those files using ``pyproject.toml``:
-
-.. code-block:: toml
-
-    [dist-info.files]
-    sboms = [
-       "sboms/bom.cdx.json"
-    ]
-
-For projects manually specifying an SBOM document the challenge will be
-keeping the document up-to-date. The CPython project has some
-`customized tooling <https://github.com/python/cpython/blob/main/Tools/build/generate_sbom.py>`__
-for this task, but it can likely be generalized into a tool reusable by other
-projects.
-
 What do SBOM tool authors need to know?
 ---------------------------------------
 
@@ -644,11 +514,12 @@ user-involvement or knowledge. Compare this situation to license files which
 are almost always static.
 
 The 639-style approach was ultimately dropped in favor of defining SBOMs simply
-by their presence in the ``.dist-info/sboms`` directory and using a new table in
-``pyproject.toml`` called ``[dist-info.files]`` to define SBOMs in source
-distributions. This approach allows users to specify static SBOM files while
-still empowering build backends and tools to add their own SBOM data without the
-static/dynamic conflict.
+by their presence in the ``.dist-info/sboms`` directory. This approach allows
+build backends and tools to add their own SBOM data without the static/dynamic
+conflict.
+
+A future PEP will define the process for statically defining SBOM files to be
+added to the ``.dist-info/sboms`` directory.
 
 Open Issues
 ===========
@@ -686,9 +557,8 @@ Acknowledgements
 ================
 
 Thanks to Karolina Surma for authoring and leading :pep:`639` to acceptance.
-This PEP's initial design was heavily inspired by :pep:`639` and the new
-"dist-info.files" mechanism generalizes 639's approach of using a subdirectory
-under ``.dist-info``.
+This PEP's initial design was heavily inspired by :pep:`639` and adopts a
+similar approach of using a subdirectory under ``.dist-info`` to store files.
 
 Copyright
 =========

peps/pep-0776.rst

@@ -72,6 +72,23 @@ Packaging Goals
 Emscripten Platform Information
 ===============================
 
+"Pyodide" vs "Emscripten Python"
+--------------------------------
+
+For the sake of this document, we use the term "Emscripten Python" to refer to
+the Emscripten Python maintained in the ``python/cpython`` repository, without
+any downstream additions. We contrast the features present in Emscripten Python
+to the features present in Pyodide.
+
+Pyodide is maintained `on GitHub <https://github.com/pyodide/pyodide>`__ and
+distributed via `jsDelivr <https://www.jsdelivr.com/oss-cdn/pyodide>`__, `npm
+<https://www.npmjs.com/package/pyodide>`__, and `GitHub releases
+<https://github.com/pyodide/pyodide/releases>`__.
+
+Emscripten Python is not distributed, but it is possible to build `by following
+the instructions in the devguide
+<https://devguide.python.org/getting-started/setup-building/#emscripten>`__
+
 Background on Emscripten
 ------------------------
 
@@ -792,7 +809,9 @@ Because Emscripten supports POSIX, a significant number of tasks can be achieved
 using the ``os`` module. However, many fundamental operations in JavaScript
 runtimes are not possible via POSIX APIs. Pyodide's approach is to specify a
 mapping between the JavaScript object model and the Python object model and a
-calling convention that allows high level bidirectional integration.
+calling convention that allows high level bidirectional integration. `See the
+Pyodide documentation
+<https://pyodide.org/en/stable/usage/type-conversions.html>`__.
 
 Asyncio
 ~~~~~~~