Skip to content

Commit 3a792e4

Browse files
authored
PEP 642: Fix footnotes (#2718)
1 parent 5e0be8f commit 3a792e4

File tree

1 file changed

+16
-27
lines changed

1 file changed

+16
-27
lines changed

pep-0642.rst

Lines changed: 16 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -106,7 +106,7 @@ turn it into a general purpose wildcard marker that always skips making a new
106106
local variable binding.
107107

108108
While it has not yet been put forward as a PEP, Mark Shannon has a pre-PEP draft
109-
[8_] expressing several concerns about the runtime semantics of the pattern
109+
[8]_ expressing several concerns about the runtime semantics of the pattern
110110
matching proposal in :pep:`634`. This PEP is somewhat complementary to that one, as
111111
even though this PEP is mostly about surface syntax changes rather than major
112112
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
127127
an adequate foundation for the syntax used in match patterns.
128128

129129
While the PEP didn't explicitly state this assumption, one of the PEP authors
130-
explained it clearly on python-dev [1_]:
130+
explained it clearly on python-dev [1]_:
131131

132132
The actual problem that I see is that we have different cultures/intuitions
133133
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
155155
second assertion was not accurate, and that match patterns could be treated
156156
as a variation on assignment targets without leading to inherent contradictions.
157157
(An earlier PR submitted to list this option in the "Rejected Ideas" section
158-
of the original :pep:`622` had previously been declined [2_]).
158+
of the original :pep:`622` had previously been declined [2]_).
159159

160160
However, the review process for this PEP strongly suggested that not only did
161161
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
164164
abandon alignment between the sequence matching syntax and the existing iterable
165165
unpacking syntax (effectively answering "Not really, as least as far as the
166166
exact syntax is concerned" to the first question raised in the DLS'20 paper
167-
[9_]: "Can we extend a feature like iterable unpacking to work for more general
167+
[9]_: "Can we extend a feature like iterable unpacking to work for more general
168168
object and data layouts?").
169169

170170
This resulted in a complete reversal of the goals of the PEP: rather than
@@ -492,7 +492,7 @@ If this PEP were to be adopted in preference to :pep:`634`, then all literal and
492492
value patterns would instead be written more explicitly as value constraints::
493493

494494
# Literal patterns
495-
match number:
495+
match number:
496496
case == 0:
497497
print("Nothing")
498498
case == 1:
@@ -505,7 +505,7 @@ value patterns would instead be written more explicitly as value constraints::
505505
print("Good luck with that...")
506506

507507
# Additional literal patterns
508-
match value:
508+
match value:
509509
case == True:
510510
print("True or 1")
511511
case == False:
@@ -696,7 +696,7 @@ sequence.
696696

697697
Subpatterns are mostly required to be closed patterns, but the parentheses may
698698
be omitted for value constraints. Sequence elements may also be captured
699-
unconditionally without parentheses.
699+
unconditionally without parentheses.
700700

701701
Note: where :pep:`634` allows all the same syntactic flexibility as iterable
702702
unpacking in assignment statements, this PEP restricts sequence patterns
@@ -1091,7 +1091,7 @@ next question is to ask exactly what that prefix should be.
10911091
The initially published version of this PEP proposed using the previously
10921092
unused ``?`` symbol as the prefix for equality constraints, and ``?is`` as the
10931093
prefix for identity constraints. When reviewing the PEP, Steven D'Aprano
1094-
presented a compelling counterproposal [5_] to use the existing comparison
1094+
presented a compelling counterproposal [5]_ to use the existing comparison
10951095
operators (``==`` and ``is``) instead.
10961096

10971097
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
11421142
to use existing comparison operations rather than ``?`` and ``?is``, that
11431143
argument holds for this PEP as well.
11441144

1145-
However, as noted by Thomas Wouters in [6_], :pep:`634`'s choice of ``_`` remains
1145+
However, as noted by Thomas Wouters in [6]_, :pep:`634`'s choice of ``_`` remains
11461146
problematic as it would likely mean that match patterns would have a *permanent*
11471147
difference from all other parts of Python - the use of ``_`` in software
11481148
internationalisation and at the interactive prompt means that there isn't really
11491149
a plausible path towards using it as a general purpose "skipped binding" marker.
11501150

11511151
``__`` is an alternative "this value is not needed" marker drawn from a Stack
1152-
Overflow answer [7_] (originally posted by the author of this PEP) on the
1152+
Overflow answer [7]_ (originally posted by the author of this PEP) on the
11531153
various meanings of ``_`` in existing Python code.
11541154

11551155
This PEP also proposes adopting an implementation technique that limits
@@ -1764,8 +1764,8 @@ a human reader as well: ``case {0: == 0}:``
17641764
Reference Implementation
17651765
========================
17661766

1767-
A draft reference implementation for this PEP [3_] has been derived from Brandt
1768-
Bucher's reference implementation for :pep:`634` [4_].
1767+
A draft reference implementation for this PEP [3]_ has been derived from Brandt
1768+
Bucher's reference implementation for :pep:`634` [4]_.
17691769

17701770
Relative to the text of this PEP, the draft reference implementation has not
17711771
yet complemented the special casing of several builtin and standard library
@@ -1860,7 +1860,7 @@ References
18601860
https://gvanrossum.github.io/docs/PyPatternMatching.pdf
18611861
18621862
1863-
.. _Appendix A:
1863+
.. _642-appendix-a:
18641864

18651865
Appendix A -- Full Grammar
18661866
==========================
@@ -1970,7 +1970,7 @@ Notation used beyond standard EBNF is as per :pep:`534`:
19701970
| '**' '{' [attrs_constraint_elements] '}'
19711971

19721972

1973-
.. _Appendix B:
1973+
.. _642-appendix-b:
19741974

19751975
Appendix B: Summary of Abstract Syntax Tree changes
19761976
===================================================
@@ -2003,7 +2003,7 @@ The following new nodes are added to the AST by this PEP::
20032003
matchop = EqCheck | IdCheck
20042004

20052005

2006-
.. _Appendix C:
2006+
.. _642-appendix-c:
20072007

20082008
Appendix C: Summary of changes relative to PEP 634
20092009
==================================================
@@ -2073,7 +2073,7 @@ binary addition and subtraction operations on constants, so proposals like
20732073
:pep:`634` have to do work in later compilation steps to check for correct usage.
20742074

20752075

2076-
.. _Appendix D:
2076+
.. _642-appendix-d:
20772077

20782078
Appendix D: History of changes to this proposal
20792079
===============================================
@@ -2104,14 +2104,3 @@ Copyright
21042104

21052105
This document is placed in the public domain or under the
21062106
CC0-1.0-Universal license, whichever is more permissive.
2107-
2108-
2109-
2110-
..
2111-
Local Variables:
2112-
mode: indented-text
2113-
indent-tabs-mode: nil
2114-
sentence-end-double-space: t
2115-
fill-column: 70
2116-
coding: utf-8
2117-
End:

0 commit comments

Comments
 (0)