iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 642: Fix footnotes (#2718)

This commit is contained in:
Hugo van Kemenade 2022-07-21 00:47:57 +03:00 committed by GitHub
parent 5e0be8f86f
commit 3a792e4a1d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
pep-0642.rst
View File

@ -106,7 +106,7 @@ turn it into a general purpose wildcard marker that always skips making a new
local variable binding. local variable binding.
While it has not yet been put forward as a PEP, Mark Shannon has a pre-PEP draft 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 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 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 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. an adequate foundation for the syntax used in match patterns.
While the PEP didn't explicitly state this assumption, one of the PEP authors 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 The actual problem that I see is that we have different cultures/intuitions
fundamentally clashing here. In particular, so many programmers welcome 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 second assertion was not accurate, and that match patterns could be treated
as a variation on assignment targets without leading to inherent contradictions. as a variation on assignment targets without leading to inherent contradictions.
(An earlier PR submitted to list this option in the "Rejected Ideas" section (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 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 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 abandon alignment between the sequence matching syntax and the existing iterable
unpacking syntax (effectively answering "Not really, as least as far as the 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 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?"). object and data layouts?").
This resulted in a complete reversal of the goals of the PEP: rather than 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:: value patterns would instead be written more explicitly as value constraints::
# Literal patterns # Literal patterns
match number: match number:
case == 0: case == 0:
print("Nothing") print("Nothing")
case == 1: case == 1:
@ -505,7 +505,7 @@ value patterns would instead be written more explicitly as value constraints::
print("Good luck with that...") print("Good luck with that...")
# Additional literal patterns # Additional literal patterns
match value: match value:
case == True: case == True:
print("True or 1") print("True or 1")
case == False: case == False:
@ -696,7 +696,7 @@ sequence.
Subpatterns are mostly required to be closed patterns, but the parentheses may Subpatterns are mostly required to be closed patterns, but the parentheses may
be omitted for value constraints. Sequence elements may also be captured 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 Note: where :pep:`634` allows all the same syntactic flexibility as iterable
unpacking in assignment statements, this PEP restricts sequence patterns 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 The initially published version of this PEP proposed using the previously
unused ``?`` symbol as the prefix for equality constraints, and ``?is`` as the unused ``?`` symbol as the prefix for equality constraints, and ``?is`` as the
prefix for identity constraints. When reviewing the PEP, Steven D'Aprano 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. operators (``==`` and ``is``) instead.
There were a few concerns with ``==`` as a prefix that kept it from being 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 to use existing comparison operations rather than ``?`` and ``?is``, that
argument holds for this PEP as well. 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* 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 difference from all other parts of Python - the use of ``_`` in software
internationalisation and at the interactive prompt means that there isn't really 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. 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 ``__`` 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. various meanings of ``_`` in existing Python code.
This PEP also proposes adopting an implementation technique that limits This PEP also proposes adopting an implementation technique that limits
@ -1764,8 +1764,8 @@ a human reader as well: ``case {0: == 0}:``
Reference Implementation Reference Implementation
======================== ========================
A draft reference implementation for this PEP [3_] has been derived from Brandt A draft reference implementation for this PEP [3]_ has been derived from Brandt
Bucher's reference implementation for :pep:`634` [4_]. Bucher's reference implementation for :pep:`634` [4]_.
Relative to the text of this PEP, the draft reference implementation has not Relative to the text of this PEP, the draft reference implementation has not
yet complemented the special casing of several builtin and standard library yet complemented the special casing of several builtin and standard library
@ -1860,7 +1860,7 @@ References
https://gvanrossum.github.io/docs/PyPatternMatching.pdf https://gvanrossum.github.io/docs/PyPatternMatching.pdf
.. _Appendix A: .. _642-appendix-a:
Appendix A -- Full Grammar Appendix A -- Full Grammar
========================== ==========================
@ -1970,7 +1970,7 @@ Notation used beyond standard EBNF is as per :pep:`534`:
| '**' '{' [attrs_constraint_elements] '}' | '**' '{' [attrs_constraint_elements] '}'
.. _Appendix B: .. _642-appendix-b:
Appendix B: Summary of Abstract Syntax Tree changes 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 matchop = EqCheck | IdCheck
.. _Appendix C: .. _642-appendix-c:
Appendix C: Summary of changes relative to PEP 634 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. :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 Appendix D: History of changes to this proposal
=============================================== ===============================================
@ -2104,14 +2104,3 @@ Copyright
This document is placed in the public domain or under the This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive. 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: