Lint: Normalise whitespace

.github/PULL_REQUEST_TEMPLATE/Mark a PEP Final.md

@@ -9,6 +9,6 @@ If you're unsure about something, just leave it blank and we'll take a look.
 * [ ] Any substantial changes since the accepted version approved by the SC/PEP delegate
 * [ ] Pull request title in appropriate format (``PEP 123: Mark Final``)
 * [ ] ``Status`` changed to ``Final`` (and ``Python-Version`` is correct)
-* [ ] Canonical docs/spec linked with a ``canonical-doc`` directive 
+* [ ] Canonical docs/spec linked with a ``canonical-doc`` directive
       (or ``canonical-pypa-spec`` for packaging PEPs,
        or ``canonical-typing-spec`` for typing PEPs)

.pre-commit-config.yaml

@@ -17,6 +17,12 @@ repos:
       - id: mixed-line-ending
         name: "Normalize mixed line endings"
         args: [--fix=lf]
+      - id: end-of-file-fixer
+        name: "Ensure files end with a single newline"
+      - id: trailing-whitespace
+        name: "Remove trailing whitespace"
+        args: ["--chars", " \t"]
+
       - id: file-contents-sorter
         name: "Sort codespell ignore list"
         files: '.codespell/ignore-words.txt'

pep_sphinx_extensions/tests/peps/pep-9000.rst

@@ -1,6 +1,6 @@
 PEP: 9000
 Title: Test with authors with email addresses
-Author: Francis Fussyreverend <[email protected]>, 
+Author: Francis Fussyreverend <[email protected]>,
         Javier Soulfulcommodore <[email protected]>
 Created: 20-Apr-2022
 Status: Draft

peps/pep-0008.rst

@@ -820,7 +820,7 @@ complete sentences, with each sentence ending in a period.
 You should use one or two spaces after a sentence-ending period in
 multi-sentence comments, except after the final sentence.
 
-Ensure that your comments are clear and easily understandable to other 
+Ensure that your comments are clear and easily understandable to other
 speakers of the language you are writing in.
 
 Python coders from non-English speaking countries: please write your

peps/pep-0230.rst

@@ -407,4 +407,3 @@ Implementation
 
 Here's a prototype implementation:
 http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470
-

peps/pep-0247.rst

@@ -170,4 +170,3 @@ This document has been placed in the public domain.
   mode: indented-text
   indent-tabs-mode: nil
   End:
-

peps/pep-0265.rst

@@ -204,4 +204,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-

peps/pep-0272.rst

@@ -241,4 +241,3 @@ This document has been placed in the public domain.
   mode: indented-text
   indent-tabs-mode: nil
   End:
-

peps/pep-0282.rst

@@ -74,7 +74,7 @@ used to generate simple logging output on stderr.
             raise TypeError, "Bogus type error for testing"
     -----------------------------------------------------
 
-.. code-block:: python 
+.. code-block:: python
 
     --------- myapp.py ----------------------------------
     import mymodule, logging
@@ -91,7 +91,7 @@ used to generate simple logging output on stderr.
     log.info("Ending my app")
     -----------------------------------------------------
 
-.. code-block:: console 
+.. code-block:: console
 
     $ python myapp.py
 
@@ -111,7 +111,7 @@ The above example shows the default output format.  All
 aspects of the output format should be configurable, so that
 you could have output formatted like this:
 
-.. code-block:: text 
+.. code-block:: text
 
     2002-04-19 07:56:58,174 MyModule   DEBUG - Doin' stuff...
 

peps/pep-0342.rst

@@ -605,4 +605,3 @@ This document has been placed in the public domain.
    fill-column: 70
    coding: utf-8
    End:
-

peps/pep-0374.rst

@@ -1515,4 +1515,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-

peps/pep-0400.rst

@@ -331,4 +331,3 @@ Footnotes
 
 .. [#f1] StreamReaderWriter has two more attributes than
          TextIOWrapper, reader and writer.
-

peps/pep-0404.rst

@@ -180,4 +180,3 @@ This document has been placed in the public domain.
 .. _`2to3`: http://docs.python.org/library/2to3.html
 .. _differences: http://docs.python.org/release/3.0.1/whatsnew/3.0.html
 .. _porting: http://python3porting.com/
-

peps/pep-0405.rst

@@ -533,4 +533,3 @@ This document has been placed in the public domain.
    fill-column: 70
    coding: utf-8
    End:
-

peps/pep-0409.rst

@@ -204,4 +204,3 @@ This document has been placed in the public domain.
    fill-column: 70
    coding: utf-8
    End:
-

peps/pep-0410.rst

@@ -544,4 +544,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-

peps/pep-0416.rst

@@ -251,4 +251,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-

peps/pep-0418/bench_time.c

@@ -185,4 +185,3 @@ int main()
     benchmark("time()", bench_time, 0);
     return 0;
 }
-

peps/pep-0418/clock_resolution.py

@@ -69,4 +69,3 @@ def gettime():
     test_clock(name, gettime)
     resolution = time.clock_getres(clock_id)
     print("- announced resolution: %s" % format_duration(resolution))
-

peps/pep-0426/pepsort.py

@@ -267,4 +267,3 @@ def main(pepno = '426'):
                         filemode='w', format='%(message)s')
     logger.setLevel(logging.DEBUG)
     main(pepno)
-

peps/pep-0445.rst

@@ -770,4 +770,3 @@ Copyright
 =========
 
 This document has been placed into the public domain.
-

peps/pep-0446.rst

@@ -618,5 +618,3 @@ Copyright
 =========
 
 This document has been placed into the public domain.
-
-

peps/pep-0446/test_cloexec.py

@@ -47,4 +47,3 @@ def after_exec():
         main()
     else:
         after_exec()
-

peps/pep-0451.rst

@@ -957,4 +957,3 @@ This document has been placed in the public domain.
    fill-column: 70
    coding: utf-8
    End:
-

peps/pep-0468.rst

@@ -438,4 +438,3 @@ This document has been placed in the public domain.
    fill-column: 70
    coding: utf-8
    End:
-

peps/pep-0484.rst

@@ -128,7 +128,7 @@ have a return annotation; the default behavior is thus the same as for
 other methods.)
 
 A type checker is expected to check the body of a checked function for
-consistency with the given annotations.  The annotations may also be 
+consistency with the given annotations.  The annotations may also be
 used to check correctness of calls appearing in other checked functions.
 
 Type checkers are expected to attempt to infer as much information as

peps/pep-0517.rst

@@ -375,7 +375,7 @@ configuration into individual package builds. Build backends MAY
 assign any semantics they like to this dictionary. Build frontends
 SHOULD provide some mechanism for users to specify arbitrary
 string-key/string-value pairs to be placed in this dictionary.
-For example, they might support some syntax like ``--package-config CC=gcc``. 
+For example, they might support some syntax like ``--package-config CC=gcc``.
 In case a user provides duplicate string-keys, build frontends SHOULD
 combine the corresponding string-values into a list of strings.
 Build frontends MAY also provide arbitrary other mechanisms

peps/pep-0524.rst

@@ -561,4 +561,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-

peps/pep-0544.rst

@@ -369,7 +369,7 @@ Examples::
       def __init__(self, name: str, value: int) -> None:
           self.name = name
           self.value = value
-      
+
       def method(self) -> None:
           return
 

peps/pep-0563.rst

@@ -263,8 +263,8 @@ valid.  They can use local names or the fully qualified name.  Example::
             def method(self) -> C.D.field2:  # this is OK
                 ...
 
-            def method(self) -> D.field2:  # this FAILS, class D is local to C 
-                ...                        # and is therefore only available 
+            def method(self) -> D.field2:  # this FAILS, class D is local to C
+                ...                        # and is therefore only available
                                            # as C.D. This was already true
                                            # before the PEP.
 
@@ -273,7 +273,7 @@ valid.  They can use local names or the fully qualified name.  Example::
 
             def method(self) -> field:  # this FAILS, field is local to C and
                                         # is therefore not visible to D unless
-                                        # accessed as C.field. This was already 
+                                        # accessed as C.field. This was already
                                         # true before the PEP.
 
 In the presence of an annotation that isn't a syntactically valid

peps/pep-0582.rst

@@ -86,7 +86,7 @@ startup.
 When the interactive interpreter starts, if a ``__pypackages__`` directory is
 found in the current working directory, then it will be included in
 ``sys.path`` after the entry for current working directory and just before the
-system site-packages. 
+system site-packages.
 
 When the interpreter runs a script, Python will try to find ``__pypackages__``
 in the same directory as the script. If found (along with the current Python

peps/pep-0586.rst

@@ -258,7 +258,7 @@ allowing them in future extensions of this PEP.
 -  Floats: e.g. ``Literal[3.14]``. Representing Literals of infinity or NaN
    in a clean way is tricky; real-world APIs are unlikely to vary their
    behavior based on a float parameter.
-  
+
 -  Any: e.g. ``Literal[Any]``. ``Any`` is a type, and ``Literal[...]`` is
    meant to contain values only. It is also unclear what ``Literal[Any]``
    would actually semantically mean.
@@ -584,7 +584,7 @@ involving Literal bools. For example, we can combine ``Literal[True]``,
        scalar += 3      # Type checks: type of 'scalar' is narrowed to 'int'
    else:
        scalar += "foo"  # Type checks: type of 'scalar' is narrowed to 'str'
-    
+
 Interactions with Final
 -----------------------
 

peps/pep-0611.rst

@@ -5,7 +5,7 @@ Status: Withdrawn
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 05-Dec-2019
-Post-History: 
+Post-History:
 
 
 Abstract
@@ -16,7 +16,7 @@ for various aspects of Python code and its implementation.
 The Python language does not specify limits for many of its features.
 Not having any limit to these values seems to enhance programmer freedom,
 at least superficially, but in practice the CPython VM and other Python virtual
-machines have implicit limits or are forced to assume that the limits are 
+machines have implicit limits or are forced to assume that the limits are
 astronomical, which is expensive.
 
 This PR lists a number of features which are to have a limit of one million.
@@ -36,7 +36,7 @@ It is inefficient as actual values rarely need more than a dozen or so bits to r
 
 It is unsafe as malicious or poorly generated code could cause values to exceed 2\ :sup:`32`.
 
-For example, line numbers are represented by 32 bit values internally. 
+For example, line numbers are represented by 32 bit values internally.
 This is inefficient, given that modules almost never exceed a few thousand lines.
 Despite being inefficient, it is still vulnerable to overflow as
 it is easy for an attacker to created a module with billions of newline characters.
@@ -73,7 +73,7 @@ Imposing a limit on values such as lines of code in a module, and the number of
 has significant advantages for ease of implementation and efficiency of virtual machines.
 If the limit is sufficiently large, there is no adverse effect on users of the language.
 
-By selecting a fixed but large limit for these values, 
+By selecting a fixed but large limit for these values,
 it is possible to have both safety and efficiency whilst causing no inconvenience to human programmers
 and only very rare problems for code generators.
 

peps/pep-0615.rst

@@ -188,7 +188,7 @@ of the interpreter, it must not invalidate any caches or modify any
 existing ``ZoneInfo`` objects. Newly constructed ``ZoneInfo`` objects, however,
 should come from the updated data source.
 
-This means that the point at which the data source is updated for new 
+This means that the point at which the data source is updated for new
 invocations of the ``ZoneInfo`` constructor depends primarily on the semantics
 of the caching behavior. The only guaranteed way to get a ``ZoneInfo`` object
 from an updated data source is to induce a cache miss, either by bypassing the

peps/pep-0616.rst

@@ -294,11 +294,11 @@ built-in functions, a common theme is that if a beginner finds
 themselves manually indexing or slicing a string, then they should
 consider whether there is a higher-level method that better
 communicates *what* the code should do rather than merely *how* the
-code should do it.  The proposed  ``removeprefix()`` and 
+code should do it.  The proposed  ``removeprefix()`` and
 ``removesuffix()`` methods expand the high-level string "toolbox" and
 further allow for this sort of skepticism toward manual slicing.
 
-The main opportunity for user confusion will be the conflation of 
+The main opportunity for user confusion will be the conflation of
 ``lstrip``/``rstrip`` with ``removeprefix``/``removesuffix``.
 It may therefore be helpful to emphasize (as the documentation will)
 the following differences between the methods:

peps/pep-0617.rst

@@ -623,7 +623,7 @@ A similar grammar written to target Python AST objects:
 .. code:: PEG
 
   start: expr NEWLINE? ENDMARKER { ast.Expression(expr) }
-  expr: 
+  expr:
       | expr '+' term { ast.BinOp(expr, ast.Add(), term) }
       | expr '-' term { ast.BinOp(expr, ast.Sub(), term) }
       | term { term }
@@ -637,7 +637,7 @@ A similar grammar written to target Python AST objects:
       | '(' expr ')' { expr }
       | atom { atom }
 
-  atom: 
+  atom:
       | NAME { ast.Name(id=name.string, ctx=ast.Load()) }
       | NUMBER { ast.Constant(value=ast.literal_eval(number.string)) }
 

peps/pep-0625.rst

@@ -67,7 +67,7 @@ the metadata available in the filename.
 This PEP also serves as the formal specification to the long-standing
 filename convention used by the current sdist implementations. The filename
 contains the distribution name and version, to aid tools identifying a
-distribution without needing to download, unarchive the file, and perform 
+distribution without needing to download, unarchive the file, and perform
 costly metadata generation for introspection, if all the information they need
 is available in the filename.
 

peps/pep-0626.rst

@@ -77,7 +77,7 @@ All expressions and parts of expressions are considered to be executable code.
 In general, all statements are also considered to be executable code. However, when a statement is spread over several lines,
 we must consider which parts of a statement are considered to be executable code.
 
-Statements are made up of keywords and expressions. Not all keywords have a direct runtime effect, so not all keywords are considered to be executable code. 
+Statements are made up of keywords and expressions. Not all keywords have a direct runtime effect, so not all keywords are considered to be executable code.
 For example, ``else``, is a necessary part of an ``if`` statement, but there is no runtime effect associated with an ``else``.
 
 For the purposes of tracing, the following keywords will *not* be considered to be executable code:
@@ -304,7 +304,7 @@ The ``PyLineTable_`` functions do not call into the C-API, so can be safely copi
 The ``PyCodeAddressRange`` struct will not be changed, but the ``_opaque`` struct is not part of the specification and may change.
 
 .. note::
-  The ``PyCodeAddressRange`` struct has changed from the original version of this PEP, where the addition fields were defined, but 
+  The ``PyCodeAddressRange`` struct has changed from the original version of this PEP, where the addition fields were defined, but
   were liable to change.
 
 For example, the following code prints out all the address ranges:

peps/pep-0636.rst

@@ -164,7 +164,7 @@ Adding a wildcard
 ------------------
 
 You may want to print an error message saying that the command wasn't recognized when
-all the patterns fail. You could use the feature we just learned and write 
+all the patterns fail. You could use the feature we just learned and write
 ``case [*ignored_words]`` as your last pattern. There's however a much simpler way::
 
    match command.split():
@@ -312,7 +312,7 @@ different kinds of objects, and also apply patterns to its attributes::
             game.go_north()
         ...
         case KeyPress():
-            pass # Ignore other keystrokes 
+            pass # Ignore other keystrokes
         case other_event:
             raise ValueError(f"Unrecognized event: {other_event}")
 
@@ -417,13 +417,13 @@ mappings based on their present keys. In this case you could use::
 
 The keys in your mapping pattern need to be literals, but the values can be any
 pattern. As in sequence patterns, all subpatterns have to match for the general
-pattern to match. 
+pattern to match.
 
 You can use ``**rest`` within a mapping pattern to capture additional keys in
 the subject. Note that if you omit this, extra keys in the subject will be
-ignored while matching, i.e. the message 
+ignored while matching, i.e. the message
 ``{"text": "foo", "color": "red", "style": "bold"}`` will match the first pattern
-in the example above. 
+in the example above.
 
 Matching builtin classes
 ------------------------
@@ -433,7 +433,7 @@ source, the types of the field could be wrong, leading to bugs or security issue
 
 Any class is a valid match target, and that includes built-in classes like ``bool``
 ``str`` or ``int``. That allows us to combine the code above with a class pattern.
-So instead of writing ``{"text": message, "color": c}`` we can use 
+So instead of writing ``{"text": message, "color": c}`` we can use
 ``{"text": str() as message, "color": str() as c}`` to ensure that ``message`` and ``c``
 are both strings. For many builtin classes (see :pep:`634` for the whole list), you can
 use a positional parameter as a shorthand, writing ``str(c)`` rather than ``str() as c``.