PEP 532, 577, 598: Fix footnotes references (#2791)

Author: hugovk

pep-0532.txt

@@ -107,7 +107,7 @@ PEP 335: Overloadable Boolean operators
 comparison chaining being one of the consequences of that change. The
 proposal in an earlier version of this PEP to instead handle the element-wise
 comparison use case by changing the semantic definition of comparison chaining
-is drawn directly from Guido's rejection of :pep:`335` [1_].
+is drawn directly from Guido's rejection of :pep:`335` [1]_.
 
 However, initial feedback on this PEP indicated that the number of different
 proposals that it covered made it difficult to read, so that part of the
@@ -875,9 +875,9 @@ interest in the idea of making these changes.
 Acknowledgements
 ================
 
-Thanks go to Steven D'Aprano for his detailed critique [2_] of the initial
+Thanks go to Steven D'Aprano for his detailed critique [2]_ of the initial
 draft of this PEP that inspired many of the changes in the second draft, as
-well as to all of the other participants in that discussion thread [3_]
+well as to all of the other participants in that discussion thread [3]_.
 
 
 References
@@ -897,13 +897,3 @@ Copyright
 
 This document has been placed in the public domain under the terms of the
 CC0 1.0 license: https://creativecommons.org/publicdomain/zero/1.0/
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End:

pep-0577.rst

@@ -490,7 +490,7 @@ Ignoring scoped expressions when determining augmented assignment targets
 -------------------------------------------------------------------------
 
 When discussing possible binding semantics for :pep:`572`'s assignment expressions,
-Tim Peters made a plausible case [1_,2_,3_] for assignment expressions targeting
+Tim Peters made a plausible case [1]_, [2]_, [3]_ for assignment expressions targeting
 the containing block scope, essentially ignoring any intervening scoped
 expressions.
 
@@ -505,7 +505,7 @@ way::
     while any(n % (factor := p) == 0 for p in small_primes):
         n //= factor
 
-Guido also expressed his approval for this general approach [4_].
+Guido also expressed his approval for this general approach [4]_.
 
 The proposal in this PEP differs from Tim's original proposal in three main
 areas:
@@ -536,7 +536,7 @@ One of the challenges with :pep:`572` is the fact that ``NAME = EXPR`` and
 makes the two forms hard to teach, since there's no inherent nudge towards
 choosing one over the other at the statement level, so you end up having to
 resort to "``NAME = EXPR`` is preferred because it's been around longer"
-(and :pep:`572` proposes to enfore that historical idiosyncrasy at the compiler
+(and :pep:`572` proposes to enforce that historical idiosyncrasy at the compiler
 level).
 
 That semantic equivalence is difficult to avoid at module and class scope while
@@ -820,14 +820,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End:

pep-0598.rst

@@ -36,7 +36,7 @@ proposal in :pep:`605`.
 However, the concerns raised in this PEP are likely to apply to any other
 "Long Term Support branch" proposals that allow feature backports to improve
 the developer experience of supporting such releases (such as the EL Python
-draft at [3_]), so the ideas presented here may provide useful design
+draft at [3]_), so the ideas presented here may provide useful design
 suggestions for such proposals.
 
 
@@ -612,7 +612,7 @@ in that release series.
 Implications for the proposed Scientific Python ecosystem support period
 ------------------------------------------------------------------------
 
-Based on discussions at SciPy 2019, a NEP is currently being drafted [2_] to
+Based on discussions at SciPy 2019, a NEP is currently being drafted [2]_ to
 define a common convention across the Scientific Python ecosystem for dropping
 support for older Python versions.
 
@@ -833,7 +833,7 @@ the subsequent October 2022 baseline feature release, as there are already inher
 compatibility risks associated with the choice of either "Python 4.0" (erroneous
 checks for the major version being exactly 3 rather than 3 or greater), or
 "Python 3.10" (code incorrectly assuming that the minor version will always
-contain exactly one decimal digit) [1_].
+contain exactly one decimal digit) [1]_.
 
 While the text of this PEP assumes that the release published in 2022 will be
 3.10 (as the PEP author personally considers that the more reasonable and most
@@ -883,7 +883,7 @@ References
 ==========
 
 .. [1] Anthony Sottile created a pseudo "Python 3.10" to find and fix such issues
-       (https://github.com/asottile/python3.10)
+       (https://github.com/asottile-archive/python3.10)
 
 .. [2] NEP proposing a standard policy for dropping support of old Python versions
        (https://github.com/numpy/numpy/pull/14086)
@@ -895,13 +895,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-
-
-..
-  Local Variables:
-  mode: indented-text
-  indent-tabs-mode: nil
-  sentence-end-double-space: t
-  fill-column: 80
-  coding: utf-8
-  End: