Merge remote-tracking branch 'upstream/3.13' into backport-c8ca336-3.13

Author: serhiy-storchaka

.github/workflows/reusable-context.yml

@@ -86,15 +86,6 @@ jobs:
             || ''
           }}
 
-    - name: 'Downgrade Git'
-      # Temporarily downgrade to 2.43 until 2.55 is in the runner image,
-      # to avoid "fatal: shallow file has changed since we read it" bug.
-      # See https://github.com/python/cpython/issues/151365.
-      if: github.event_name == 'pull_request'
-      run: |
-        sudo apt-get install -y --allow-downgrades 'git=1:2.43.*' 'git-man=1:2.43.*'
-        git --version
-
     # Adapted from https://github.com/actions/checkout/issues/520#issuecomment-1167205721
     - name: Fetch commits to get branch diff
       if: github.event_name == 'pull_request'

.github/workflows/reusable-docs.yml

@@ -47,14 +47,6 @@ jobs:
             && github.event.pull_request.head.sha
             || ''
           }}
-    - name: 'Downgrade Git'
-      # Temporarily downgrade to 2.43 until 2.55 is in the runner image,
-      # to avoid "fatal: shallow file has changed since we read it" bug.
-      # See https://github.com/python/cpython/issues/151365.
-      if: github.event_name == 'pull_request'
-      run: |
-        sudo apt-get install -y --allow-downgrades 'git=1:2.43.*' 'git-man=1:2.43.*'
-        git --version
     # Adapted from https://github.com/actions/checkout/issues/520#issuecomment-1167205721
     - name: 'Fetch commits to get branch diff'
       if: github.event_name == 'pull_request'
@@ -94,6 +86,9 @@ jobs:
           --fail-if-regression \
           --fail-if-improved \
           --fail-if-new-news-nit
+    - name: 'Build list of changes'
+      run: |
+        make -C Doc/ PYTHON=../python changes
 
   # Run "doctest" on HEAD as new syntax doesn't exist in the latest stable release
   doctest:

Doc/howto/curses.rst

@@ -298,15 +298,18 @@ the next subsection.
 
 The :meth:`~curses.window.addstr` method takes a Python string or
 bytestring as the value to be displayed.  The contents of bytestrings
-are sent to the terminal as-is.  Strings are encoded to bytes using
-the value of the window's :attr:`~window.encoding` attribute; this defaults to
-the default system encoding as returned by :func:`locale.getencoding`.
+are sent to the terminal as-is.
+On a build without wide-character support strings are encoded
+using the value of the window's :attr:`~window.encoding` attribute;
+this defaults to the default system encoding
+as returned by :func:`locale.getencoding`.
 
 The :meth:`~curses.window.addch` methods take a character, which can be
 either a string of length 1, a bytestring of length 1, or an integer.
 
-Constants are provided for extension characters; these constants are
-integers greater than 255.  For example, :const:`ACS_PLMINUS` is a +/-
+Constants are provided for the characters of the terminal's alternate
+character set.
+For example, :const:`ACS_PLMINUS` is a +/-
 symbol, and :const:`ACS_ULCORNER` is the upper left corner of a box
 (handy for drawing borders).  You can also use the appropriate Unicode
 character.
@@ -320,11 +323,11 @@ won't be distracting; it can be confusing to have the cursor blinking at some
 apparently random location.
 
 If your application doesn't need a blinking cursor at all, you can
-call ``curs_set(False)`` to make it invisible.  For compatibility
-with older curses versions, there's a ``leaveok(bool)`` function
-that's a synonym for :func:`~curses.curs_set`.  When *bool* is true, the
-curses library will attempt to suppress the flashing cursor, and you
-won't need to worry about leaving it in odd locations.
+call ``curs_set(False)`` to make it invisible.
+The window method :meth:`~curses.window.leaveok` does something different:
+when its argument is true,
+curses leaves the cursor wherever the last update put it,
+instead of moving it back to the window's cursor position.
 
 
 Attributes and Color
@@ -430,40 +433,48 @@ The C curses library offers only very simple input mechanisms. Python's
 :mod:`curses` module adds a basic text-input widget.  (Other libraries
 such as :pypi:`Urwid` have more extensive collections of widgets.)
 
-There are two methods for getting input from a window:
+There are three methods for getting input from a window:
 
-* :meth:`~curses.window.getch` refreshes the screen and then waits for
+* :meth:`~curses.window.get_wch` refreshes the screen and then waits for
   the user to hit a key, displaying the key if :func:`~curses.echo` has been
   called earlier.  You can optionally specify a coordinate to which
   the cursor should be moved before pausing.
 
-* :meth:`~curses.window.getkey` does the same thing but converts the
-  integer to a string.  Individual characters are returned as
-  1-character strings, and special keys such as function keys return
-  longer strings containing a key name such as ``KEY_UP`` or ``^G``.
+* :meth:`~curses.window.getch` does the same thing but returns the code of
+  the key instead of a character.
+  With ncurses this is a single byte of the key's encoding in the current
+  locale, so a character encoded with several bytes takes several calls,
+  one byte per call.
+
+* :meth:`~curses.window.getkey` does the same as :meth:`!getch` but returns
+  a string:
+  an ordinary key as a 1-character string,
+  and a special key as its name, such as ``KEY_UP``.
 
 It's possible to not wait for the user using the
 :meth:`~curses.window.nodelay` window method. After ``nodelay(True)``,
-:meth:`!getch` and :meth:`!getkey` for the window become
-non-blocking. To signal that no input is ready, :meth:`!getch` returns
-``curses.ERR`` (a value of -1) and :meth:`!getkey` raises an exception.
+the reads for the window become non-blocking.
+To signal that no input is ready,
+:meth:`!get_wch` and :meth:`!getkey` raise an exception,
+and :meth:`!getch` returns ``-1``.
 There's also a :func:`~curses.halfdelay` function, which can be used to (in
-effect) set a timer on each :meth:`!getch`; if no input becomes
+effect) set a timer on each read; if no input becomes
 available within a specified delay (measured in tenths of a second),
-curses raises an exception.
+the read fails the same way.
 
-The :meth:`!getch` method returns an integer; if it's between 0 and 255, it
-represents the ASCII code of the key pressed.  Values greater than 255 are
-special keys such as Page Up, Home, or the cursor keys. You can compare the
-value returned to constants such as :const:`curses.KEY_PPAGE`,
+Special keys such as Page Up, Home, or the cursor keys are returned by all
+three as one of the :ref:`KEY_* constants <curses-key-constants>`,
+all larger than 255.
+You can compare the value returned to constants such as
+:const:`curses.KEY_PPAGE`,
 :const:`curses.KEY_HOME`, or :const:`curses.KEY_LEFT`.  The main loop of
 your program may look something like this::
 
    while True:
-       c = stdscr.getch()
-       if c == ord('p'):
+       c = stdscr.get_wch()
+       if c == 'p':
            PrintDocument()
-       elif c == ord('q'):
+       elif c == 'q':
            break  # Exit the while loop
        elif c == curses.KEY_HOME:
            x = y = 0
@@ -475,15 +486,16 @@ conversion functions  that take either integer or 1-character-string arguments
 and return the same type.  For example, :func:`curses.ascii.ctrl` returns the
 control character corresponding to its argument.
 
-There's also a method to retrieve an entire string,
+There's also a method to retrieve an entire line,
 :meth:`~curses.window.getstr`.  It isn't used very often, because its
 functionality is quite limited; the only editing keys available are
-the backspace key and the Enter key, which terminates the string.  It
-can optionally be limited to a fixed number of characters. ::
+the erase and kill characters, and the Enter key, which terminates the line.
+It returns a bytes object,
+and can optionally be limited to a fixed number of bytes. ::
 
    curses.echo()            # Enable echoing of characters
 
-   # Get a 15-character string, with the cursor on the top line
+   # Get a line of at most 15 bytes, with the cursor on the top line
    s = stdscr.getstr(0,0, 15)
 
 The :mod:`curses.textpad` module supplies a text box that supports an

Doc/howto/logging-cookbook.rst

@@ -3912,7 +3912,7 @@ subclassed handler which looks something like this::
 
 You'll need to be familiar with RFC 5424 to fully understand the above code, and it
 may be that you have slightly different needs (e.g. for how you pass structural data
-to the log). Nevertheless, the above should be adaptable to your speciric needs. With
+to the log). Nevertheless, the above should be adaptable to your specific needs. With
 the above handler, you'd pass structured data using something like this::
 
     sd = {

Doc/howto/mro.rst

@@ -189,7 +189,7 @@ prescription:
   the tail of any of the other lists, then add it to the linearization
   of C and remove it from the lists in the merge, otherwise look at the
   head of the next list and take it, if it is a good head.  Then repeat
-  the operation until all the class are removed or it is impossible to
+  the operation until all the classes are removed or it is impossible to
   find good heads.  In this case, it is impossible to construct the
   merge, Python 2.3 will refuse to create the class C and will raise an
   exception.*

Doc/library/argparse.rst

@@ -734,7 +734,9 @@ how the command-line arguments should be handled. The supplied actions are:
     >>> parser.parse_args(['-vvv'])
     Namespace(verbose=3)
 
-  Note, the *default* will be ``None`` unless explicitly set to *0*.
+  Unless explicitly set, the *default* will be ``None``. If the default
+  value is a non-zero number, the count starts from that number rather
+  than from zero.
 
 * ``'help'`` - This prints a complete help message for all the options in the
   current parser and then exits. By default a help action is automatically

Doc/library/asyncio-task.rst

@@ -347,7 +347,7 @@ and reliable way to wait for all tasks in the group to finish.
       The signature matches that of :func:`asyncio.create_task`.
       If the task group is inactive (e.g. not yet entered,
       already finished, or in the process of shutting down),
-      we will close the given ``coro``.
+      we will close the given ``coro`` and raise :exc:`RuntimeError`.
 
       .. versionchanged:: 3.13
 

Doc/library/atexit.rst

@@ -9,59 +9,68 @@
 
 --------------
 
-The :mod:`atexit` module defines functions to register and unregister cleanup
-functions.  Functions thus registered are automatically executed upon normal
-interpreter termination.  :mod:`atexit` runs these functions in the *reverse*
-order in which they were registered; if you register ``A``, ``B``, and ``C``,
-at interpreter termination time they will be run in the order ``C``, ``B``,
-``A``.
-
-**Note:** The functions registered via this module are not called when the
+The :mod:`!atexit` module defines functions to register and unregister
+:dfn:`exit handlers`: functions that are automatically executed
+"at exit", that is, upon normal program termination (for instance,
+if :func:`sys.exit` is called or the main module's execution completes)
+or, more generally, upon :term:`interpreter shutdown`.
+
+At exit, all registered exit handlers are called
+in the *reverse* order in which they were registered.
+If you register ``A``, ``B``, and ``C``, at interpreter shutdown time they
+will be run in the order ``C``, ``B``, ``A``.
+The assumption is that lower level modules will normally be imported before
+higher level modules and thus must be cleaned up later.
+
+If an exception is raised during execution of an exit handler, a traceback is
+printed (unless :exc:`SystemExit` is raised) and the exception information is
+saved.  After all exit handlers have had a chance to run, the last exception to
+be raised is re-raised.
+
+In programs that use multiple interpreters, each interpreter has its own stack
+of exit handlers, which are executed when the interpreter shuts down
+(for example, with the C API function :c:func:`Py_EndInterpreter`).
+Registration functions in this module only affect the interpreter they are
+called from.
+
+**Note:** Exit handlers are not called when the
 program is killed by a signal not handled by Python, when a Python fatal
 internal error is detected, or when :func:`os._exit` is called.
 
 **Note:** The effect of registering or unregistering functions from within
 a cleanup function is undefined.
 
-.. versionchanged:: 3.7
-    When used with C-API subinterpreters, registered functions
-    are local to the interpreter they were registered in.
+.. warning::
+   When writing exit handlers, especially in C API extensions, keep in mind
+   that other exit handlers may still run arbitrary Python code after you
+   clean up.
+   Such code should succeed or fail with an exception, rather than crash.
 
-.. function:: register(func, *args, **kwargs)
+.. versionchanged:: 3.12
+   Attempts to start a new thread or :func:`os.fork` a new process
+   in an exit handler now leads to :exc:`RuntimeError`.
+   Previously, this could cause race conditions between the main Python
+   runtime thread freeing thread states while internal :mod:`threading`
+   routines or the new process try to use that state, which could lead to
+   crashes rather than clean shutdown.
 
-   Register *func* as a function to be executed at termination.  Any optional
-   arguments that are to be passed to *func* must be passed as arguments to
-   :func:`register`.  It is possible to register the same function and arguments
-   more than once.
+.. versionchanged:: 3.7
+   When used with subinterpreters, registered functions
+   are local to the interpreter they were registered in.
 
-   At normal program termination (for instance, if :func:`sys.exit` is called or
-   the main module's execution completes), all functions registered are called in
-   last in, first out order.  The assumption is that lower level modules will
-   normally be imported before higher level modules and thus must be cleaned up
-   later.
+.. function:: register(func, *args, **kwargs)
 
-   If an exception is raised during execution of the exit handlers, a traceback is
-   printed (unless :exc:`SystemExit` is raised) and the exception information is
-   saved.  After all exit handlers have had a chance to run, the last exception to
-   be raised is re-raised.
+   Register *func* as an exit handler.
+   Any optional arguments that are to be passed to *func* must be passed as
+   arguments to :func:`register`.
+   It is possible to register the same function and arguments more than once.
 
    This function returns *func*, which makes it possible to use it as a
    decorator.
 
-   .. warning::
-       Starting new threads or calling :func:`os.fork` from a registered
-       function can lead to race condition between the main Python
-       runtime thread freeing thread states while internal :mod:`threading`
-       routines or the new process try to use that state. This can lead to
-       crashes rather than clean shutdown.
-
-   .. versionchanged:: 3.12
-       Attempts to start a new thread or :func:`os.fork` a new process
-       in a registered function now leads to :exc:`RuntimeError`.
-
 .. function:: unregister(func)
 
-   Remove *func* from the list of functions to be run at interpreter shutdown.
+   Remove *func* from the list of exit handlers.
    :func:`unregister` silently does nothing if *func* was not previously
    registered.  If *func* has been registered more than once, every occurrence
    of that function in the :mod:`atexit` call stack will be removed.  Equality

Doc/library/colorsys.rst

@@ -21,7 +21,7 @@ spaces, the coordinates are all between 0 and 1.
 .. seealso::
 
    More information about color spaces can be found at
-   https://poynton.ca/ColorFAQ.html and
+   https://www.poynton.ca/pdf/ColourFAQ.pdf and
    https://www.cambridgeincolour.com/tutorials/color-spaces.htm.
 
 The :mod:`colorsys` module defines the following functions:

Doc/library/curses.rst

@@ -971,7 +971,8 @@ Window objects
 
 .. attribute:: window.encoding
 
-   Encoding used to encode method arguments (Unicode strings and characters).
+   Encoding used to encode the string arguments of the methods and to decode
+   their results on a build without wide-character support.
    The encoding attribute is inherited from the parent window when a subwindow
    is created, for example with :meth:`window.subwin`.
    By default, current locale encoding is used (see :func:`locale.getencoding`).