Merge branch 'main' into cleanup-reporting_an_issue

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,39 @@
+name: "Bug report"
+description: Create a report to help us improve the Python devguide
+title: "Bug: <title>"
+labels: ["bug"]
+assignees: []
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        > [!NOTE]
+        > This repo is for the [Python developer's guide](https://devguide.python.org/).
+        > If you are reporting a bug for the Python language or
+        > CPython interpreter, then use the
+        > [CPython issue tracker](https://github.com/python/cpython/issues) instead.
+
+  - type: textarea
+    id: bug_description
+    attributes:
+      label: "Describe the bug"
+      description: A clear and concise description of what the bug is and, optionally, what you expected to happen.
+    validations:
+      required: true
+
+  - type: textarea
+    id: screenshots
+    attributes:
+      label: "Screenshots"
+      description: If applicable, add screenshots to help explain your problem.
+    validations:
+      required: false
+
+  - type: textarea
+    id: additional_context
+    attributes:
+      label: "Additional context"
+      description: Add any other context about the problem here.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,14 @@
+blank_issues_enabled: false
+contact_links:
+  - name: CPython Documentation
+    url: https://docs.python.org/
+    about: Official CPython documentation - please check here before opening an issue.
+  - name: Python Website
+    url: https://python.org/
+    about: For all things Python
+  - name: PyPI Issues / Support
+    url: https://github.com/pypi/support
+    about: For issues with PyPI itself, PyPI accounts, or with packages hosted on PyPI.
+  - name: CPython Issues
+    url: https://github.com/python/cpython/issues
+    about: For issues with the CPython interpreter itself.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,39 @@
+name: "Feature request"
+description: Suggest an idea for the Python devguide
+title: "Feature: <title>"
+labels: ["enhancement"]
+assignees: []
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        > [!NOTE]
+        > This repo is for the [Python developer's guide](https://devguide.python.org/).
+        > If you are requesting an enhancement for the Python language or
+        > CPython interpreter, then use the
+        > [CPython issue tracker](https://github.com/python/cpython/issues) instead.
+
+  - type: textarea
+    id: feature_description
+    attributes:
+      label: "Describe the enhancement or feature you would like"
+      description: A clear and concise description of what you want to happen.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: "Describe alternatives you have considered"
+      description: A clear and concise description of any alternative solutions or features you have considered.
+    validations:
+      required: false
+
+  - type: textarea
+    id: additional_context
+    attributes:
+      label: "Additional context"
+      description: Add any other context or screenshots about the feature request here.
+    validations:
+      required: false

.ruff.toml

@@ -1,4 +1,4 @@
-target-version = "py311"
+target-version = "py310"
 fix = true
 output-format = "full"
 line-length = 88

_tools/generate_release_cycle.py

@@ -45,7 +45,7 @@ def __init__(self) -> None:
 
     def write_csv(self) -> None:
         """Output CSV files."""
-        now_str = str(dt.datetime.now(dt.UTC))
+        now_str = str(dt.datetime.now(dt.timezone.utc))
 
         versions_by_category = {"branches": {}, "end-of-life": {}}
         headers = None

conf.py

@@ -67,6 +67,7 @@
     # Login page
     r"https://github.com/python/buildmaster-config/issues/new.*": r"https://github.com/login.*",  # noqa: E501
     r"https://github.com/python/core-workflow/issues/new.*": r"https://github.com/login.*",  # noqa: E501
+    r"https://github.com/orgs/python/teams.*": r"https://github.com/login.*",  # noqa: E501
     # Archive redirect
     r"https://github.com/python/cpython/archive/main.zip": r"https://codeload.github.com/python/cpython/zip/refs/heads/main",  # noqa: E501
     # Blob to tree
@@ -89,6 +90,13 @@
     r'\/.*',
 ]
 
+# Check the link itself, but ignore anchors that are added by JS
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-linkcheck_anchors_ignore_for_url
+linkcheck_anchors_ignore_for_url = [
+    # GitHub
+    r'https://github.com/.*',
+]
+
 linkcheck_ignore = [
     # The voters repo is private and appears as a 404
     'https://github.com/python/voters',
@@ -98,27 +106,22 @@
     'https://discuss.python.org/groups/staff',
     'https://discuss.python.org/groups/moderators',
     'https://discuss.python.org/groups/admins',
-    # The crawler gets "Anchor not found" for GitHub anchors
-    r'https://github.com.+?#L\d+',
-    r'https://github.com/cli/cli#installation',
-    r'https://github.com/github/renaming#renaming-existing-branches',
-    r'https://github.com/python/bedevere/#pr-state-machine',
     # "Anchor not found":
     r'https://packaging.python.org/.*#',
     # "-rate limited-", causing a timeout
     r'https://stackoverflow.com/.*',
     # Discord doesn't allow robot crawlers: "403 Client Error: Forbidden"
-    'https://support.discord.com/hc/en-us/articles/219070107-Server-Nicknames',
+    r'https://support.discord.com/hc/en-us/articles/219070107-Server-Nicknames',
+    # Patreon also gives 403 to the GHA linkcheck runner
+    r'https://www.patreon.com/.*',
 ]
 
 rediraffe_redirects = {
     # Development Tools
     "clang.rst": "development-tools/clang.rst",
-    "coverity.rst": "development-tools/coverity.rst",
     "gdb.rst": "development-tools/gdb.rst",
     # Advanced Tools was renamed Development Tools in gh-1149
     "advanced-tools/clang.rst": "development-tools/clang.rst",
-    "advanced-tools/coverity.rst": "development-tools/coverity.rst",
     "advanced-tools/gdb.rst": "development-tools/gdb.rst",
     # Core Developers
     "coredev.rst": "core-developers/become-core-developer.rst",

core-developers/developers.csv

@@ -1,3 +1,4 @@
+Matt Page,mpage,2024-10-10,,
 Kirill Podoprigora,Eclips4,2024-09-20,,
 Ned Batchelder,nedbat,2024-07-16,,
 Tian Gao,gaogaotiantian,2024-06-06,,

core-developers/experts.rst

@@ -286,7 +286,7 @@ for “their” platform as a third-party project.
 ===================   ===========
 Platform              Maintainers
 ===================   ===========
-AIX                   edelsohn
+AIX                   edelsohn, ayappanec
 Android               mhsmith
 Cygwin                jlt63^, stutzbach^
 Emscripten            hoodmane, pmp-p, rdb, rth, ryanking13
@@ -319,7 +319,6 @@ buildbots           zware, pablogsal
 bytecode            benjaminp, 1st1, markshannon, brandtbucher, carljm, iritkatriel
 context managers    ncoghlan
 core workflow       Mariatta, ezio-melotti, hugovk, AA-Turner
-coverity scan       tiran, Yhg1s
 cryptography        gpshead, dstufft
 data formats
 database            malemburg

core-developers/motivations.rst

@@ -261,7 +261,7 @@ participating in the CPython core development process:
 
 .. topic:: Carol Willing (United States)
 
-   * Noteable: `<https://noteable.io/about-us/>`__ (VP Engineering)
+   * Noteable (VP Engineering)
    * Personal site: `Willing Consulting <https://www.willingconsulting.com/>`_
    * `Extended bio <https://www.willingconsulting.com/about/>`__
    * Project Jupyter (Software Council, Core Team for JupyterHub/Binder)

developer-workflow/communication-channels.rst

@@ -263,7 +263,7 @@ Other core workflow tools are:
 * `blurb_it`_
 * `miss-islington`_
 * `cla-bot`_
-* `cpython-emailer-webhook`_
+* `webhook-mailer`_
 
 Python `Performance Benchmark`_ project is intended to be an authoritative
 source of benchmarks for all Python implementations.
@@ -274,5 +274,5 @@ source of benchmarks for all Python implementations.
 .. _blurb_it: https://github.com/python/blurb_it
 .. _miss-islington: https://github.com/python/miss-islington
 .. _cla-bot: https://github.com/ambv/cla-bot
-.. _cpython-emailer-webhook: https://github.com/berkerpeksag/cpython-emailer-webhook
+.. _webhook-mailer: https://github.com/python/webhook-mailer
 .. _Performance Benchmark: https://github.com/python/pyperformance

developer-workflow/development-cycle.rst

@@ -37,7 +37,7 @@ Branches
 --------
 
 There is a branch for each *feature version*, whether released or not (for
-example, 3.7, 3.8).
+example, 3.12, 3.13).
 
 
 .. _indevbranch:
@@ -51,13 +51,11 @@ changes, performance improvements, bug fixes.
 
 At some point during the life-cycle of a release, a
 new :ref:`maintenance branch <maintbranch>` is created to host all bug fixing
-activity for further micro versions in a feature version (3.8.1, 3.8.2, etc.).
+activity for further micro versions in a feature version (3.12.1, 3.12.2, and so
+on).
 
-For versions 3.4 and before, this was conventionally done when the final
-release was cut (for example, 3.4.0 final).
-
-Starting with the 3.5 release, we create the release maintenance branch
-(``3.5``) at the time we enter beta (3.5.0 beta 1).  This allows
+We create the release maintenance branch
+(``3.14``) at the time we enter beta (3.14.0 beta 1).  This allows
 feature development for the release 3.n+1 to occur within the main
 branch alongside the beta and release candidate stabilization periods
 for release 3.n.
@@ -79,7 +77,7 @@ releases; the terms are used interchangeably. These releases have a
 The only changes allowed to occur in a maintenance branch without debate are
 bug fixes, test improvements, and edits to the documentation.
 Also, a general rule for maintenance branches is that compatibility
-must not be broken at any point between sibling micro releases (3.5.1, 3.5.2,
+must not be broken at any point between sibling micro releases (3.12.1, 3.12.2,
 etc.).  For both rules, only rare exceptions are accepted and **must** be
 discussed first.
 
@@ -97,9 +95,9 @@ that maintenance branch.
 Sometime following the final release (3.x.0), the maintenance branch for
 the previous minor version will go into :ref:`security mode <secbranch>`,
 usually after at least one more bugfix release at the discretion of the
-release manager.  For example, the 3.4 maintenance branch was put into
-:ref:`security mode <secbranch>` after the 3.4.4 bugfix release
-which followed the release of 3.5.1.
+release manager.  For example, the 3.11 maintenance branch was put into
+:ref:`security mode <secbranch>` after the 3.11.9 bugfix release
+which followed the release of 3.12.2.
 
 .. _secbranch:
 
@@ -131,7 +129,7 @@ End-of-life branches
 The code base for a release cycle which has reached end-of-life status
 is frozen and no longer has a branch in the repo.  The final state of
 the end-of-lifed branch is recorded as a tag with the same name as the
-former branch, for example, ``3.3`` or ``2.6``.
+former branch, for example, ``3.8`` or ``2.7``.
 
 The :ref:`versions` page contains list of active and end-of-life branches.
 
@@ -347,7 +345,7 @@ Current administrators
 | Pablo Galindo     | Python 3.10 and 3.11 Release Manager,                    | pablogsal       |
 |                   | Maintainer of buildbot.python.org                        |                 |
 +-------------------+----------------------------------------------------------+-----------------+
-| Łukasz Langa      | Python 3.8 and 3.9 Release Manager,                      | ambv            |
+| Łukasz Langa      | Python 3.9 Release Manager,                              | ambv            |
 |                   | PSF CPython Developer in Residence 2021-present          |                 |
 +-------------------+----------------------------------------------------------+-----------------+
 | Brett Cannon      |                                                          | brettcannon     |

developer-workflow/extension-modules.rst

@@ -31,7 +31,7 @@ Extension modules can be classified into two categories:
 
 * A *built-in* extension module is a module built and shipped with
   the Python interpreter. A built-in module is *statically* linked
-  into the interpreter, thereby lacking a :attr:`__file__` attribute.
+  into the interpreter, thereby lacking a :attr:`!__file__` attribute.
 
   .. seealso:: :data:`sys.builtin_module_names` --- names of built-in modules.
 
@@ -41,7 +41,7 @@ Extension modules can be classified into two categories:
 * A *shared* (or *dynamic*) extension module is built as a shared library
   (``.so`` or ``.dll`` file) and is *dynamically* linked into the interpreter.
 
-  In particular, the module's :attr:`__file__` attribute contains the path
+  In particular, the module's :attr:`!__file__` attribute contains the path
   to the ``.so`` or ``.dll`` file.
 
   Shared modules are built with the :c:macro:`!Py_BUILD_CORE_MODULE`
@@ -75,7 +75,7 @@ with the following :func:`!foo.greet` function:
 
 Instead of using the Python implementation of :func:`!foo.greet`, we want to
 use its corresponding C extension implementation exposed in the :mod:`!_foo`
-module. Ideally, we want to modify :cpy-file:`!Lib/foo.py` as follows:
+module. Ideally, we want to modify ``Lib/foo.py`` as follows:
 
 .. code-block:: python
    :caption: Lib/foo.py

developer-workflow/lang-changes.rst

@@ -45,7 +45,7 @@ The `Ideas Discourse category`_
 is specifically intended for discussion of new features and language changes.
 Please don't be disappointed if your idea isn't met with universal approval:
 as the :pep:`long list of Withdrawn and Rejected PEPs
-<0#abandoned-withdrawn-and-rejected-peps>`
+<0#rejected-superseded-and-withdrawn-peps>`
 in the :pep:`PEP Index <0>` attests,
 and as befits a reasonably mature programming language,
 getting significant changes into Python isn't a simple task.

development-tools/clang.rst

@@ -54,7 +54,7 @@ A complete list of sanitizers can be found at `Controlling Code Generation
 
 Clang and its sanitizers have strengths (and weaknesses). Its just one tool in
 the war chest to uncovering bugs and improving code quality. Clang should be
-used to complement other methods, including Code Reviews, Valgrind, Coverity,
+used to complement other methods, including Code Reviews, `Valgrind`_,
 etc.
 
 Clang/LLVM setup
@@ -281,3 +281,5 @@ Unfortunately, you won't know what to ignorelist until you run the sanitizer.
 
 The documentation is available at `Sanitizer special case list
 <https://clang.llvm.org/docs/SanitizerSpecialCaseList.html>`_.
+
+.. _Valgrind: https://github.com/python/cpython/blob/main/Misc/README.valgrind