Remove trailing spaces from many PEPs (python#983)

Author: serhiy-storchaka

README.rst

@@ -21,10 +21,10 @@ reStructuredText for PEPs
 =========================
 
 Original PEP source should be written in reStructuredText format,
-which is a constrained version of plaintext, and is described in 
+which is a constrained version of plaintext, and is described in
 PEP 12.  Older PEPs were often written in a more mildly restricted
-plaintext format, as described in PEP 9.  The ``pep2html.py`` 
-processing and installation script knows how to produce the HTML 
+plaintext format, as described in PEP 9.  The ``pep2html.py``
+processing and installation script knows how to produce the HTML
 for either PEP format.
 
 For processing reStructuredText format PEPs, you need the docutils

pep-0001.txt

@@ -427,7 +427,7 @@ Each PEP should have the following parts/sections:
    The rationale should provide evidence of consensus within the
    community and discuss important objections or concerns raised
    during discussion.
-   
+
 5. Specification -- The technical specification should describe the
    syntax and semantics of any new language feature.  The
    specification should be detailed enough to allow competing,
@@ -440,7 +440,7 @@ Each PEP should have the following parts/sections:
    author proposes to deal with these incompatibilities.  PEP
    submissions without a sufficient backwards compatibility treatise
    may be rejected outright.
-   
+
 7. Security Implications -- If there are security concerns in relation
    to the PEP, those concerns should be explicitly written out to make
    sure reviewers of the PEP are aware of them.
@@ -465,14 +465,14 @@ Each PEP should have the following parts/sections:
    The final implementation must include test code and documentation
    appropriate for either the Python language reference or the
    standard library reference.
-   
+
 10. Rejected Ideas -- Throughout the discussion of a PEP, various ideas
     will be proposed which are not accepted. Those rejected ideas should
     be recorded along with the reasoning as to why they were rejected.
     This both helps record the thought process behind the final version
     of the PEP as well as preventing people from bringing up the same
     rejected idea again in subsequent discussions.
-   
+
     In a way this section can be thought of as a breakout section of the
     Rationale section that is focused specifically on why certain ideas
     were not ultimately pursued.
@@ -483,9 +483,9 @@ Each PEP should have the following parts/sections:
     resolution. This helps make sure all issues required for the PEP to be
     ready for consideration are complete complete and reduces people
     duplicating prior discussion.
-    
-12. References -- A collection of URLs used as references through the PEP. 
-   
+
+12. References -- A collection of URLs used as references through the PEP.
+
 13. Copyright/public domain -- Each PEP must either be explicitly
     labeled as placed in the public domain (see this PEP as an
     example) or licensed under the `Open Publication License`_.

pep-0012.rst

@@ -73,7 +73,7 @@ directions below.
   Your email address may appear second (or it can be omitted) and if
   it appears, it must appear in angle brackets.  It is okay to
   obfuscate your email address.
-  
+
 - If none of the authors are Python core developers and this PEP is
   ready to be submitted to the PEP repository, include a Sponsor header
   with the name of the core developer sponsoring your PEP.
@@ -158,7 +158,7 @@ your PEP)::
   Title: [...]
   Author: [Full Name <email at example.com>]
   Sponsor: *[Full Name <email at example.com>]
-  BDFL-Delegate: 
+  BDFL-Delegate:
   Discussions-To: *[...]
   Status: Draft
   Type: [Standards Track | Informational | Process]
@@ -603,8 +603,8 @@ should be avoided.  For ordinary text, use ordinary 'single-quotes' or
 above), use double-backquotes::
 
     ``literal text: in here, anything goes!``
-    
-    
+
+
 Suggested Sections
 ==================
 Various sections are found to be common across PEPs and are outlined in
@@ -613,70 +613,70 @@ PEP 1 [1]_. Those sections are provided here for convenience.
 
   Abstract
   ========
-  
+
   [A short (~200 word) description of the technical issue being addressed.]
-  
-  
+
+
   Motivation
   ==========
-  
+
   [Clearly explain why the existing language specification is inadequate to address the problem that the PEP solves.]
-  
-  
+
+
   Rationale
   =========
-  
+
   [Describe why particular design decisions were made.]
-  
-  
+
+
   Specification
   =============
-  
+
   [Describe the syntax and semantics of any new language feature.]
-  
-  
+
+
   Backwards Compatibility
   =======================
-  
+
   [Describe potential impact and severity on pre-existing code.]
-  
-  
+
+
   Security Implications
   =====================
-  
+
   [How could a malicious user take advantage of this new feature?]
-  
-  
+
+
   How to Teach This
   =================
-  
+
   [How to teach users, new and experienced, how to apply the PEP to their work.]
-  
-  
+
+
   Reference Implementation
   ========================
-  
+
   [Link to any existing implementation and details about its state, e.g. proof-of-concept.]
-  
-  
+
+
   Rejected Ideas
   ==============
-  
+
   [Why certain ideas that were brought while discussing this PEP were not ultimately pursued.]
-  
-  
+
+
   Open Issues
   ===========
-  
+
   [Any points that are still being decided/discussed.]
-  
-  
+
+
   References
   ==========
-  
+
   [A collection of URLs used as references through the PEP.]
-  
-  
+
+
   Copyright
   =========
 

pep-0203.txt

@@ -226,7 +226,7 @@ members must first check that they are available with the
     if (PyType_HasFeature(x->ob_type, Py_TPFLAGS_HAVE_INPLACE_OPS) &&
         x->ob_type->tp_as_number && x->ob_type->tp_as_number->nb_inplace_add) {
             /* ... */
- 
+
 This check must be made even before testing the method slots for ``NULL``
 values!  The macro only tests whether the slots are available, not whether
 they are filled with methods or not.

pep-0225.txt

@@ -482,7 +482,7 @@ Miscellaneous issues
 - Additional multiplication operators.  Several forms of multiplications are
   used in (multi-)linear algebra.  Most can be seen as variations of
   multiplication in linear algebra sense (such as Kronecker product).  But two
-  forms appear to be more fundamental: outer product and inner product. 
+  forms appear to be more fundamental: outer product and inner product.
   However, their specification includes indices, which can be either
 
   - associated with the operator, or
@@ -542,7 +542,7 @@ a given operator.  Several examples are listed here:
    Among them, the ``&`` ``|`` ``^`` ``~`` operators can be regarded as
    elementwise versions of lattice operators applied to integers regarded as
    bit strings.::
-   
+
        5 and 6                # 6
        5 or 6                 # 5
 
@@ -556,7 +556,7 @@ a given operator.  Several examples are listed here:
    make ``xor`` a reserved word.
 
 2. List arithmetics.::
-   
+
        [1, 2] + [3, 4]        # [1, 2, 3, 4]
        [1, 2] ~+ [3, 4]       # [4, 6]
 

pep-0255.txt

@@ -386,7 +386,7 @@ Then why not some other special syntax without a new keyword?
 -------------------------------------------------------------
 
 For example, one of these instead of ``yield 3``::
- 
+
     return 3 and continue
     return and continue 3
     return generating 3

pep-0440.txt

@@ -1534,7 +1534,7 @@ the initial reference implementation was released in setuptools 8.0 and pip
   This change was based on user feedback received when setuptools 8.0
   started applying normalisation to the release metadata generated when
   preparing packages for publication on PyPI [8]_.
-  
+
 * The PEP text and the ``is_canonical`` regex were updated to be explicit
   that numeric components are specifically required to be represented as
   squences of ASCII digits, not arbitrary Unicode [Nd] code points. This
@@ -1575,7 +1575,7 @@ justifications for needing such a standard can be found in PEP 386.
 
 .. [9] Changing the status of PEP 440 to Provisional
    https://mail.python.org/pipermail/distutils-sig/2014-December/025412.html
-   
+
 .. [10] PEP 440: regex should not permit Unicode [Nd] characters
    https://github.com/python/peps/pull/966
 

pep-0447.txt

@@ -49,8 +49,8 @@ dictionary::
               return cls.__dict__[name]
           except KeyError:
               raise AttributeError(name) from None
-              
-              
+
+
 PEP Status
 ==========
 

pep-0505.rst

@@ -170,7 +170,7 @@ short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated::
             _v = _v[e]
     await _v
 
-.. note:: 
+.. note::
     ``await`` will almost certainly fail in this context, as it would in
     the case where code attempts ``await None``. We are not proposing to add a
     ``None``-aware ``await`` keyword here, and merely include it in this

pep-0512.txt

@@ -774,7 +774,7 @@ Optional features:
   - `Bot to generate cherry-pick pull requests`_
   - Write `.github/CONTRIBUTING.md`
     (to prevent PRs that are inappropriate from even showing up and pointing to the devguide)
-  
+
 
 
 Open Issues

pep-0538.txt

@@ -466,7 +466,7 @@ successfully configured::
 
 (Note: this warning ended up being silenced by default. See the
 Implementation Note above for more details)
-  
+
 As long as the current platform provides at least one of the candidate UTF-8
 based environments, this locale coercion will mean that the standard
 Python binary *and* locale-aware extensions should once again "just work"

pep-0541.txt

@@ -219,17 +219,17 @@ names as unavailable for security reasons.
 Intellectual property policy
 ----------------------------
 
-It is the policy of Python Software Foundation and the Package Index 
-maintainers to be appropriately responsive to claims of intellectual 
+It is the policy of Python Software Foundation and the Package Index
+maintainers to be appropriately responsive to claims of intellectual
 property infringement by third parties. It is not the policy of
 the Python Software Foundation nor the Package Index maintainers
-to pre-screen uploaded packages for any type of intellectual property 
-infringement. 
+to pre-screen uploaded packages for any type of intellectual property
+infringement.
 
 Possibly-infringing packages should be reported to [email protected]
-and counsel to the Python Software Foundation will determine an 
+and counsel to the Python Software Foundation will determine an
 appropriate response. A package can be removed or transferred to a
-new owner at the sole discretion of the Python Software Foundation to 
+new owner at the sole discretion of the Python Software Foundation to
 address a claim of infringement.
 
 A project published on the Package Index meeting ANY of the following
@@ -244,9 +244,9 @@ or transferral to a new owner:
   the subject of a complaint; or
 * project is subject to an active lawsuit.
 
-In the event of a complaint for intellectual property infringement, 
-a copy of the complaint will be sent to the package owner. In some 
-cases, action may be taken by the Package Index maintainers before 
+In the event of a complaint for intellectual property infringement,
+a copy of the complaint will be sent to the package owner. In some
+cases, action may be taken by the Package Index maintainers before
 the owner responds.
 
 

pep-0547.rst

@@ -9,7 +9,7 @@ Type: Standards Track
 Content-Type: text/x-rst
 Created: 25-May-2017
 Python-Version: 3.7
-Post-History: 
+Post-History:
 
 
 Deferral Notice
@@ -161,7 +161,7 @@ importlib's ``ExtensionFileLoader`` will get an implementation of
 extension module's ``PyInit_*`` function.
 
 The ``PyInit_*`` function can return either a fully initialized module
-(single-phase initialization) or a ``PyModuleDef`` (for PEP 489 multi-phase 
+(single-phase initialization) or a ``PyModuleDef`` (for PEP 489 multi-phase
 initialization).
 
 In the single-phase initialization case, ``_imp.exec_in_module`` will raise

pep-0549.rst

@@ -26,7 +26,7 @@ an extension to the descriptor protocol allowing use of
 the descriptor protocol for members of *instances.*  This
 would permit using properties in modules.
 
-Rationale 
+Rationale
 =========
 
 Python's descriptor protocol guides programmers towards