Skip to content

PEP 642: Fix footnotes #2718

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 20, 2022
Merged

PEP 642: Fix footnotes #2718

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7ba7a7c
PEP 642: Fix footnotes
hugovk Jul 18, 2022
c5a4432
PEP 642: Remove redudant emacs metadata
hugovk Jul 18, 2022
bc84258
PEP 642: Use unambiguous name to remove duplicate label warning
hugovk Jul 18, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 16 additions & 27 deletions pep-0642.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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:
Expand All @@ -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:
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -1860,7 +1860,7 @@ References
https://gvanrossum.github.io/docs/PyPatternMatching.pdf


.. _Appendix A:
.. _642-appendix-a:

Appendix A -- Full Grammar
==========================
Expand Down Expand Up @@ -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
===================================================
Expand Down Expand Up @@ -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
==================================================
Expand Down Expand Up @@ -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
===============================================
Expand Down Expand Up @@ -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: