Merge branch 'main' into gh-93963/remove-importlib-resources-abcs

Author: jaraco

.gitattributes

@@ -28,8 +28,8 @@ Lib/test/cjkencodings/*                    noeol
 Lib/test/coding20731.py                    noeol
 Lib/test/decimaltestdata/*.decTest         noeol
 Lib/test/test_email/data/*.txt             noeol
-Lib/test/test_importlib/data01/*           noeol
-Lib/test/test_importlib/namespacedata01/*  noeol
+Lib/test/test_importlib/resources/data01/*           noeol
+Lib/test/test_importlib/resources/namespacedata01/*  noeol
 Lib/test/xmltestdata/*                     noeol
 
 # CRLF files

.github/CODEOWNERS

@@ -61,7 +61,7 @@ Python/pythonrun.c            @iritkatriel
 # bytecode.
 **/*import*.c                 @brettcannon @encukou @ericsnowcurrently @ncoghlan @warsaw
 **/*import*.py                @brettcannon @encukou @ericsnowcurrently @ncoghlan @warsaw
-**/importlib/resources/*      @jaraco @warsaw @brettcannon
+**/*importlib/resources/*      @jaraco @warsaw @brettcannon
 **/importlib/metadata/*       @jaraco @warsaw
 
 # Dates and times

.github/ISSUE_TEMPLATE/bug.md

@@ -15,12 +15,12 @@ labels: "type-bug"
     your problem has already been reported
 -->
 
-**Bug report**
+# Bug report
 
 A clear and concise description of what the bug is.
 Include a minimal, reproducible example (https://stackoverflow.com/help/minimal-reproducible-example), if possible.
 
-**Your environment**
+# Your environment
 
 <!-- Include as many relevant details as possible about the environment you experienced the bug in -->
 

.github/ISSUE_TEMPLATE/crash.md

@@ -13,15 +13,15 @@ labels: "type-crash"
   For CPython, a "crash" is when Python itself fails, leading to a traceback in the C stack.
 -->
 
-**Crash report**
+# Crash report
 
 Tell us what happened, ideally including a minimal, reproducible example (https://stackoverflow.com/help/minimal-reproducible-example).
 
-**Error messages**
+# Error messages
 
 Enter any relevant error message caused by the crash, including a core dump if there is one.
 
-**Your environment**
+# Your environment
 
 <!-- Include as many relevant details as possible about the environment you experienced the bug in -->
 

.github/ISSUE_TEMPLATE/documentation.md

@@ -4,6 +4,6 @@ about: Report a problem with the documentation
 labels: "docs"
 ---
 
-**Documentation**
+# Documentation
 
 (A clear and concise description of the issue.)

.github/ISSUE_TEMPLATE/feature.md

@@ -4,16 +4,16 @@ about: Submit a proposal for a new CPython feature or enhancement
 labels: "type-feature"
 ---
 
-**Feature or enhancement**
+# Feature or enhancement
 
 (A clear and concise description of your proposal.)
 
-**Pitch**
+# Pitch
 
 (Explain why this feature or enhancement should be implemented and how it would be used.
  Add examples, if applicable.)
 
-**Previous discussion**
+# Previous discussion
 
 <!--
   New features to Python should first be discussed elsewhere before creating issues on GitHub,

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``).

Doc/c-api/long.rst

@@ -84,14 +84,15 @@ distinguished from a number.  Use :c:func:`PyErr_Occurred` to disambiguate.
 .. c:function:: PyObject* PyLong_FromString(const char *str, char **pend, int base)
 
    Return a new :c:type:`PyLongObject` based on the string value in *str*, which
-   is interpreted according to the radix in *base*.  If *pend* is non-``NULL``,
-   *\*pend* will point to the first character in *str* which follows the
-   representation of the number.  If *base* is ``0``, *str* is interpreted using
-   the :ref:`integers` definition; in this case, leading zeros in a
-   non-zero decimal number raises a :exc:`ValueError`. If *base* is not ``0``,
-   it must be between ``2`` and ``36``, inclusive.  Leading spaces and single
-   underscores after a base specifier and between digits are ignored.  If there
-   are no digits, :exc:`ValueError` will be raised.
+   is interpreted according to the radix in *base*, or ``NULL`` on failure.  If
+   *pend* is non-``NULL``, *\*pend* will point to the end of *str* on success or
+   to the first character that could not be processed on error.  If *base* is ``0``,
+   *str* is interpreted using the :ref:`integers` definition; in this case, leading
+   zeros in a non-zero decimal number raises a :exc:`ValueError`.  If *base* is not
+   ``0``, it must be between ``2`` and ``36``, inclusive.  Leading and trailing
+   whitespace and single underscores after a base specifier and between digits are
+   ignored.  If there are no digits or *str* is not NULL-terminated following the
+   digits and trailing whitespace, :exc:`ValueError` will be raised.
 
 
 .. c:function:: PyObject* PyLong_FromUnicodeObject(PyObject *u, int base)

Doc/c-api/typeobj.rst

@@ -1942,6 +1942,13 @@ and :c:type:`PyType_Type` effectively act as defaults.)
    Weak reference list head, for weak references to this type object.  Not
    inherited.  Internal use only.
 
+   .. versionchanged:: 3.12
+
+      Internals detail: For the static builtin types this is always ``NULL``,
+      even if weakrefs are added.  Instead, the weakrefs for each are stored
+      on ``PyInterpreterState``.  Use the public C-API or the internal
+      ``_PyObject_GET_WEAKREFS_LISTPTR()`` macro to avoid the distinction.
+
    **Inheritance:**
 
    This field is not inherited.

Doc/c-api/unicode.rst

@@ -819,7 +819,7 @@ wchar_t Support
    most C functions. If *size* is ``NULL`` and the :c:type:`wchar_t*` string
    contains null characters a :exc:`ValueError` is raised.
 
-   Returns a buffer allocated by :c:func:`PyMem_Alloc` (use
+   Returns a buffer allocated by :c:func:`PyMem_New` (use
    :c:func:`PyMem_Free` to free it) on success. On error, returns ``NULL``
    and *\*size* is undefined. Raises a :exc:`MemoryError` if memory allocation
    is failed.

Doc/contents.rst

@@ -27,5 +27,4 @@
 .. toctree::
    :hidden:
 
-   distutils/index.rst
    install/index.rst

Doc/distributing/index.rst

@@ -41,21 +41,21 @@ Key terms
   file format standards. They maintain a variety of tools, documentation
   and issue trackers on both `GitHub <https://github.com/pypa>`__ and
   `Bitbucket <https://bitbucket.org/pypa/>`__.
-* :mod:`distutils` is the original build and distribution system first added
-  to the Python standard library in 1998. While direct use of :mod:`distutils`
+* ``distutils`` is the original build and distribution system first added
+  to the Python standard library in 1998. While direct use of ``distutils``
   is being phased out, it still laid the foundation for the current packaging
   and distribution infrastructure, and it not only remains part of the
   standard library, but its name lives on in other ways (such as the name
   of the mailing list used to coordinate Python packaging standards
   development).
-* `setuptools`_ is a (largely) drop-in replacement for :mod:`distutils` first
+* `setuptools`_ is a (largely) drop-in replacement for ``distutils`` first
   published in 2004. Its most notable addition over the unmodified
-  :mod:`distutils` tools was the ability to declare dependencies on other
+  ``distutils`` tools was the ability to declare dependencies on other
   packages. It is currently recommended as a more regularly updated
-  alternative to :mod:`distutils` that offers consistent support for more
+  alternative to ``distutils`` that offers consistent support for more
   recent packaging standards across a wide range of Python versions.
 * `wheel`_ (in this context) is a project that adds the ``bdist_wheel``
-  command to :mod:`distutils`/`setuptools`_. This produces a cross platform
+  command to ``distutils``/`setuptools`_. This produces a cross platform
   binary packaging format (called "wheels" or "wheel files" and defined in
   :pep:`427`) that allows Python libraries, even those including binary
   extensions, to be installed on a system without needing to be built