Merge branch 'main' into deepcopy_c_implementation

python · eendebakpt · Apr 16, 2022 · Apr 16, 2022 · Apr 16, 2022 · Jun 15, 2022
commit 73b1300c3747a45bc10b679cbbf04bb22d884b95
diff --git a/.gitattributes b/.gitattributes
@@ -62,26 +62,27 @@ PCbuild/readme.txt  dos
 #
 [attr]generated linguist-generated=true diff=generated
 
-**/clinic/*.c.h                              generated
-*_db.h                                       generated
-Doc/data/stable_abi.dat                      generated
-Doc/library/token-list.inc                   generated
-Include/internal/pycore_ast.h                generated
-Include/internal/pycore_ast_state.h          generated
-Include/internal/pycore_opcode.h             generated
-Include/opcode.h                             generated
-Include/token.h                              generated
-Lib/keyword.py                               generated
-Lib/test/test_stable_abi_ctypes.py           generated
-Lib/token.py                                 generated
-Objects/typeslots.inc                        generated
-PC/python3dll.c                              generated
-Parser/parser.c                              generated
-Parser/token.c                               generated
-Programs/test_frozenmain.h                   generated
-Python/Python-ast.c                          generated
-Python/opcode_targets.h                      generated
-Python/stdlib_module_names.h                 generated
-Tools/peg_generator/pegen/grammar_parser.py  generated
-aclocal.m4                                   generated
-configure                                    generated
+**/clinic/*.c.h                                     generated
+*_db.h                                              generated
+Doc/data/stable_abi.dat                             generated
+Doc/library/token-list.inc                          generated
+Include/internal/pycore_ast.h                       generated
+Include/internal/pycore_ast_state.h                 generated
+Include/internal/pycore_opcode.h                    generated
+Include/internal/pycore_runtime_init_generated.h    generated
+Include/opcode.h                                    generated
+Include/token.h                                     generated
+Lib/keyword.py                                      generated
+Lib/test/test_stable_abi_ctypes.py                  generated
+Lib/token.py                                        generated
+Objects/typeslots.inc                               generated
+PC/python3dll.c                                     generated
+Parser/parser.c                                     generated
+Parser/token.c                                      generated
+Programs/test_frozenmain.h                          generated
+Python/Python-ast.c                                 generated
+Python/opcode_targets.h                             generated
+Python/stdlib_module_names.h                        generated
+Tools/peg_generator/pegen/grammar_parser.py         generated
+aclocal.m4                                          generated
+configure                                           generated
diff --git a/Doc/c-api/allocation.rst b/Doc/c-api/allocation.rst
@@ -14,7 +14,7 @@ Allocating Objects on the Heap
 
 .. c:function:: PyObject* PyObject_Init(PyObject *op, PyTypeObject *type)
 
-   Initialize a newly-allocated object *op* with its type and initial
+   Initialize a newly allocated object *op* with its type and initial
    reference.  Returns the initialized object.  If *type* indicates that the
    object participates in the cyclic garbage detector, it is added to the
    detector's set of observed objects. Other fields of the object are not

diff --git a/Doc/c-api/datetime.rst b/Doc/c-api/datetime.rst
@@ -132,13 +132,15 @@ Macros to create objects:
    resulting number of microseconds and seconds lie in the ranges documented for
    :class:`datetime.timedelta` objects.
 
+
 .. c:function:: PyObject* PyTimeZone_FromOffset(PyDateTime_DeltaType* offset)
 
    Return a :class:`datetime.timezone` object with an unnamed fixed offset
    represented by the *offset* argument.
 
    .. versionadded:: 3.7
 
+
 .. c:function:: PyObject* PyTimeZone_FromOffsetAndName(PyDateTime_DeltaType* offset, PyUnicode* name)
 
    Return a :class:`datetime.timezone` object with a fixed offset represented
@@ -190,12 +192,21 @@ must not be ``NULL``, and the type is not checked:
 
    Return the microsecond, as an int from 0 through 999999.
 
+
+.. c:function:: int PyDateTime_DATE_GET_FOLD(PyDateTime_DateTime *o)
+
+   Return the fold, as an int from 0 through 1.
+
+   .. versionadded:: 3.6
+
+
 .. c:function:: PyObject* PyDateTime_DATE_GET_TZINFO(PyDateTime_DateTime *o)
 
    Return the tzinfo (which may be ``None``).
 
    .. versionadded:: 3.10
 
+
 Macros to extract fields from time objects.  The argument must be an instance of
 :c:data:`PyDateTime_Time`, including subclasses. The argument must not be ``NULL``,
 and the type is not checked:
@@ -219,6 +230,14 @@ and the type is not checked:
 
    Return the microsecond, as an int from 0 through 999999.
 
+
+.. c:function:: int PyDateTime_TIME_GET_FOLD(PyDateTime_Time *o)
+
+   Return the fold, as an int from 0 through 1.
+
+   .. versionadded:: 3.6
+
+
 .. c:function:: PyObject* PyDateTime_TIME_GET_TZINFO(PyDateTime_Time *o)
 
    Return the tzinfo (which may be ``None``).

diff --git a/Doc/c-api/intro.rst b/Doc/c-api/intro.rst
@@ -779,7 +779,7 @@ A full list of the various types of debugging builds is in the file
 :file:`Misc/SpecialBuilds.txt` in the Python source distribution. Builds are
 available that support tracing of reference counts, debugging the memory
 allocator, or low-level profiling of the main interpreter loop.  Only the most
-frequently-used builds will be described in the remainder of this section.
+frequently used builds will be described in the remainder of this section.
 
 Compiling the interpreter with the :c:macro:`Py_DEBUG` macro defined produces
 what is generally meant by :ref:`a debug build of Python <debug-build>`.

diff --git a/Doc/c-api/memory.rst b/Doc/c-api/memory.rst
@@ -75,7 +75,7 @@ memory manager. For example, this is required when the interpreter is extended
 with new object types written in C. Another reason for using the Python heap is
 the desire to *inform* the Python memory manager about the memory needs of the
 extension module. Even when the requested memory is used exclusively for
-internal, highly-specific purposes, delegating all memory requests to the Python
+internal, highly specific purposes, delegating all memory requests to the Python
 memory manager causes the interpreter to have a more accurate image of its
 memory footprint as a whole. Consequently, under certain circumstances, the
 Python memory manager may or may not trigger appropriate actions, like garbage

diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst
@@ -529,7 +529,7 @@ type objects) *must* have the :attr:`ob_size` field.
    ``PyObject_HEAD_INIT`` macro.  For :ref:`statically allocated objects
    <static-types>`, these fields always remain ``NULL``.  For :ref:`dynamically
    allocated objects <heap-types>`, these two fields are used to link the
-   object into a doubly-linked list of *all* live objects on the heap.
+   object into a doubly linked list of *all* live objects on the heap.
 
    This could be used for various debugging purposes; currently the only uses
    are the :func:`sys.getobjects` function and to print the objects that are

diff --git a/Doc/c-api/weakref.rst b/Doc/c-api/weakref.rst
@@ -35,7 +35,7 @@ as much as it can.
    callable object that receives notification when *ob* is garbage collected; it
    should accept a single parameter, which will be the weak reference object
    itself. *callback* may also be ``None`` or ``NULL``.  If *ob* is not a
-   weakly-referencable object, or if *callback* is not callable, ``None``, or
+   weakly referencable object, or if *callback* is not callable, ``None``, or
    ``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
 
 
@@ -47,7 +47,7 @@ as much as it can.
    be a callable object that receives notification when *ob* is garbage
    collected; it should accept a single parameter, which will be the weak
    reference object itself. *callback* may also be ``None`` or ``NULL``.  If *ob*
-   is not a weakly-referencable object, or if *callback* is not callable,
+   is not a weakly referencable object, or if *callback* is not callable,
    ``None``, or ``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
 
 

diff --git a/Doc/distutils/apiref.rst b/Doc/distutils/apiref.rst
@@ -1198,7 +1198,7 @@ other utility module.
    it contains certain values: see :func:`check_environ`.  Raise :exc:`ValueError`
    for any variables not found in either *local_vars* or ``os.environ``.
 
-   Note that this is not a fully-fledged string interpolation function. A valid
+   Note that this is not a full-fledged string interpolation function. A valid
    ``$variable`` can consist only of upper and lower case letters, numbers and an
    underscore. No { } or ( ) style quoting is available.
 

diff --git a/Doc/extending/building.rst b/Doc/extending/building.rst
@@ -17,7 +17,7 @@ The initialization function has the signature:
 
 .. c:function:: PyObject* PyInit_modulename(void)
 
-It returns either a fully-initialized module, or a :c:type:`PyModuleDef`
+It returns either a fully initialized module, or a :c:type:`PyModuleDef`
 instance. See :ref:`initializing-modules` for details.
 
 .. highlight:: python

diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
@@ -175,7 +175,7 @@ example::
    }
 
 If no :c:member:`~PyTypeObject.tp_repr` handler is specified, the interpreter will supply a
-representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely-identifying
+representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely identifying
 value for the object.
 
 The :c:member:`~PyTypeObject.tp_str` handler is to :func:`str` what the :c:member:`~PyTypeObject.tp_repr` handler
@@ -589,7 +589,7 @@ with the required field::
        PyObject *weakreflist;  /* List of weak references */
    } TrivialObject;
 
-And the corresponding member in the statically-declared type object::
+And the corresponding member in the statically declared type object::
 
    static PyTypeObject TrivialType = {
        PyVarObject_HEAD_INIT(NULL, 0)

diff --git a/Doc/faq/design.rst b/Doc/faq/design.rst
@@ -313,7 +313,7 @@ you're too lazy to define a function.
 
 Functions are already first class objects in Python, and can be declared in a
 local scope.  Therefore the only advantage of using a lambda instead of a
-locally-defined function is that you don't need to invent a name for the
+locally defined function is that you don't need to invent a name for the
 function -- but that's just a local variable to which the function object (which
 is exactly the same type of object that a lambda expression yields) is assigned!
 

diff --git a/Doc/faq/programming.rst b/Doc/faq/programming.rst
@@ -294,7 +294,7 @@ It's good practice if you import modules in the following order:
 1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
 2. third-party library modules (anything installed in Python's site-packages
    directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
-3. locally-developed modules
+3. locally developed modules
 
 It is sometimes necessary to move imports to a function or class to avoid
 problems with circular imports.  Gordon McMillan says:
@@ -771,7 +771,7 @@ What does the slash(/) in the parameter list of a function mean?
 
 A slash in the argument list of a function denotes that the parameters prior to
 it are positional-only.  Positional-only parameters are the ones without an
-externally-usable name.  Upon calling a function that accepts positional-only
+externally usable name.  Upon calling a function that accepts positional-only
 parameters, arguments are mapped to parameters based solely on their position.
 For example, :func:`divmod` is a function that accepts positional-only
 parameters. Its documentation looks like this::

diff --git a/Doc/glossary.rst b/Doc/glossary.rst
@@ -532,7 +532,7 @@ Glossary
       machines.
 
       However, some extension modules, either standard or third-party,
-      are designed so as to release the GIL when doing computationally-intensive
+      are designed so as to release the GIL when doing computationally intensive
       tasks such as compression or hashing.  Also, the GIL is always released
       when doing I/O.
 

diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
@@ -541,7 +541,7 @@ Let's dive in!
 
 16. Compile, then run the relevant portions of the regression-test suite.
     This change should not introduce any new compile-time warnings or errors,
-    and there should be no externally-visible change to Python's behavior.
+    and there should be no externally visible change to Python's behavior.
 
     Well, except for one difference: ``inspect.signature()`` run on your function
     should now provide a valid signature!
@@ -1117,7 +1117,7 @@ Here's the syntax for cloning a function::
 ``module.class`` in the sample just to illustrate that you must
 use the full path to *both* functions.)
 
-Sorry, there's no syntax for partially-cloning a function, or cloning a function
+Sorry, there's no syntax for partially cloning a function, or cloning a function
 then modifying it.  Cloning is an all-or nothing proposition.
 
 Also, the function you are cloning from must have been previously defined
@@ -1315,7 +1315,7 @@ to specify in your subclass.  Here's the current list:
     there is no default, but not specifying a default may
     result in an "uninitialized variable" warning.  This can
     easily happen when using option groups—although
-    properly-written code will never actually use this value,
+    properly written code will never actually use this value,
     the variable does get passed in to the impl, and the
     C compiler will complain about the "use" of the
     uninitialized value.  This value should always be a

diff --git a/Doc/howto/functional.rst b/Doc/howto/functional.rst
@@ -741,7 +741,7 @@ further because you risk skipping a discarded element.
 The itertools module
 ====================
 
-The :mod:`itertools` module contains a number of commonly-used iterators as well
+The :mod:`itertools` module contains a number of commonly used iterators as well
 as functions for combining several iterators.  This section will introduce the
 module's contents by showing small examples.
 

diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
@@ -31,4 +31,5 @@ Currently, the HOWTOs are:
    clinic.rst
    instrumentation.rst
    annotations.rst
+   isolating-extensions.rst
 
diff --git a/Doc/howto/instrumentation.rst b/Doc/howto/instrumentation.rst
@@ -123,7 +123,7 @@ Sufficiently modern readelf can print the metadata::
             Arguments: 8@%rbp 8@%r12 -4@%eax
 
 The above metadata contains information for SystemTap describing how it
-can patch strategically-placed machine code instructions to enable the
+can patch strategically placed machine code instructions to enable the
 tracing hooks used by a SystemTap script.
 
 
@@ -410,7 +410,7 @@ needing to directly name the static markers:
 
 
 The following script uses the tapset above to provide a top-like view of all
-running CPython code, showing the top 20 most frequently-entered bytecode
+running CPython code, showing the top 20 most frequently entered bytecode
 frames, each second, across the whole system:
 
 .. code-block:: none