Merge branch 'main' into warsaw/pep-694-updates

Author: warsaw

.github/CODEOWNERS

@@ -643,6 +643,7 @@ peps/pep-0762.rst  @pablogsal @ambv @lysnikolaou @emilyemorehouse
 peps/pep-0763.rst  @dstufft
 peps/pep-0765.rst  @iritkatriel @ncoghlan
 peps/pep-0766.rst  @warsaw
+peps/pep-0767.rst  @carljm
 # ...
 peps/pep-0777.rst  @warsaw
 # ...

peps/pep-0101.rst

@@ -33,10 +33,13 @@ Here's a hopefully-complete list.
 
 * A GPG key.
 
-  Python releases are digitally signed with GPG; you'll need a key,
-  which hopefully will be on the "web of trust" with at least one of
+  Python releases before 3.14 are digitally signed with GPG; for these you'll
+  need a key, which hopefully will be on the "web of trust" with at least one of
   the other release managers.
 
+  .. note:: GPG instructions in this PEP can be ignored for Python 3.14 and
+            later. See :pep:`761` for details.
+
 * A bunch of software:
 
   * A checkout of the `python/release-tools`_ repo.
@@ -263,20 +266,6 @@ to perform some manual editing steps.
 - Make sure all changes have been committed.  (``release.py --bump``
   doesn't check in its changes for you.)
 
-- Check the years on the copyright notice.  If the last release
-  was some time last year, add the current year to the copyright
-  notice in several places:
-
-  - ``README``
-  - ``LICENSE`` (make sure to change on ``main`` and the branch)
-  - ``Python/getcopyright.c``
-  - ``Doc/copyright.rst``
-  - ``Doc/license.rst``
-  - ``PC/python_ver_rc.h`` sets up the DLL version resource for Windows
-    (displayed when you right-click on the DLL and select
-    Properties).  This isn't a C include file, it's a Windows
-    "resource file" include file.
-
 - For a **final** major release, edit the first paragraph of
   ``Doc/whatsnew/3.X.rst`` to include the actual release date; e.g. "Python
   2.5 was released on August 1, 2003."  There's no need to edit this for
@@ -610,7 +599,7 @@ the main repo.
   release branch (3.X-1) and use them as a template.
   https://github.com/python/cpython/settings/branches
 
-  Also, add a ``needs backport to 3.X`` label to the GitHub repo.
+  Also, add ``3.x`` and ``needs backport to 3.X`` labels to the GitHub repo.
   https://github.com/python/cpython/labels
 
 - You can now re-enable enforcement of branch settings against administrators
@@ -637,7 +626,7 @@ permissions.
   Python release "page", editing as you go.
 
   You can use `Markdown <https://daringfireball.net/projects/markdown/syntax>`_ or
-  `reStructured Text <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
+  `reStructured Text <https://docutils.sourceforge.io/docs/user/rst/quickref.html>`_
   to describe your release.  The former is less verbose, while the latter has nifty
   integration for things like referencing PEPs.
 
@@ -742,28 +731,20 @@ permissions.
 
   * python-list@python.org
   * python-announce@python.org
-  * python-dev@python.org
 
 - Also post the announcement to the
-  `Python Insider blog <http://blog.python.org>`_.
+  `Python Insider blog <https://blog.python.org>`_.
   To add a new entry, go to
-  `your Blogger home page, here <https://www.blogger.com/home>`_.
+  `your Blogger home page <https://www.blogger.com/home>`_.
 
-- Update any release PEPs (e.g. 719) with the release dates.
+- Update `release PEPs <https://peps.python.org/topic/release/>`__
+  (e.g. 719) with the release dates.
 
 - Update the labels on https://github.com/python/cpython/issues:
 
   - Flip all the `deferred-blocker`_ issues back to `release-blocker`_
     for the next release.
 
-  - Add version ``3.X+1`` as when version ``3.X`` enters alpha.
-
-  - Change non-doc feature requests to version ``3.X+1`` when version ``3.X``
-    enters beta.
-
-  - Update issues from versions that your release makes
-    unsupported to the next supported version.
-
   - Review open issues, as this might find lurking showstopper bugs,
     besides reminding people to fix the easy ones they forgot about.
 
@@ -788,7 +769,7 @@ permissions.
     or Zach Ware).
 
   - Ensure the various GitHub bots are updated, as needed, for the
-    new branch, in particular, make sure backporting to the new
+    new branch. In particular, make sure backporting to the new
     branch works (contact the `core-workflow team
     <https://github.com/python/core-workflow/issues>`__).
 
@@ -801,7 +782,7 @@ permissions.
     branches and that the release branch is properly protected (no direct
     pushes, etc).
 
-  - Verify that the `on-line docs <https://docs.python.org/>`__ are building
+  - Verify that the `online docs <https://docs.python.org/>`__ are building
     properly (this may take up to 24 hours for a complete build on the website).
 
 
@@ -869,12 +850,16 @@ else does them.  Some of those tasks include:
 
 - Retire the release from the `issue tracker`_. Tasks include:
 
+  * update issues from this version to the next supported version
+
   * remove version label from list of versions
 
   * remove the ``needs backport to`` label for the retired version
 
   * review and dispose of open issues marked for this branch
 
+- Run a final build of the online docs to add the end-of-life banner
+
 - Announce the branch retirement in the usual places:
 
   * `discuss.python.org`_

peps/pep-0352.rst

@@ -1,11 +1,8 @@
 PEP: 352
 Title: Required Superclass for Exceptions
-Version: $Revision$
-Last-Modified: $Date$
 Author: Brett Cannon, Guido van Rossum
 Status: Final
 Type: Standards Track
-Content-Type: text/x-rst
 Created: 27-Oct-2005
 Python-Version: 2.5
 Post-History:
@@ -276,24 +273,13 @@ References
 .. [#hierarchy-good] python-dev Summary for 2004-08-01 through 2004-08-15
    http://www.python.org/dev/summary/2004-08-01_2004-08-15.html#an-exception-is-an-exception-unless-it-doesn-t-inherit-from-exception
 
-.. [#SF_1104669] SF patch #1104669 (new-style exceptions)
-   https://bugs.python.org/issue1104669
-
 .. [#pycon2007-sprint-email]  python-3000 email ("How far to go with cleaning up exceptions")
     https://mail.python.org/pipermail/python-3000/2007-March/005911.html
 
+* Issue for new-style exceptions:
+  `python/cpython#41459 <https://github.com/python/cpython/issues/41459>`__
 
 Copyright
 =========
 
 This document has been placed in the public domain.
-
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   End:

peps/pep-0440.rst

@@ -1625,7 +1625,7 @@ project)::
             (?P<release>[0-9]+(?:\.[0-9]+)*)                  # release segment
             (?P<pre>                                          # pre-release
                 [-_\.]?
-                (?P<pre_l>(a|b|c|rc|alpha|beta|pre|preview))
+                (?P<pre_l>alpha|a|beta|b|preview|pre|c|rc)
                 [-_\.]?
                 (?P<pre_n>[0-9]+)?
             )?

peps/pep-0672.rst

@@ -3,7 +3,6 @@ Title: Unicode-related Security Considerations for Python
 Author: Petr Viktorin <encukou@gmail.com>
 Status: Active
 Type: Informational
-Content-Type: text/x-rst
 Created: 01-Nov-2021
 Post-History: 01-Nov-2021
 
@@ -40,7 +39,8 @@ This document purposefully does not give any solutions
 or recommendations: it is rather a list of things to keep in mind.
 
 This document is specific to Python.
-For general security considerations in Unicode text, see [tr36]_ and [tr39]_.
+For general security considerations in Unicode text and source code,
+see Unicode technical reports [tr36]_, [tr39]_, and [tr55]_.
 
 
 Acknowledgement
@@ -379,6 +379,8 @@ References
    http://www.unicode.org/reports/tr36/
 .. [tr39]   Unicode® Technical Standard #39: Unicode Security Mechanisms
    http://www.unicode.org/reports/tr39/
+.. [tr55]  Unicode Technical Report #55: Unicode Source Code Handling
+   http://www.unicode.org/reports/tr55/
 .. _CVE-2021-42574:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42574
 .. _`Encoding declarations`: https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations
@@ -391,15 +393,3 @@ Copyright
 
 This document is placed in the public domain or under the
 CC0-1.0-Universal license, whichever is more permissive.
-
-
-
-..
-    Local Variables:
-    mode: indented-text
-    indent-tabs-mode: nil
-    sentence-end-double-space: t
-    fill-column: 70
-    coding: utf-8
-    End:
-

peps/pep-0740.rst

@@ -6,14 +6,17 @@ Author: William Woodruff <william@yossarian.net>,
 Sponsor: Donald Stufft <donald@stufft.io>
 PEP-Delegate: Donald Stufft <donald@stufft.io>
 Discussions-To: https://discuss.python.org/t/pep-740-index-support-for-digital-attestations/44498
-Status: Provisional
+Status: Final
 Type: Standards Track
 Topic: Packaging
 Created: 08-Jan-2024
 Post-History: `02-Jan-2024 <https://discuss.python.org/t/pre-pep-exposing-trusted-publisher-provenance-on-pypi/42337>`__,
               `29-Jan-2024 <https://discuss.python.org/t/pep-740-index-support-for-digital-attestations/44498>`__
-Resolution: https://discuss.python.org/t/pep-740-index-support-for-digital-attestations/44498/26
+Resolution: `17-Jul-2024 <https://discuss.python.org/t/pep-740-index-support-for-digital-attestations/44498/26>`__
 
+.. canonical-pypa-spec:: :ref:`packaging:index-hosted-attestations`
+
+.. canonical-doc:: `PyPI - Digital Attestations <https://docs.pypi.org/attestations/>`__
 
 Abstract
 ========

peps/pep-0743.rst

@@ -3,7 +3,7 @@ Title: Add Py_COMPAT_API_VERSION to the Python C API
 Author: Victor Stinner <vstinner@python.org>,
         Petr Viktorin <encukou@gmail.com>,
 PEP-Delegate: C API Working Group
-Discussions-To: https://discuss.python.org/t/pep-743-add-py-compat-api-version-to-the-python-c-api/48243
+Discussions-To: https://discuss.python.org/t/pep-743-add-py-compat-api-version-to-the-python-c-api-take-2/59323
 Status: Draft
 Type: Standards Track
 Created: 11-Mar-2024
@@ -375,16 +375,22 @@ for one source file at a time.
 Discussions
 ===========
 
+* `PEP 743 – Add Py_COMPAT_API_VERSION to the Python C API (take 2)
+  <https://discuss.python.org/t/pep-743-add-py-compat-api-version-to-the-python-c-api-take-2/59323>`__
+  (July 2024)
+* `Finishing the Great Renaming
+  <https://discuss.python.org/t/finishing-the-great-renaming/54082>`_
+  (May 2024)
+* `PEP 743: Add Py_COMPAT_API_VERSION to the Python C API
+  <https://discuss.python.org/t/pep-743-add-py-compat-api-version-to-the-python-c-api/48243>`_
+  (March 2024)
 * C API Evolutions: `Macro to hide deprecated functions
   <https://github.com/capi-workgroup/api-evolution/issues/24>`_
   (October 2023)
 * C API Problems: `Opt-in macro for a new clean API? Subset of functions
   with no known issues
   <https://github.com/capi-workgroup/problems/issues/54>`_
   (June 2023)
-* `Finishing the Great Renaming
-  <https://discuss.python.org/t/finishing-the-great-renaming/54082>`_
-  (May 2024)
 
 
 Prior Art

peps/pep-0757.rst

@@ -2,7 +2,6 @@ PEP: 757
 Title: C API to import-export Python integers
 Author: Sergey B Kirpichev <skirpichev@gmail.com>,
         Victor Stinner <vstinner@python.org>
-PEP-Delegate: C API Working Group
 Discussions-To: https://discuss.python.org/t/63895
 Status: Draft
 Type: Standards Track
@@ -80,7 +79,7 @@ functions.
       - ``1`` for most significant digit first
       - ``-1`` for least significant digit first
 
-   .. c:member:: int8_t endianness
+   .. c:member:: int8_t digit_endianness
 
       Digit endianness:
 
@@ -178,19 +177,20 @@ create a Python :class:`int` object from a digits array.
 
    Create a :c:type:`PyLongWriter`.
 
-   On success, set *\*digits* and return a writer.
+   On success, allocate *\*digits* and return a writer.
    On error, set an exception and return ``NULL``.
 
    *negative* is ``1`` if the number is negative, or ``0`` otherwise.
 
-   *ndigits* is the number of digits in the *digits* array. It must be
-   greater than or equal to 0.
+   *ndigits* is the number of digits in the *digits* array.  It must be
+   greater than 0.
 
-   The caller can either initialize the array of digits *digits* and then call
-   :c:func:`PyLongWriter_Finish` to get a Python :class:`int`, or call
+   The caller can either initialize the array of digits *digits* and then
+   either call :c:func:`PyLongWriter_Finish` to get a Python :class:`int` or
    :c:func:`PyLongWriter_Discard` to destroy the writer instance.  Digits must
-   be in the range [``0``; ``(1 << sys.int_info.bits_per_digit) - 1``].  Unused
-   digits must be set to ``0``.
+   be in the range [``0``; ``(1 << bits_per_digit) - 1``]  (where the
+   :c:struct:`~PyLongLayout.bits_per_digit` is the number of bits per digit).
+   The unused most-significant digits must be set to ``0``.
 
 
 On CPython 3.14, the :c:func:`PyLongWriter_Create` implementation is a thin
@@ -207,11 +207,15 @@ wrapper to the private :c:func:`!_PyLong_New()` function.
    The function takes care of normalizing the digits and converts the
    object to a compact integer if needed.
 
+   The writer instance is invalid after the call.
+
 
 .. c:function:: void PyLongWriter_Discard(PyLongWriter *writer)
 
    Discard a :c:type:`PyLongWriter` created by :c:func:`PyLongWriter_Create`.
 
+   The writer instance is invalid after the call.
+
 
 Optimize import for small integers
 ==================================
@@ -253,7 +257,7 @@ Code::
     int int_digits_order = layout->digits_order;
     size_t int_bits_per_digit = layout->bits_per_digit;
     size_t int_nails = int_digit_size*8 - int_bits_per_digit;
-    int int_endianness = layout->endianness;
+    int int_endianness = layout->digit_endianness;
 
 
 Export: :c:func:`PyLong_Export()` with gmpy2