@@ -106,7 +106,7 @@ turn it into a general purpose wildcard marker that always skips making a new
106
106
local variable binding.
107
107
108
108
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
110
110
matching proposal in :pep: `634 `. This PEP is somewhat complementary to that one, as
111
111
even though this PEP is mostly about surface syntax changes rather than major
112
112
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
127
127
an adequate foundation for the syntax used in match patterns.
128
128
129
129
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 ]_ :
131
131
132
132
The actual problem that I see is that we have different cultures/intuitions
133
133
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
155
155
second assertion was not accurate, and that match patterns could be treated
156
156
as a variation on assignment targets without leading to inherent contradictions.
157
157
(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 ]_ ).
159
159
160
160
However, the review process for this PEP strongly suggested that not only did
161
161
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
164
164
abandon alignment between the sequence matching syntax and the existing iterable
165
165
unpacking syntax (effectively answering "Not really, as least as far as the
166
166
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
168
168
object and data layouts?").
169
169
170
170
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
492
492
value patterns would instead be written more explicitly as value constraints::
493
493
494
494
# Literal patterns
495
- match number:
495
+ match number:
496
496
case == 0:
497
497
print("Nothing")
498
498
case == 1:
@@ -505,7 +505,7 @@ value patterns would instead be written more explicitly as value constraints::
505
505
print("Good luck with that...")
506
506
507
507
# Additional literal patterns
508
- match value:
508
+ match value:
509
509
case == True:
510
510
print("True or 1")
511
511
case == False:
@@ -696,7 +696,7 @@ sequence.
696
696
697
697
Subpatterns are mostly required to be closed patterns, but the parentheses may
698
698
be omitted for value constraints. Sequence elements may also be captured
699
- unconditionally without parentheses.
699
+ unconditionally without parentheses.
700
700
701
701
Note: where :pep: `634 ` allows all the same syntactic flexibility as iterable
702
702
unpacking in assignment statements, this PEP restricts sequence patterns
@@ -1091,7 +1091,7 @@ next question is to ask exactly what that prefix should be.
1091
1091
The initially published version of this PEP proposed using the previously
1092
1092
unused ``? `` symbol as the prefix for equality constraints, and ``?is `` as the
1093
1093
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
1095
1095
operators (``== `` and ``is ``) instead.
1096
1096
1097
1097
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
1142
1142
to use existing comparison operations rather than ``? `` and ``?is ``, that
1143
1143
argument holds for this PEP as well.
1144
1144
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
1146
1146
problematic as it would likely mean that match patterns would have a *permanent *
1147
1147
difference from all other parts of Python - the use of ``_ `` in software
1148
1148
internationalisation and at the interactive prompt means that there isn't really
1149
1149
a plausible path towards using it as a general purpose "skipped binding" marker.
1150
1150
1151
1151
``__ `` 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
1153
1153
various meanings of ``_ `` in existing Python code.
1154
1154
1155
1155
This PEP also proposes adopting an implementation technique that limits
@@ -1764,8 +1764,8 @@ a human reader as well: ``case {0: == 0}:``
1764
1764
Reference Implementation
1765
1765
========================
1766
1766
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 ]_ .
1769
1769
1770
1770
Relative to the text of this PEP, the draft reference implementation has not
1771
1771
yet complemented the special casing of several builtin and standard library
@@ -1860,7 +1860,7 @@ References
1860
1860
https://gvanrossum.github.io/docs/PyPatternMatching.pdf
1861
1861
1862
1862
1863
- .. _ Appendix A :
1863
+ .. _ 642-appendix-a :
1864
1864
1865
1865
Appendix A -- Full Grammar
1866
1866
==========================
@@ -1970,7 +1970,7 @@ Notation used beyond standard EBNF is as per :pep:`534`:
1970
1970
| '**' '{' [attrs_constraint_elements] '}'
1971
1971
1972
1972
1973
- .. _ Appendix B :
1973
+ .. _ 642-appendix-b :
1974
1974
1975
1975
Appendix B: Summary of Abstract Syntax Tree changes
1976
1976
===================================================
@@ -2003,7 +2003,7 @@ The following new nodes are added to the AST by this PEP::
2003
2003
matchop = EqCheck | IdCheck
2004
2004
2005
2005
2006
- .. _ Appendix C :
2006
+ .. _ 642-appendix-c :
2007
2007
2008
2008
Appendix C: Summary of changes relative to PEP 634
2009
2009
==================================================
@@ -2073,7 +2073,7 @@ binary addition and subtraction operations on constants, so proposals like
2073
2073
:pep: `634 ` have to do work in later compilation steps to check for correct usage.
2074
2074
2075
2075
2076
- .. _ Appendix D :
2076
+ .. _ 642-appendix-d :
2077
2077
2078
2078
Appendix D: History of changes to this proposal
2079
2079
===============================================
@@ -2104,14 +2104,3 @@ Copyright
2104
2104
2105
2105
This document is placed in the public domain or under the
2106
2106
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