From 3a792e4a1dd52258342788b8ed628f1059ce69d5 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade Date: Thu, 21 Jul 2022 00:47:57 +0300 Subject: [PATCH] PEP 642: Fix footnotes (#2718) --- pep-0642.rst | 43 ++++++++++++++++--------------------------- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/pep-0642.rst b/pep-0642.rst index f582b302f..8742804dc 100644 --- a/pep-0642.rst +++ b/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 @@ -492,7 +492,7 @@ If this PEP were to be adopted in preference to :pep:`634`, then all literal and value patterns would instead be written more explicitly as value constraints:: # Literal patterns - match number: + match number: case == 0: print("Nothing") case == 1: @@ -505,7 +505,7 @@ value patterns would instead be written more explicitly as value constraints:: print("Good luck with that...") # Additional literal patterns - match value: + match value: case == True: print("True or 1") case == False: @@ -696,7 +696,7 @@ sequence. Subpatterns are mostly required to be closed patterns, but the parentheses may be omitted for value constraints. Sequence elements may also be captured -unconditionally without parentheses. +unconditionally without parentheses. Note: where :pep:`634` allows all the same syntactic flexibility as iterable unpacking in assignment statements, this PEP restricts sequence patterns @@ -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: