Merge branch 'main' into pythongh-105623

.github/workflows/reusable-docs.yml

@@ -28,8 +28,6 @@ jobs:
         cache-dependency-path: 'Doc/requirements.txt'
     - name: 'Install build dependencies'
       run: make -C Doc/ venv
-    - name: 'Check documentation'
-      run: make -C Doc/ check
     - name: 'Build HTML documentation'
       run: make -C Doc/ SPHINXOPTS="-q" SPHINXERRORHANDLING="-W --keep-going" html
 
@@ -59,8 +57,6 @@ jobs:
         make -C Doc/ PYTHON=../python SPHINXOPTS="-q -n -W --keep-going" html 2>&1
 
   # This build doesn't use problem matchers or check annotations
-  # It also does not run 'make check', as sphinx-lint is not installed into the
-  # environment.
   build_doc_oldest_supported_sphinx:
     name: 'Docs (Oldest Sphinx)'
     runs-on: ubuntu-latest

.pre-commit-config.yaml

@@ -5,3 +5,11 @@ repos:
       - id: check-yaml
       - id: trailing-whitespace
         types_or: [c, python, rst]
+
+  - repo: https://github.com/sphinx-contrib/sphinx-lint
+    rev: v0.6.7
+    hooks:
+      - id: sphinx-lint
+        args: [--enable=default-role]
+        files: ^Doc/
+        types: [rst]

Doc/Makefile

@@ -216,11 +216,9 @@ dist:
 	rm dist/python-$(DISTVERSION)-docs-texinfo.tar
 
 .PHONY: check
-check:
-	# Check the docs and NEWS files with sphinx-lint.
-	# Ignore the tools and venv dirs and check that the default role is not used.
-	$(SPHINXLINT) -i tools -i $(VENVDIR) --enable default-role
-	$(SPHINXLINT) --enable default-role ../Misc/NEWS.d/next/
+check: venv
+	$(VENVDIR)/bin/python3 -m pre_commit --version > /dev/null || $(VENVDIR)/bin/python3 -m pip install pre-commit
+	$(VENVDIR)/bin/python3 -m pre_commit run --all-files
 
 .PHONY: serve
 serve:

Doc/c-api/import.rst

@@ -98,27 +98,40 @@ Importing Modules
    an exception set on failure (the module still exists in this case).
 
 
-.. c:function:: PyObject* PyImport_AddModuleObject(PyObject *name)
+.. c:function:: PyObject* PyImport_AddModuleRef(const char *name)
+
+   Return the module object corresponding to a module name.
+
+   The *name* argument may be of the form ``package.module``. First check the
+   modules dictionary if there's one there, and if not, create a new one and
+   insert it in the modules dictionary.
+
+   Return a :term:`strong reference` to the module on success. Return ``NULL``
+   with an exception set on failure.
 
-   Return the module object corresponding to a module name.  The *name* argument
-   may be of the form ``package.module``. First check the modules dictionary if
-   there's one there, and if not, create a new one and insert it in the modules
-   dictionary. Return ``NULL`` with an exception set on failure.
+   The module name *name* is decoded from UTF-8.
 
-   .. note::
+   This function does not load or import the module; if the module wasn't
+   already loaded, you will get an empty module object. Use
+   :c:func:`PyImport_ImportModule` or one of its variants to import a module.
+   Package structures implied by a dotted name for *name* are not created if
+   not already present.
+
+   .. versionadded:: 3.13
+
+
+.. c:function:: PyObject* PyImport_AddModuleObject(PyObject *name)
 
-      This function does not load or import the module; if the module wasn't already
-      loaded, you will get an empty module object. Use :c:func:`PyImport_ImportModule`
-      or one of its variants to import a module.  Package structures implied by a
-      dotted name for *name* are not created if not already present.
+   Similar to :c:func:`PyImport_AddModuleRef`, but return a :term:`borrowed
+   reference` and *name* is a Python :class:`str` object.
 
    .. versionadded:: 3.3
 
 
 .. c:function:: PyObject* PyImport_AddModule(const char *name)
 
-   Similar to :c:func:`PyImport_AddModuleObject`, but the name is a UTF-8
-   encoded string instead of a Unicode object.
+   Similar to :c:func:`PyImport_AddModuleRef`, but return a :term:`borrowed
+   reference`.
 
 
 .. c:function:: PyObject* PyImport_ExecCodeModule(const char *name, PyObject *co)

Doc/constraints.txt

@@ -23,7 +23,3 @@ sphinxcontrib-serializinghtml<1.2
 
 # Direct dependencies of Jinja2 (Jinja is a dependency of Sphinx, see above)
 MarkupSafe<2.2
-
-# Direct dependencies of sphinx-lint
-polib<1.3
-regex<2024

Doc/data/refcounts.dat

@@ -974,6 +974,9 @@ PyCoro_New:PyFrameObject*:frame:0:
 PyCoro_New:PyObject*:name:0:
 PyCoro_New:PyObject*:qualname:0:
 
+PyImport_AddModuleRef:PyObject*::+1:
+PyImport_AddModuleRef:const char*:name::
+
 PyImport_AddModule:PyObject*::0:reference borrowed from sys.modules
 PyImport_AddModule:const char*:name::
 

Doc/faq/general.rst

@@ -135,7 +135,7 @@ Python versions are numbered "A.B.C" or "A.B":
 
 See :pep:`6` for more information about bugfix releases.
 
-Not all releases are bugfix releases.  In the run-up to a new minor release, a
+Not all releases are bugfix releases.  In the run-up to a new feature release, a
 series of development releases are made, denoted as alpha, beta, or release
 candidate.  Alphas are early releases in which interfaces aren't yet finalized;
 it's not unexpected to see an interface change between two alpha releases.
@@ -297,9 +297,9 @@ How stable is Python?
 
 Very stable.  New, stable releases have been coming out roughly every 6 to 18
 months since 1991, and this seems likely to continue.  As of version 3.9,
-Python will have a minor new release every 12 months (:pep:`602`).
+Python will have a new feature release every 12 months (:pep:`602`).
 
-The developers issue "bugfix" releases of older versions, so the stability of
+The developers issue bugfix releases of older versions, so the stability of
 existing releases gradually improves.  Bugfix releases, indicated by a third
 component of the version number (e.g. 3.5.3, 3.6.2), are managed for stability;
 only fixes for known problems are included in a bugfix release, and it's

Doc/library/sqlite3.rst

@@ -29,7 +29,7 @@ PostgreSQL or Oracle.
 
 The :mod:`!sqlite3` module was written by Gerhard Häring.  It provides an SQL interface
 compliant with the DB-API 2.0 specification described by :pep:`249`, and
-requires SQLite 3.7.15 or newer.
+requires SQLite 3.15.2 or newer.
 
 This document includes four main sections:
 
@@ -734,9 +734,6 @@ Connection objects
           `deterministic <https://sqlite.org/deterministic.html>`_,
           which allows SQLite to perform additional optimizations.
 
-      :raises NotSupportedError:
-          If *deterministic* is used with SQLite versions older than 3.8.3.
-
       .. versionadded:: 3.8
          The *deterministic* parameter.
 

Doc/library/typing.rst

@@ -23,10 +23,9 @@
 
 --------------
 
-This module provides runtime support for type hints. The most fundamental
-support consists of the types :data:`Any`, :data:`Union`, :data:`Callable`,
-:class:`TypeVar`, and :class:`Generic`. For a specification, please see
-:pep:`484`. For a simplified introduction to type hints, see :pep:`483`.
+This module provides runtime support for type hints. For the original
+specification of the typing system, see :pep:`484`. For a simplified
+introduction to type hints, see :pep:`483`.
 
 
 The function below takes and returns a string and is annotated as follows::
@@ -47,16 +46,18 @@ For a summary of deprecated features and a deprecation timeline, please see
 
 .. seealso::
 
-   For a quick overview of type hints, refer to
-   `this cheat sheet <https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html>`_.
+   `"Typing cheat sheet" <https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html>`_
+       A quick overview of type hints (hosted at the mypy docs)
 
-   The "Type System Reference" section of https://mypy.readthedocs.io/ -- since
-   the Python typing system is standardised via PEPs, this reference should
-   broadly apply to most Python type checkers, although some parts may still be
-   specific to mypy.
+   "Type System Reference" section of `the mypy docs <https://mypy.readthedocs.io/en/stable/index.html>`_
+      The Python typing system is standardised via PEPs, so this reference
+      should broadly apply to most Python type checkers. (Some parts may still
+      be specific to mypy.)
 
-   The documentation at https://typing.readthedocs.io/ serves as useful reference
-   for type system features, useful typing related tools and typing best practices.
+   `"Static Typing with Python" <https://typing.readthedocs.io/en/latest/>`_
+      Type-checker-agnostic documentation written by the community detailing
+      type system features, useful typing related tools and typing best
+      practices.
 
 .. _relevant-peps:
 
@@ -654,33 +655,16 @@ can define new custom protocols to fully enjoy structural subtyping
 Module contents
 ===============
 
-The module defines the following classes, functions and decorators.
-
-.. note::
-
-   This module defines several deprecated aliases to pre-existing
-   standard library classes. These were originally included in the typing
-   module in order to support parameterizing these generic classes using ``[]``.
-   However, the aliases became redundant in Python 3.9 when the
-   corresponding pre-existing classes were enhanced to support ``[]``.
-
-   The redundant types are deprecated as of Python 3.9 but no
-   deprecation warnings are issued by the interpreter.
-   It is expected that type checkers will flag the deprecated types
-   when the checked program targets Python 3.9 or newer.
-
-   The deprecated types will be removed from the :mod:`typing` module
-   no sooner than the first Python version released 5 years after the release of Python 3.9.0.
-   See details in :pep:`585`—*Type Hinting Generics In Standard Collections*.
-
+The ``typing`` module defines the following classes, functions and decorators.
 
 Special typing primitives
 -------------------------
 
 Special types
 """""""""""""
 
-These can be used as types in annotations and do not support ``[]``.
+These can be used as types in annotations. They do not support subscription
+using ``[]``.
 
 .. data:: Any
 
@@ -890,7 +874,8 @@ These can be used as types in annotations and do not support ``[]``.
 Special forms
 """""""""""""
 
-These can be used as types in annotations using ``[]``, each having a unique syntax.
+These can be used as types in annotations. They all support subscription using
+``[]``, but each has a unique syntax.
 
 .. data:: Tuple
 
@@ -1471,7 +1456,8 @@ These can be used as types in annotations using ``[]``, each having a unique syn
 Building generic types and type aliases
 """""""""""""""""""""""""""""""""""""""
 
-The following objects are not used directly in annotations. Instead, they are building blocks
+The following classes should not be used directly as annotations.
+Their intended purpose is to be building blocks
 for creating generic types and type aliases.
 
 These objects can be created through special syntax
@@ -1962,7 +1948,9 @@ without the dedicated syntax, as documented below.
 Other special directives
 """"""""""""""""""""""""
 
-These are not used in annotations. They are building blocks for declaring types.
+These functions and classes should not be used directly as annotations.
+Their intended purpose is to be building blocks for creating and declaring
+types.
 
 .. class:: NamedTuple
 
@@ -2399,7 +2387,8 @@ These are not used in annotations. They are building blocks for declaring types.
 Protocols
 ---------
 
-These protocols are decorated with :func:`runtime_checkable`.
+The following protocols are provided by the typing module. All are decorated
+with :func:`@runtime_checkable <runtime_checkable>`.
 
 .. class:: SupportsAbs
 
@@ -3069,6 +3058,21 @@ Constant
 Deprecated aliases
 ------------------
 
+This module defines several deprecated aliases to pre-existing
+standard library classes. These were originally included in the typing
+module in order to support parameterizing these generic classes using ``[]``.
+However, the aliases became redundant in Python 3.9 when the
+corresponding pre-existing classes were enhanced to support ``[]``.
+
+The redundant types are deprecated as of Python 3.9 but no
+deprecation warnings are issued by the interpreter.
+It is expected that type checkers will flag the deprecated types
+when the checked program targets Python 3.9 or newer.
+
+The deprecated types will be removed from the :mod:`typing` module
+no sooner than the first Python version released 5 years after the release of Python 3.9.0.
+See details in :pep:`585`—*Type Hinting Generics In Standard Collections*.
+
 .. _corresponding-to-built-in-types:
 
 Aliases to built-in types

Doc/requirements.txt

@@ -11,7 +11,6 @@ sphinx==6.2.0
 
 blurb
 
-sphinx-lint==0.6.7
 sphinxext-opengraph==0.7.5
 
 # The theme used by the documentation is stored separately, so we need

Doc/whatsnew/3.12.rst

@@ -1369,7 +1369,38 @@ Removed
   * The :mod:`!imp` module has been removed.  (Contributed by Barry Warsaw in
     :gh:`98040`.)
 
-  * Replace ``imp.new_module(name)`` with ``types.ModuleType(name)``.
+  * Replace removed :mod:`!imp` functions with :mod:`importlib` functions:
+
+    =================================  =======================================
+       imp                                importlib
+    =================================  =======================================
+    ``imp.NullImporter``               Insert ``None`` into ``sys.path_importer_cache``
+    ``imp.cache_from_source()``        :func:`importlib.util.cache_from_source`
+    ``imp.find_module()``              :func:`importlib.util.find_spec`
+    ``imp.get_magic()``                :attr:`importlib.util.MAGIC_NUMBER`
+    ``imp.get_suffixes()``             :attr:`importlib.machinery.SOURCE_SUFFIXES`, :attr:`importlib.machinery.EXTENSION_SUFFIXES`, and :attr:`importlib.machinery.BYTECODE_SUFFIXES`
+    ``imp.get_tag()``                  :attr:`sys.implementation.cache_tag <sys.implementation>`
+    ``imp.load_module()``              :func:`importlib.import_module`
+    ``imp.new_module(name)``           ``types.ModuleType(name)``
+    ``imp.reload()``                   :func:`importlib.reload`
+    ``imp.source_from_cache()``        :func:`importlib.util.source_from_cache`
+    =================================  =======================================
+
+  * Removed :mod:`!imp` functions and attributes with no replacements:
+
+    * undocumented functions:
+
+      * ``imp.init_builtin()``
+      * ``imp.load_compiled()``
+      * ``imp.load_dynamic()``
+      * ``imp.load_package()``
+      * ``imp.load_source()``
+
+    * ``imp.lock_held()``, ``imp.acquire_lock()``, ``imp.release_lock()``:
+      the locking scheme has changed in Python 3.3 to per-module locks.
+    * ``imp.find_module()`` constants: ``SEARCH_ERROR``, ``PY_SOURCE``,
+      ``PY_COMPILED``, ``C_EXTENSION``, ``PY_RESOURCE``, ``PKG_DIRECTORY``,
+      ``C_BUILTIN``, ``PY_FROZEN``, ``PY_CODERESOURCE``, ``IMP_HOOK``.
 
 * Removed the ``suspicious`` rule from the documentation Makefile, and
   removed ``Doc/tools/rstlint.py``, both in favor of `sphinx-lint

Doc/whatsnew/3.13.rst

@@ -410,6 +410,9 @@ Build Changes
   :file:`!configure`.
   (Contributed by Christian Heimes in :gh:`89886`.)
 
+* SQLite 3.15.2 or newer is required to build the :mod:`sqlite3` extension module.
+  (Contributed by Erlend Aasland in :gh:`105875`.)
+
 
 C API Changes
 =============
@@ -423,6 +426,11 @@ New Features
   APIs accepting the format codes always use ``Py_ssize_t`` for ``#`` formats.
   (Contributed by Inada Naoki in :gh:`104922`.)
 
+* Add :c:func:`PyImport_AddModuleRef`: similar to
+  :c:func:`PyImport_AddModule`, but return a :term:`strong reference` instead
+  of a :term:`borrowed reference`.
+  (Contributed by Victor Stinner in :gh:`105922`.)
+
 
 Porting to Python 3.13
 ----------------------

Include/import.h

@@ -43,6 +43,11 @@ PyAPI_FUNC(PyObject *) PyImport_AddModuleObject(
 PyAPI_FUNC(PyObject *) PyImport_AddModule(
     const char *name            /* UTF-8 encoded string */
     );
+#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030d0000
+PyAPI_FUNC(PyObject *) PyImport_AddModuleRef(
+    const char *name            /* UTF-8 encoded string */
+    );
+#endif
 PyAPI_FUNC(PyObject *) PyImport_ImportModule(
     const char *name            /* UTF-8 encoded string */
     );