Lint: fixup subsubsection markups

core-developers/committing.rst

@@ -186,7 +186,7 @@ clone.
 .. _committing-active-branches:
 
 Seeing active branches
-''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^
 
 If you use ``git branch``, then you will see a :ref:`list of branches
 <branchstatus>`. The only branch that receives new features is
@@ -198,7 +198,7 @@ originate on ``main`` and then be ported back to older branches.
 .. _branch-merge:
 
 Backporting changes to an older version
-'''''''''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If it is determined that a pull request needs to be backported into one or
 more of the maintenance branches, then a core developer can apply the label
@@ -236,7 +236,7 @@ can apply labels to GitHub pull requests).
 
 
 Reverting a merged pull request
-'''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To revert a merged pull request, press the ``Revert`` button at the
 bottom of the pull request. That will bring up the page to create a

developer-workflow/communication-channels.rst

@@ -138,7 +138,7 @@ Notifications
 -------------
 
 Following categories (category notifications)
-'''''''''''''''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Notifications can be set for individual categories and topics. To change any of these
 defaults, you can either go to your user preferences, or visit the category
@@ -151,7 +151,7 @@ All categories are set by default in Normal mode where you will only be notified
 if someone mentions your @name or replies to you.
 
 Following individual threads (topic notifications)
-''''''''''''''''''''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To follow any individual topics or threads, you can adjust your notifications
 through the notification button 🔔 found on the right of the topic at the end
@@ -160,7 +160,7 @@ Select "Watching" and you will be notified when there is any new updated reply
 from that particular thread.
 
 Customising notifications on user preference
-''''''''''''''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To get a bird's eye view of all your customised notifications, you can
 go to `Preferences of your account <https://discuss.python.org/my/preferences/categories>`_.

developer-workflow/development-cycle.rst

@@ -34,7 +34,7 @@ and *null* for final releases), and ``N`` is the release serial number.
 Some examples of release tags: ``v3.7.0a1``, ``v3.6.3``, ``v2.7.14rc1``.
 
 Branches
-''''''''
+^^^^^^^^
 
 There is a branch for each *feature version*, whether released or not (e.g.
 3.7, 3.8).
@@ -141,7 +141,7 @@ The latest release for each Python version can be found on the `download page
 .. _stages:
 
 Stages
-''''''
+^^^^^^
 
 Based on what stage the :ref:`in-development <indevbranch>` version of Python
 is in, the responsibilities of a core developer change in regards to commits
@@ -214,7 +214,7 @@ changes to the branch.  After the final release is published, the full
 
 
 Repository administration
-'''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The source code is currently hosted on `GitHub
 <https://github.com/python/cpython>`_ in the `Python organization <https://github.com/python/>`_.

developer-workflow/stdlib.rst

@@ -62,7 +62,7 @@ are not taken lightly.
 
 
 Acceptable types of modules
-'''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Typically two types of modules get added to the stdlib. One type is a module
 which implements something that is difficult to get right. A good example of
 this is the :py:mod:`multiprocessing` package. Working out the various OS
@@ -83,7 +83,7 @@ it.
 
 
 Requirements
-''''''''''''
+^^^^^^^^^^^^
 In order for a module to even be considered for inclusion into the stdlib, a
 couple of requirements must be met.
 
@@ -121,7 +121,7 @@ uniform.
 
 
 Proposal process
-''''''''''''''''
+^^^^^^^^^^^^^^^^
 
 If the module you want to propose adding to the stdlib meets the requirements,
 you may propose its inclusion

documentation/markup.rst

@@ -165,14 +165,14 @@ Hyperlinks
 ----------
 
 External links
-''''''''''''''
+^^^^^^^^^^^^^^
 
 Use ```Link text <http://target>`_`` for inline web links.  If the link text
 should be the web address, you don't need special markup at all, the parser
 finds links and mail addresses in ordinary text.
 
 Internal links
-''''''''''''''
+^^^^^^^^^^^^^^
 
 Internal linking is done via a special reST role, see the section on specific
 markup, :ref:`doc-ref-role`.

getting-started/setup-building.rst

@@ -227,7 +227,7 @@ the interpreter you just built.
 
 
 Clang
-'''''
+^^^^^
 
 If you are using clang_ to build CPython, some flags you might want to set to
 quiet some standard warnings which are specifically superfluous to CPython are
@@ -246,7 +246,7 @@ still build properly).
 
 
 Optimization
-''''''''''''
+^^^^^^^^^^^^
 
 If you are trying to improve CPython's performance, you will probably want
 to use an optimized build of CPython. It can take a lot longer to build CPython

internals/parser.rst

@@ -161,12 +161,12 @@ Grammar expressions
 -------------------
 
 ``# comment``
-'''''''''''''
+^^^^^^^^^^^^^
 
 Python-style comments.
 
 ``e1 e2``
-'''''''''
+^^^^^^^^^
 
 Match ``e1``, then match ``e2``.
 
@@ -175,7 +175,7 @@ Match ``e1``, then match ``e2``.
     rule_name: first_rule second_rule
 
 ``e1 | e2``
-'''''''''''
+^^^^^^^^^^^
 
 Match ``e1`` or ``e2``.
 
@@ -190,7 +190,7 @@ first alternative, like so:
         | second_alt
 
 ``( e )``
-'''''''''
+^^^^^^^^^
 
 Match ``e``.
 
@@ -206,7 +206,7 @@ operator together with the repeat operators:
     rule_name: (e1 e2)*
 
 ``[ e ] or e?``
-'''''''''''''''
+^^^^^^^^^^^^^^^
 
 Optionally match ``e``.
 
@@ -222,7 +222,7 @@ optional:
     rule_name: e (',' e)* [',']
 
 ``e*``
-''''''
+^^^^^^
 
 Match zero or more occurrences of ``e``.
 
@@ -231,7 +231,7 @@ Match zero or more occurrences of ``e``.
     rule_name: (e1 e2)*
 
 ``e+``
-''''''
+^^^^^^
 
 Match one or more occurrences of ``e``.
 
@@ -240,7 +240,7 @@ Match one or more occurrences of ``e``.
     rule_name: (e1 e2)+
 
 ``s.e+``
-''''''''
+^^^^^^^^
 
 Match one or more occurrences of ``e``, separated by ``s``. The generated parse
 tree does not include the separator. This is otherwise identical to
@@ -251,14 +251,14 @@ tree does not include the separator. This is otherwise identical to
     rule_name: ','.e+
 
 ``&e``
-''''''
+^^^^^^
 
 .. _peg-positive-lookahead:
 
 Succeed if ``e`` can be parsed, without consuming any input.
 
 ``!e``
-''''''
+^^^^^^
 
 .. _peg-negative-lookahead:
 
@@ -273,7 +273,7 @@ consists of an atom, which is not followed by a ``.`` or a ``(`` or a
     primary: atom !'.' !'(' !'['
 
 ``~``
-''''''
+^^^^^
 
 Commit to the current alternative, even if it fails to parse (this is called
 the "cut").

testing/coverage.rst

@@ -88,7 +88,7 @@ provided by the stdlib then you can :ref:`use test.regrtest
 .. _install_coverage:
 
 Install coverage
-''''''''''''''''
+^^^^^^^^^^^^^^^^
 
 By default, pip will not install into the in-development version of Python you
 just built, and this built version of Python will not see packages installed
@@ -143,7 +143,7 @@ it. For this, you will again need to use the full path to that installation.
 .. _coverage_usage:
 
 Basic usage
-'''''''''''
+^^^^^^^^^^^
 
 The following command will tell you if your copy of coverage works (substitute
 ``COVERAGEDIR`` with the directory where your clone exists, e.g.
@@ -197,7 +197,7 @@ with pages that visibly show what lines of code were or were not executed.
 .. _branch_coverage:
 
 Branch coverage
-'''''''''''''''
+^^^^^^^^^^^^^^^
 
 For the truly daring, you can use another powerful feature of coverage.py:
 branch coverage. Testing every possible branch path through code, while a great