Merge branch 'main' into tidying

Author: hugovk

.github/CODEOWNERS

@@ -641,6 +641,8 @@ peps/pep-0760.rst  @pablogsal @brettcannon
 peps/pep-0761.rst  @sethmlarson @hugovk
 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-0777.rst  @warsaw
 # ...

peps/pep-0011.rst

@@ -103,7 +103,7 @@ Target Triple                 Notes                      Contacts
 aarch64-unknown-linux-gnu     glibc, gcc                 Petr Viktorin, Victor Stinner
 
                               glibc, clang               Victor Stinner, Gregory P. Smith
-wasm32-unknown-wasi           WASI SDK, Wasmtime         Brett Cannon, Eric Snow
+wasm32-unknown-wasip1         WASI SDK, Wasmtime         Brett Cannon, Eric Snow
 x86_64-unknown-linux-gnu      glibc, clang               Victor Stinner, Gregory P. Smith
 ============================= ========================== ========
 

peps/pep-0012/pep-NNNN.rst

@@ -1,8 +1,8 @@
 PEP: <REQUIRED: pep number>
 Title: <REQUIRED: pep title>
-Author: <REQUIRED: list of authors' real names and optionally, email addrs>
-Sponsor: <real name of sponsor>
-PEP-Delegate: <PEP delegate's real name>
+Author: <REQUIRED: list of authors' names and optionally, email addrs>
+Sponsor: <name of sponsor>
+PEP-Delegate: <PEP delegate's name>
 Discussions-To: <REQUIRED: URL of current canonical discussion thread>
 Status: <REQUIRED: Draft | Active | Accepted | Provisional | Deferred | Rejected | Withdrawn | Final | Superseded>
 Type: <REQUIRED: Standards Track | Informational | Process>

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-0440.rst

@@ -1624,7 +1624,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-0525.rst

@@ -336,7 +336,7 @@ The following methods and properties are defined:
 
        v = await g.athrow(ZeroDivisionError)
        print(v)                # Will print 'world' after
-                               $ sleeping 0.2 seconds.
+                               # sleeping 0.2 seconds.
 
 5. ``agen.aclose()``: Returns an *awaitable*, that throws a
    ``GeneratorExit`` exception into the generator.  The *awaitable* can

peps/pep-0540.rst

@@ -256,7 +256,7 @@ The "Legacy Windows FS encoding" is enabled by the
 ``PYTHONLEGACYWINDOWSFSENCODING`` environment variable.
 
 If stdin and/or stdout is redirected to a pipe, ``sys.stdin`` and/or
-``sys.output`` uses ``mbcs`` encoding by default rather than UTF-8.
+``sys.stdout`` uses ``mbcs`` encoding by default rather than UTF-8.
 But in UTF-8 Mode, ``sys.stdin`` and ``sys.stdout`` always use the UTF-8
 encoding.
 

peps/pep-0601.rst

@@ -8,6 +8,7 @@ Type: Standards Track
 Created: 26-Aug-2019
 Python-Version: 3.8
 Post-History: 26-Aug-2019, 23-Sep-2019
+Superseded-By: 765
 Resolution: https://discuss.python.org/t/pep-601-forbid-return-break-continue-breaking-out-of-finally/2239/32
 
 Rejection Note

peps/pep-0672.rst

@@ -39,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
@@ -378,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

peps/pep-0719.rst

@@ -52,9 +52,29 @@ Actual:
 - 3.13.0 candidate 3: Tuesday, 2024-10-01
 - 3.13.0 final: Monday, 2024-10-07
 
+Bugfix releases
+---------------
+
 Expected:
 
-Subsequent bugfix releases every two months.
+- 3.13.1: Tuesday, 2024-12-03
+- 3.13.2: Tuesday, 2025-02-04
+- 3.13.3: Tuesday, 2025-04-08
+- 3.13.4: Tuesday, 2025-06-03
+- 3.13.5: Tuesday, 2025-08-05
+- 3.13.6: Tuesday, 2025-10-07
+- 3.13.7: Tuesday, 2025-12-02
+- 3.13.8: Tuesday, 2026-02-03
+- 3.13.9: Tuesday, 2026-04-07
+- 3.13.10: Tuesday, 2026-06-09
+- 3.13.11: Tuesday, 2026-08-04
+- 3.13.12: Tuesday, 2026-10-06
+
+
+Source-only security fix releases
+---------------------------------
+
+Provided irregularly on an as-needed basis until October 2029.
 
 
 3.13 Lifespan