Remove extra whitespace in the documentation files (python#832)

appendix.rst

@@ -1,4 +1,4 @@
-Appendix: Topics 
+Appendix: Topics
 ================
 
 Basics for contributors
@@ -67,4 +67,4 @@ Testing and continuous integration
 * :doc:`buildbots`
 * :doc:`buildworker`
 * :doc:`coverity`
-  
+

c-api.rst

@@ -74,7 +74,7 @@ see below).
 
 Guidelines for expanding/changing the public API:
 
-- Make sure the new API follows reference counting conventions. 
+- Make sure the new API follows reference counting conventions.
   (Following them makes the API easier to reason about, and easier use
   in other Python implementations.)
 
@@ -170,7 +170,7 @@ Guidelines for adding to the Limited API
 
 - Think about ease of use for the user.
 
-  - In C, ease of use itself is not very important; what is useful is 
+  - In C, ease of use itself is not very important; what is useful is
     reducing boilerplate code needed to use the API. Bugs like to hide in
     boiler plates.
 

committing.rst

@@ -15,36 +15,36 @@ Before you can accept a pull request, you need to make sure that it is ready
 to enter the public source tree. Ask yourself the following questions:
 
 * **Are there ongoing discussions at** ``bugs.python.org`` **(b.p.o.)?**
-   Read the linked b.p.o. issue. If there are ongoing discussions, then 
+   Read the linked b.p.o. issue. If there are ongoing discussions, then
    we need to have a resolution there before we can merge the pull request.
 
-* **Was the pull request first made against the appropriate branch?** 
+* **Was the pull request first made against the appropriate branch?**
    The only branch that receives new features is ``main``, the
    in-development branch. Pull requests should only target bug-fix branches
    if an issue appears in only that version and possibly older versions.
 
-* **Are the changes acceptable?** 
-   If you want to share your work-in-progress code on a feature or bugfix, 
-   then you can open a ``WIP``-prefixed pull request, publish patches on 
+* **Are the changes acceptable?**
+   If you want to share your work-in-progress code on a feature or bugfix,
+   then you can open a ``WIP``-prefixed pull request, publish patches on
    the `issue tracker`_, or create a public fork of the repository.
 
-* **Do the checks on the pull request show that the test suite passes?** 
+* **Do the checks on the pull request show that the test suite passes?**
    Make sure that all of the status checks are passing.
 
-* **Is the patch in a good state?** 
-   Check :ref:`patch` and :ref:`helptriage` to review what is expected of 
+* **Is the patch in a good state?**
+   Check :ref:`patch` and :ref:`helptriage` to review what is expected of
    a patch.
 
-* **Does the patch break backwards-compatibility without a strong reason?** 
-   :ref:`Run the entire test suite <runtests>` to make sure that everything 
-   still passes. If there is a change to the semantics, then there needs to 
-   be a strong reason, because it will cause some peoples' code to break. 
+* **Does the patch break backwards-compatibility without a strong reason?**
+   :ref:`Run the entire test suite <runtests>` to make sure that everything
+   still passes. If there is a change to the semantics, then there needs to
+   be a strong reason, because it will cause some peoples' code to break.
    If you are unsure if the breakage is worth it, then ask on python-dev.
-   
+
 * **Does documentation need to be updated?**
-   If the pull request introduces backwards-incompatible changes (e.g. 
-   deprecating or removing a feature), then make sure that those changes 
-   are reflected in the documentation before you merge the pull request.   
+   If the pull request introduces backwards-incompatible changes (e.g.
+   deprecating or removing a feature), then make sure that those changes
+   are reflected in the documentation before you merge the pull request.
 
 * **Were appropriate labels added to signify necessary backporting of the pull request?**
    If it is determined that a pull request needs to be
@@ -55,21 +55,21 @@ to enter the public source tree. Ask yourself the following questions:
    core developers and members of the `Python Triage Team`_ can apply
    labels to GitHub pull requests).
 
-* **Does the pull request pass a check indicating that the submitter has signed the CLA?** 
+* **Does the pull request pass a check indicating that the submitter has signed the CLA?**
    Make sure that the contributor has signed a `Contributor
-   Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`_ 
-   (CLA), unless their change has no possible intellectual property 
-   associated with it (e.g. fixing a spelling mistake in documentation). 
+   Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`_
+   (CLA), unless their change has no possible intellectual property
+   associated with it (e.g. fixing a spelling mistake in documentation).
    To check if a contributor’s CLA has been received, go
    to `Check Python CLA <https://check-python-cla.herokuapp.com/>`_ and
    put in their GitHub username. For further questions about the CLA
    process, write to [email protected].
 
-* **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?** 
-   If the change is particularly interesting for end users (e.g. new features, 
-   significant improvements, or backwards-incompatible changes), then an 
-   entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should 
-   be added as well. Changes that affect only documentation generally do not 
+* **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?**
+   If the change is particularly interesting for end users (e.g. new features,
+   significant improvements, or backwards-incompatible changes), then an
+   entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should
+   be added as well. Changes that affect only documentation generally do not
    require a ``NEWS`` entry. (See the following section for more information.)
 
 
@@ -161,7 +161,7 @@ Python repositories, so you need to be careful with your workflow:
   for maintenance work before it is integrated into the main repository.
 
 * **You should not commit directly into the** ``main`` **branch, or any of the maintenance branches.**
-  You should commit against your own feature branch, and then create a 
+  You should commit against your own feature branch, and then create a
   pull request.
 
 * **For a small change, you can make a quick edit through the GitHub web UI.**

compiler.rst

@@ -473,9 +473,9 @@ Changing this number will lead to all .pyc files with the old ``MAGIC_NUMBER``
 to be recompiled by the interpreter on import.  Whenever ``MAGIC_NUMBER`` is
 changed, the ranges in the ``magic_values`` array in :file:`PC/launcher.c`
 must also be updated.  Changes to :file:`Lib/importlib/_bootstrap_external.py`
-will take effect only after running ``make regen-importlib``. Running this 
-command before adding the new bytecode target to :file:`Python/ceval.c` will 
-result in an error. You should only run ``make regen-importlib`` after the new 
+will take effect only after running ``make regen-importlib``. Running this
+command before adding the new bytecode target to :file:`Python/ceval.c` will
+result in an error. You should only run ``make regen-importlib`` after the new
 bytecode target has been added.
 
 .. note:: On Windows, running the ``./build.bat`` script will automatically

coverage.rst

@@ -207,8 +207,8 @@ C extension is installed. You can check this with::
   ./python COVERAGEDIR --version
 
 If it says 'without C extension', then you will need to build the C extension.
-Assuming that coverage.py's clone is at ``COVERAGEDIR`` and your clone of CPython 
-is at ``CPYTHONDIR``, you can do this by executing the following in your coverage.py 
+Assuming that coverage.py's clone is at ``COVERAGEDIR`` and your clone of CPython
+is at ``CPYTHONDIR``, you can do this by executing the following in your coverage.py
 clone::
 
   CPPFLAGS="-I CPYTHONDIR -I CPYTHONDIR/Include" CPYTHONDIR/python setup.py build_ext --inplace

documenting.rst

@@ -1781,7 +1781,7 @@ How is a coordinator elected?
 There is no election; each translation has to sort this out.  Here are some suggestions.
 
 -  Coordinator requests are to be public on the `translation mailing list <translation_ml_>`_.
--  If the given language has a native core dev, the core dev has their 
+-  If the given language has a native core dev, the core dev has their
    say on the choice.
 -  Anyone who wants to become coordinator for their native language and shows
    motivation by translating and building a community will be named
@@ -1803,7 +1803,7 @@ Ask on the `translation mailing list <translation_ml_>`_, or better, make a PR o
 I have a translation, but it's not in git. What should I do?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-You can ask for help on the `translation mailing list <translation_ml_>`_, and 
+You can ask for help on the `translation mailing list <translation_ml_>`_, and
 the team will help you create an appropriate repository. You can still use tools like transifex,
 if you like.
 

garbage_collector.rst

@@ -65,7 +65,7 @@ Normally the C structure supporting a regular Python object looks as follows:
                   |                    *ob_type                   | |
                   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
                   |                      ...                      |
-                  
+
 
 In order to support the garbage collector, the memory layout of objects is altered
 to accommodate extra information **before** the normal layout:
@@ -82,7 +82,7 @@ to accommodate extra information **before** the normal layout:
                   |                    *ob_type                   | |
                   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
                   |                      ...                      |
-                  
+
 
 In this way the object can be treated as a normal python object and when the extra
 information associated to the GC is needed the previous fields can be accessed by a
@@ -179,7 +179,7 @@ Every object that supports garbage collection will have an extra reference
 count field initialized to the reference count (``gc_ref`` in the figures)
 of that object when the algorithm starts. This is because the algorithm needs
 to modify the reference count to do the computations and in this way the
-interpreter will not modify the real reference count field. 
+interpreter will not modify the real reference count field.
 
 .. figure:: images/python-cyclic-gc-1-new-page.png
 
@@ -219,10 +219,10 @@ they started originally) and setting its ``gc_refs`` field to 1. This is what ha
 to ``link_2`` and ``link_3`` below as they are reachable from ``link_1``.  From the
 state in the previous image and after examining the objects referred to by ``link_1``
 the GC knows that ``link_3`` is reachable after all, so it is moved back to the
-original list and its ``gc_refs`` field is set to 1 so that if the GC visits it again, 
+original list and its ``gc_refs`` field is set to 1 so that if the GC visits it again,
 it will know that it's reachable. To avoid visiting an object twice, the GC marks all
-objects that have already been visited once (by unsetting the ``PREV_MASK_COLLECTING`` 
-flag) so that if an object that has already been processed is referenced by some other 
+objects that have already been visited once (by unsetting the ``PREV_MASK_COLLECTING``
+flag) so that if an object that has already been processed is referenced by some other
 object, the GC does not process it twice.
 
 .. figure:: images/python-cyclic-gc-5-new-page.png
@@ -337,7 +337,7 @@ specifically in a generation by calling ``gc.collect(generation=NUM)``.
     >>> import gc
     >>> class MyObj:
     ...     pass
-    ... 
+    ...
 
     # Move everything to the last generation so it's easier to inspect
     # the younger generations.
@@ -462,7 +462,7 @@ benefit from delayed tracking:
   when created. During garbage collection it is determined whether any surviving
   tuples can be untracked. A tuple can be untracked if all of its contents are
   already not tracked. Tuples are examined for untracking in all garbage collection
-  cycles. It may take more than one cycle to untrack a tuple. 
+  cycles. It may take more than one cycle to untrack a tuple.
 
 * Dictionaries containing only immutable objects also do not need to be tracked.
   Dictionaries are untracked when created. If a tracked item is inserted into a
@@ -472,7 +472,7 @@ benefit from delayed tracking:
 
 The garbage collector module provides the Python function ``is_tracked(obj)``, which returns
 the current tracking status of the object. Subsequent garbage collections may change the
-tracking status of the object. 
+tracking status of the object.
 
 .. code-block:: python
 

parser.rst

@@ -69,7 +69,7 @@ loads the entire program in memory before parsing it but also allows the parser
 to backtrack arbitrarily. This is made efficient by memoizing the rules already
 matched for each position. The cost of the memoization cache is that the parser
 will naturally use more memory than a simple LL(1) parser, which normally are
-table-based. 
+table-based.
 
 
 Key ideas
@@ -329,7 +329,7 @@ different set of actions, keeping everything else apart from said actions
 identical in both files. As an example of a grammar with Python actions, the
 piece of the parser generator that parses grammar files is bootstrapped from a
 meta-grammar file with Python actions that generate the grammar tree as a result
-of the parsing. 
+of the parsing.
 
 In the specific case of the PEG grammar for Python, having actions allows
 directly describing how the AST is composed in the grammar itself, making it
@@ -525,7 +525,7 @@ parser. It contains the following pieces:
 * A PEG meta-grammar that automatically generates a Python parser that is used for the parser generator itself
   (this means that there are no manually-written parsers). The meta-grammar is
   located at :file:`Tools/peg_generator/pegen/metagrammar.gram`.
-* A generated parser (using the parser generator) that can directly produce C and Python AST objects. 
+* A generated parser (using the parser generator) that can directly produce C and Python AST objects.
 
 The source code for Pegen lives at :file:`Tools/peg_generator/pegen` but normally all typical commands to interact
 with the parser generator are executed from the main makefile.
@@ -606,7 +606,7 @@ and the parser just receives tokens from it.
 Memoization
 ~~~~~~~~~~~
 
-As described previously, to avoid exponential time complexity in the parser, memoization is used. 
+As described previously, to avoid exponential time complexity in the parser, memoization is used.
 
 The C parser used by Python is highly optimized and memoization can be expensive both in memory and time. Although
 the memory cost is obvious (the parser needs memory for storing previous results in the cache) the execution time
@@ -785,13 +785,13 @@ displayed when the error is reported.
     a syntax error **after** valid code triggers the rule or not. For example: ::
 
         <valid python code> $ 42
-    
+
     Should trigger the syntax error in the ``$`` character. If your rule is not correctly defined this
     won't happen. For example, if you try to define a rule to match Python 2 style ``print`` statements
     to make a better error message and you define it as: ::
 
         invalid_print: "print" expression
-    
+
     This will **seem** to work because the parser will correctly parse ``print(something)`` because it is valid
     code and the second phase will never execute but if you try to parse ``print(something) $ 3`` the first pass
     of the parser will fail (because of the ``$``) and in the second phase, the rule will match the
@@ -818,7 +818,7 @@ from them or to do extra processing on the generated tree.
     AST to decide if is valid or not but this will render the `official grammar
     <https://docs.python.org/3/reference/grammar.html>`_ partially incorrect
     (because actions are not included) and will make it more difficult for other
-    Python implementations to adapt the grammar to their own needs. 
+    Python implementations to adapt the grammar to their own needs.
 
 As a general rule, if an action spawns multiple lines or requires something more
 complicated than a single expression of C code, is normally better to create a
@@ -875,7 +875,7 @@ Verbose mode
 When Python is compiled in debug mode (by adding ``--with-pydebug`` when running the configure step in Linux or by
 adding ``-d`` when calling the :file:`PCbuild/python.bat` script in Windows), it is possible to activate a **very** verbose
 mode in the generated parser. This is very useful to debug the generated parser and to understand how it works, but it
-can be a bit hard to understand at first. 
+can be a bit hard to understand at first.
 
 .. note::
 

pullrequest.rst

@@ -453,7 +453,7 @@ Leaving a Pull Request Review on GitHub
 ---------------------------------------
 
 When you review a pull request, you should provide additional details and context
-of your review process. 
+of your review process.
 
 Instead of simply "approving" the pull request, leave comments.  For example:
 

runtests.rst

@@ -50,14 +50,14 @@ path to the test case::
 
    ./python -m unittest -v test.test_abc.TestABC_Py
 
-Some test modules also support direct invocation, 
+Some test modules also support direct invocation,
 which might be useful for IDEs and local debugging::
 
    ./python Lib/test/test_typing.py
 
 But, there are several important notes:
 
-1. This way of running tests exists only 
+1. This way of running tests exists only
    for local developer needs and is discouraged for anything else
 2. Some modules do not support it at all. One example is``test_importlib``.
    In other words: if some module does not have ``unittest.main()``, then

tracker.rst

@@ -36,7 +36,7 @@ already been reported.  Checking if the problem is an existing issue will:
   the next release
 * save time for you and the developers
 * help you learn what needs to be done to fix it
-* determine if additional information, such as how to replicate the issue, 
+* determine if additional information, such as how to replicate the issue,
   is needed
 
 To see if an issue already exists, search the bug database using the search box
@@ -100,7 +100,7 @@ As humans, we will have differences of opinions from time to time. First and
 foremost, please be respectful that care, thought, and volunteer time went into
 the resolution.
 
-With this in mind, take some time to consider any comments made in association 
+With this in mind, take some time to consider any comments made in association
 with the resolution of the issue. On reflection, the resolution steps may seem
 more reasonable than you initially thought.
 
@@ -139,8 +139,8 @@ For bugs, an issue needs to:
 These are things you can help with once you have experience developing for
 Python:
 
-* try reproducing the bug: For instance, if a bug is not clearly explained 
-  enough for you to reproduce it then there is a good chance a core developer 
+* try reproducing the bug: For instance, if a bug is not clearly explained
+  enough for you to reproduce it then there is a good chance a core developer
   won't be able to either.
 * see if the issue happens on a different Python version: It is always helpful
   to know if a bug not only affects the in-development version of Python, but