PEP 642: Fix footnotes (#2718)

pep-0642.rst

@@ -106,7 +106,7 @@ turn it into a general purpose wildcard marker that always skips making a new
 local variable binding.
 
 While it has not yet been put forward as a PEP, Mark Shannon has a pre-PEP draft
-[8_] expressing several concerns about the runtime semantics of the pattern
+[8]_ expressing several concerns about the runtime semantics of the pattern
 matching proposal in :pep:`634`. This PEP is somewhat complementary to that one, as
 even though this PEP is mostly about surface syntax changes rather than major
 semantic changes, it does propose that the Abstract Syntax Tree definition be
@@ -127,7 +127,7 @@ neither ordinary expressions *nor* the existing assignment target syntax provide
 an adequate foundation for the syntax used in match patterns.
 
 While the PEP didn't explicitly state this assumption, one of the PEP authors
-explained it clearly on python-dev [1_]:
+explained it clearly on python-dev [1]_:
 
     The actual problem that I see is that we have different cultures/intuitions
     fundamentally clashing here.  In particular, so many programmers welcome
@@ -155,7 +155,7 @@ The first iteration of this PEP was then born out of an attempt to show that the
 second assertion was not accurate, and that match patterns could be treated
 as a variation on assignment targets without leading to inherent contradictions.
 (An earlier PR submitted to list this option in the "Rejected Ideas" section
-of the original :pep:`622` had previously been declined [2_]).
+of the original :pep:`622` had previously been declined [2]_).
 
 However, the review process for this PEP strongly suggested that not only did
 the contradictions that Tobias mentioned in his email exist, but they were also
@@ -164,7 +164,7 @@ Accordingly, this PEP was changed to go even further than :pep:`634`, and largel
 abandon alignment between the sequence matching syntax and the existing iterable
 unpacking syntax (effectively answering "Not really, as least as far as the
 exact syntax is concerned" to the first question raised in the DLS'20 paper
-[9_]: "Can we extend a feature like iterable unpacking to work for more general
+[9]_: "Can we extend a feature like iterable unpacking to work for more general
 object and data layouts?").
 
 This resulted in a complete reversal of the goals of the PEP: rather than
@@ -1091,7 +1091,7 @@ next question is to ask exactly what that prefix should be.
 The initially published version of this PEP proposed using the previously
 unused ``?`` symbol as the prefix for equality constraints, and ``?is`` as the
 prefix for identity constraints. When reviewing the PEP, Steven D'Aprano
-presented a compelling counterproposal [5_] to use the existing comparison
+presented a compelling counterproposal [5]_ to use the existing comparison
 operators (``==`` and ``is``) instead.
 
 There were a few concerns with ``==`` as a prefix that kept it from being
@@ -1142,14 +1142,14 @@ marker would be a bad idea. With the syntax for value constraints changed
 to use existing comparison operations rather than ``?`` and ``?is``, that
 argument holds for this PEP as well.
 
-However, as noted by Thomas Wouters in [6_], :pep:`634`'s choice of ``_`` remains
+However, as noted by Thomas Wouters in [6]_, :pep:`634`'s choice of ``_`` remains
 problematic as it would likely mean that match patterns would have a *permanent*
 difference from all other parts of Python - the use of ``_`` in software
 internationalisation and at the interactive prompt means that there isn't really
 a plausible path towards using it as a general purpose "skipped binding" marker.
 
 ``__`` is an alternative "this value is not needed" marker drawn from a Stack
-Overflow answer [7_] (originally posted by the author of this PEP) on the
+Overflow answer [7]_ (originally posted by the author of this PEP) on the
 various meanings of ``_`` in existing Python code.
 
 This PEP also proposes adopting an implementation technique that limits
@@ -1764,8 +1764,8 @@ a human reader as well: ``case {0: == 0}:``
 Reference Implementation
 ========================
 
-A draft reference implementation for this PEP [3_] has been derived from Brandt
-Bucher's reference implementation for :pep:`634` [4_].
+A draft reference implementation for this PEP [3]_ has been derived from Brandt
+Bucher's reference implementation for :pep:`634` [4]_.
 
 Relative to the text of this PEP, the draft reference implementation has not
 yet complemented the special casing of several builtin and standard library
@@ -1860,7 +1860,7 @@ References
    https://gvanrossum.github.io/docs/PyPatternMatching.pdf
 
 
-.. _Appendix A:
+.. _642-appendix-a:
 
 Appendix A -- Full Grammar
 ==========================
@@ -1970,7 +1970,7 @@ Notation used beyond standard EBNF is as per :pep:`534`:
         | '**' '{' [attrs_constraint_elements] '}'
 
 
-.. _Appendix B:
+.. _642-appendix-b:
 
 Appendix B: Summary of Abstract Syntax Tree changes
 ===================================================
@@ -2003,7 +2003,7 @@ The following new nodes are added to the AST by this PEP::
     matchop = EqCheck | IdCheck
 
 
-.. _Appendix C:
+.. _642-appendix-c:
 
 Appendix C: Summary of changes relative to PEP 634
 ==================================================
@@ -2073,7 +2073,7 @@ binary addition and subtraction operations on constants, so proposals like
 :pep:`634` have to do work in later compilation steps to check for correct usage.
 
 
-.. _Appendix D:
+.. _642-appendix-d:
 
 Appendix D: History of changes to this proposal
 ===============================================
@@ -2104,14 +2104,3 @@ Copyright
 
 This document is placed in the public domain or under the
 CC0-1.0-Universal license, whichever is more permissive.
-
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End: