[pull] main from python:main

.github/actionlint.yaml

@@ -1,7 +1,6 @@
 self-hosted-runner:
-  # Pending https://github.com/rhysd/actionlint/issues/533
-  # and https://github.com/rhysd/actionlint/issues/571
-  labels: ["windows-11-arm", "macos-15-intel"]
+  # Pending https://github.com/rhysd/actionlint/pull/615
+  labels: ["windows-2025-vs2026"]
 
 config-variables: null
 

.github/workflows/tail-call.yml

@@ -52,7 +52,7 @@ jobs:
 #            runner: windows-2022
           - target: x86_64-pc-windows-msvc/msvc
             architecture: x64
-            runner: windows-2022
+            runner: windows-2025-vs2026
 #          - target: aarch64-pc-windows-msvc/msvc
 #            architecture: ARM64
 #            runner: windows-2022
@@ -83,8 +83,6 @@ jobs:
         if: runner.os == 'Windows' && matrix.architecture != 'ARM64'
         shell: pwsh
         run: |
-          choco install visualstudio2026buildtools --no-progress -y --force --params "--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64  --locale en-US --passive"
-          $env:PATH = "C:\Program Files (x86)\Microsoft Visual Studio\18\BuildTools\MSBuild\Current\bin;$env:PATH"
           $env:PlatformToolset = "v145"
           ./PCbuild/build.bat --tail-call-interp -c Release -p ${{ matrix.architecture }}
           ./PCbuild/rt.bat -p ${{ matrix.architecture }} -q --multiprocess 0 --timeout 4500 --verbose2 --verbose3

Doc/library/__future__.rst

@@ -15,25 +15,25 @@ before the release in which the feature becomes standard.
 
 While these future statements are given additional special meaning by the
 Python compiler, they are still executed like any other import statement and
-the :mod:`__future__` exists and is handled by the import system the same way
+the :mod:`!__future__` exists and is handled by the import system the same way
 any other Python module would be. This design serves three purposes:
 
 * To avoid confusing existing tools that analyze import statements and expect to
   find the modules they're importing.
 
 * To document when incompatible changes were introduced, and when they will be
   --- or were --- made mandatory.  This is a form of executable documentation, and
-  can be inspected programmatically via importing :mod:`__future__` and examining
+  can be inspected programmatically via importing :mod:`!__future__` and examining
   its contents.
 
 * To ensure that :ref:`future statements <future>` run under releases prior to
-  Python 2.1 at least yield runtime exceptions (the import of :mod:`__future__`
+  Python 2.1 at least yield runtime exceptions (the import of :mod:`!__future__`
   will fail, because there was no module of that name prior to 2.1).
 
 Module Contents
 ---------------
 
-No feature description will ever be deleted from :mod:`__future__`. Since its
+No feature description will ever be deleted from :mod:`!__future__`. Since its
 introduction in Python 2.1 the following features have found their way into the
 language using this mechanism:
 

Doc/library/argparse.rst

@@ -13,7 +13,7 @@
 
 .. note::
 
-   While :mod:`argparse` is the default recommended standard library module
+   While :mod:`!argparse` is the default recommended standard library module
    for implementing basic command line applications, authors with more
    exacting requirements for exactly how their command line applications
    behave may find it doesn't provide the necessary level of control.

Doc/library/ast.rst

@@ -15,7 +15,7 @@
 
 --------------
 
-The :mod:`ast` module helps Python applications to process trees of the Python
+The :mod:`!ast` module helps Python applications to process trees of the Python
 abstract syntax grammar.  The abstract syntax itself might change with each
 Python release; this module helps to find out programmatically what the current
 grammar looks like.
@@ -46,7 +46,7 @@ Node classes
    This is the base of all AST node classes.  The actual node classes are
    derived from the :file:`Parser/Python.asdl` file, which is reproduced
    :ref:`above <abstract-grammar>`.  They are defined in the :mod:`!_ast` C
-   module and re-exported in :mod:`ast`.
+   module and re-exported in :mod:`!ast`.
 
    There is one class defined for each left-hand side symbol in the abstract
    grammar (for example, :class:`ast.stmt` or :class:`ast.expr`).  In addition,
@@ -2200,10 +2200,10 @@ Async and await
    occurrences of the same value (for example, :class:`ast.Add`).
 
 
-:mod:`ast` helpers
-------------------
+:mod:`!ast` helpers
+-------------------
 
-Apart from the node classes, the :mod:`ast` module defines these utility functions
+Apart from the node classes, the :mod:`!ast` module defines these utility functions
 and classes for traversing abstract syntax trees:
 
 .. function:: parse(source, filename='<unknown>', mode='exec', *, type_comments=False, feature_version=None, optimize=-1, module=None)
@@ -2576,7 +2576,7 @@ Command-line usage
 
 .. versionadded:: 3.9
 
-The :mod:`ast` module can be executed as a script from the command line.
+The :mod:`!ast` module can be executed as a script from the command line.
 It is as simple as:
 
 .. code-block:: sh

Doc/library/atexit.rst

@@ -9,9 +9,9 @@
 
 --------------
 
-The :mod:`atexit` module defines functions to register and unregister cleanup
+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*
+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``.
@@ -64,22 +64,22 @@ a cleanup function is undefined.
    Remove *func* from the list of functions to be run at interpreter shutdown.
    :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
+   of that function in the :mod:`!atexit` call stack will be removed.  Equality
    comparisons (``==``) are used internally during unregistration, so function
    references do not need to have matching identities.
 
 
 .. seealso::
 
    Module :mod:`readline`
-      Useful example of :mod:`atexit` to read and write :mod:`readline` history
+      Useful example of :mod:`!atexit` to read and write :mod:`readline` history
       files.
 
 
 .. _atexit-example:
 
-:mod:`atexit` Example
----------------------
+:mod:`!atexit` Example
+----------------------
 
 The following simple example demonstrates how a module can initialize a counter
 from a file when it is imported and save the counter's updated value

Doc/library/base64.rst

@@ -247,8 +247,9 @@ Refer to the documentation of the individual functions for more information.
    after at most every *wrapcol* characters.
    If *wrapcol* is zero (default), do not insert any newlines.
 
-   *pad* controls whether the input is padded to a multiple of 4
-   before encoding. Note that the ``btoa`` implementation always pads.
+   If *pad* is true, the input is padded with ``b'\0'`` so its length is a
+   multiple of 4 bytes before encoding.
+   Note that the ``btoa`` implementation always pads.
 
    *adobe* controls whether the encoded byte sequence is framed with ``<~``
    and ``~>``, which is used by the Adobe implementation.
@@ -268,8 +269,9 @@ Refer to the documentation of the individual functions for more information.
    *adobe* controls whether the input sequence is in Adobe Ascii85 format
    (i.e. is framed with <~ and ~>).
 
-   *ignorechars* should be a byte string containing characters to ignore
-   from the input. This should only contain whitespace characters, and by
+   *ignorechars* should be a :term:`bytes-like object` containing characters
+   to ignore from the input.
+   This should only contain whitespace characters, and by
    default contains all whitespace characters in ASCII.
 
    .. versionadded:: 3.4

Doc/library/bdb.rst

@@ -8,7 +8,7 @@
 
 --------------
 
-The :mod:`bdb` module handles basic debugger functions, like setting breakpoints
+The :mod:`!bdb` module handles basic debugger functions, like setting breakpoints
 or managing execution via the debugger.
 
 The following exception is defined:
@@ -18,7 +18,7 @@ The following exception is defined:
    Exception raised by the :class:`Bdb` class for quitting the debugger.
 
 
-The :mod:`bdb` module also defines two classes:
+The :mod:`!bdb` module also defines two classes:
 
 .. class:: Breakpoint(self, file, line, temporary=False, cond=None, funcname=None)
 

Doc/library/binascii.rst

@@ -10,10 +10,10 @@
 
 --------------
 
-The :mod:`binascii` module contains a number of methods to convert between
+The :mod:`!binascii` module contains a number of methods to convert between
 binary and various ASCII-encoded binary representations. Normally, you will not
 use these functions directly but use wrapper modules like
-:mod:`base64` instead. The :mod:`binascii` module contains
+:mod:`base64` instead. The :mod:`!binascii` module contains
 low-level functions written in C for greater speed that are used by the
 higher-level modules.
 
@@ -28,7 +28,7 @@ higher-level modules.
       ASCII-only unicode strings are now accepted by the ``a2b_*`` functions.
 
 
-The :mod:`binascii` module defines the following functions:
+The :mod:`!binascii` module defines the following functions:
 
 
 .. function:: a2b_uu(string)
@@ -98,6 +98,112 @@ The :mod:`binascii` module defines the following functions:
       Added the *wrapcol* parameter.
 
 
+.. function:: a2b_ascii85(string, /, *, foldspaces=False, adobe=False, ignorechars=b"")
+
+   Convert Ascii85 data back to binary and return the binary data.
+
+   Valid Ascii85 data contains characters from the Ascii85 alphabet in groups
+   of five (except for the final group, which may have from two to five
+   characters). Each group encodes 32 bits of binary data in the range from
+   ``0`` to ``2 ** 32 - 1``, inclusive. The special character ``z`` is
+   accepted as a short form of the group ``!!!!!``, which encodes four
+   consecutive null bytes.
+
+   *foldspaces* is a flag that specifies whether the 'y' short sequence
+   should be accepted as shorthand for 4 consecutive spaces (ASCII 0x20).
+   This feature is not supported by the "standard" Ascii85 encoding.
+
+   *adobe* controls whether the input sequence is in Adobe Ascii85 format
+   (i.e. is framed with <~ and ~>).
+
+   *ignorechars* should be a :term:`bytes-like object` containing characters
+   to ignore from the input.
+   This should only contain whitespace characters.
+
+   Invalid Ascii85 data will raise :exc:`binascii.Error`.
+
+   .. versionadded:: next
+
+
+.. function:: b2a_ascii85(data, /, *, foldspaces=False, wrapcol=0, pad=False, adobe=False)
+
+   Convert binary data to a formatted sequence of ASCII characters in Ascii85
+   coding. The return value is the converted data.
+
+   *foldspaces* is an optional flag that uses the special short sequence 'y'
+   instead of 4 consecutive spaces (ASCII 0x20) as supported by 'btoa'. This
+   feature is not supported by the "standard" Ascii85 encoding.
+
+   If *wrapcol* is non-zero, insert a newline (``b'\n'``) character
+   after at most every *wrapcol* characters.
+   If *wrapcol* is zero (default), do not insert any newlines.
+
+   If *pad* is true, the input is padded with ``b'\0'`` so its length is a
+   multiple of 4 bytes before encoding.
+   Note that the ``btoa`` implementation always pads.
+
+   *adobe* controls whether the encoded byte sequence is framed with ``<~``
+   and ``~>``, which is used by the Adobe implementation.
+
+   .. versionadded:: next
+
+
+.. function:: a2b_base85(string, /)
+
+   Convert Base85 data back to binary and return the binary data.
+   More than one line may be passed at a time.
+
+   Valid Base85 data contains characters from the Base85 alphabet in groups
+   of five (except for the final group, which may have from two to five
+   characters). Each group encodes 32 bits of binary data in the range from
+   ``0`` to ``2 ** 32 - 1``, inclusive.
+
+   Invalid Base85 data will raise :exc:`binascii.Error`.
+
+   .. versionadded:: next
+
+
+.. function:: b2a_base85(data, /, *, pad=False)
+
+   Convert binary data to a line of ASCII characters in Base85 coding.
+   The return value is the converted line.
+
+   If *pad* is true, the input is padded with ``b'\0'`` so its length is a
+   multiple of 4 bytes before encoding.
+
+   .. versionadded:: next
+
+
+.. function:: a2b_z85(string, /)
+
+   Convert Z85 data back to binary and return the binary data.
+   More than one line may be passed at a time.
+
+   Valid Z85 data contains characters from the Z85 alphabet in groups
+   of five (except for the final group, which may have from two to five
+   characters). Each group encodes 32 bits of binary data in the range from
+   ``0`` to ``2 ** 32 - 1``, inclusive.
+
+   See `Z85 specification <https://rfc.zeromq.org/spec/32/>`_ for more information.
+
+   Invalid Z85 data will raise :exc:`binascii.Error`.
+
+   .. versionadded:: next
+
+
+.. function:: b2a_z85(data, /, *, pad=False)
+
+   Convert binary data to a line of ASCII characters in Z85 coding.
+   The return value is the converted line.
+
+   If *pad* is true, the input is padded with ``b'\0'`` so its length is a
+   multiple of 4 bytes before encoding.
+
+   See `Z85 specification <https://rfc.zeromq.org/spec/32/>`_ for more information.
+
+   .. versionadded:: next
+
+
 .. function:: a2b_qp(data, header=False)
 
    Convert a block of quoted-printable data back to binary and return the binary

Doc/library/bisect.rst

@@ -16,7 +16,7 @@ having to sort the list after each insertion.  For long lists of items with
 expensive comparison operations, this can be an improvement over
 linear searches or frequent resorting.
 
-The module is called :mod:`bisect` because it uses a basic bisection
+The module is called :mod:`!bisect` because it uses a basic bisection
 algorithm to do its work.  Unlike other bisection tools that search for a
 specific value, the functions in this module are designed to locate an
 insertion point. Accordingly, the functions never call an :meth:`~object.__eq__`
@@ -27,9 +27,9 @@ point between values in an array.
 .. note::
 
    The functions in this module are not thread-safe. If multiple threads
-   concurrently use :mod:`bisect` functions on the same sequence, this
+   concurrently use :mod:`!bisect` functions on the same sequence, this
    may result in undefined behaviour. Likewise, if the provided sequence
-   is mutated by a different thread while a :mod:`bisect` function
+   is mutated by a different thread while a :mod:`!bisect` function
    is operating on it, the result is undefined. For example, using
    :py:func:`~bisect.insort_left` on the same list from multiple threads
    may result in the list becoming unsorted.

Doc/library/bz2.rst

@@ -16,7 +16,7 @@
 This module provides a comprehensive interface for compressing and
 decompressing data using the bzip2 compression algorithm.
 
-The :mod:`bz2` module contains:
+The :mod:`!bz2` module contains:
 
 * The :func:`.open` function and :class:`BZ2File` class for reading and
   writing compressed files.
@@ -317,7 +317,7 @@ One-shot (de)compression
 Examples of usage
 -----------------
 
-Below are some examples of typical usage of the :mod:`bz2` module.
+Below are some examples of typical usage of the :mod:`!bz2` module.
 
 Using :func:`compress` and :func:`decompress` to demonstrate round-trip compression:
 

Doc/library/calendar.rst

@@ -452,7 +452,7 @@ For simple text calendars this module provides the following functions.
    inverse.
 
 
-The :mod:`calendar` module exports the following data attributes:
+The :mod:`!calendar` module exports the following data attributes:
 
 .. data:: day_name
 
@@ -578,7 +578,7 @@ The :mod:`calendar` module exports the following data attributes:
    .. versionadded:: 3.12
 
 
-The :mod:`calendar` module defines the following exceptions:
+The :mod:`!calendar` module defines the following exceptions:
 
 .. exception:: IllegalMonthError(month)
 
@@ -617,7 +617,7 @@ Command-line usage
 
 .. versionadded:: 2.5
 
-The :mod:`calendar` module can be executed as a script from the command line
+The :mod:`!calendar` module can be executed as a script from the command line
 to interactively print a calendar.
 
 .. code-block:: shell