PEP 622: Resolve unreferenced footnotes (#3251)

This commit is contained in:
Adam Turner 2023-08-02 18:30:19 +01:00 committed by GitHub
parent 8e978d4ac3
commit 65e05fd401
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 50 deletions

View File

@ -1,7 +1,5 @@
PEP: 622
Title: Structural Pattern Matching
Version: $Revision$
Last-Modified: $Date$
Author: Brandt Bucher <brandt@python.org>,
Daniel F Moisset <dfmoisset@gmail.com>,
Tobias Kohn <kohnt@tobiaskohn.ch>,
@ -198,7 +196,7 @@ required component values, which may be nested several objects deep.
Pattern matching as present in many other languages provides an
elegant solution to this problem. These range from statically compiled
functional languages like F# and Haskell, via mixed-paradigm languages
like Scala [4]_ and Rust [3]_, to dynamic languages like Elixir and
like Scala_ and Rust_, to dynamic languages like Elixir and
Ruby, and is under consideration for JavaScript. We are indebted to
these languages for guiding the way to Pythonic pattern matching, as
Python is indebted to so many other languages for many of its
@ -326,7 +324,7 @@ a ``@typing.sealed`` class decorator that will be a no-op at runtime
but will indicate to static tools that all sub-classes of this class
must be defined in the same module. This will allow effective static
exhaustiveness checks, and together with dataclasses, will provide
basic support for algebraic data types [2]_. See the `static checkers
basic support for `algebraic data types`_. See the `static checkers
<static checkers specification_>`_ section for more details.
@ -1071,10 +1069,10 @@ Quite often it is desirable to apply exhaustiveness to a set of classes without
defining ad-hoc union types, which is itself fragile if a class is missing in
the union definition. A design pattern where a group of record-like classes is
combined into a union is popular in other languages that support pattern
matching and is known under a name of algebraic data types [2]_.
matching and is known under a name of `algebraic data types`_.
We propose to add a special decorator class ``@sealed`` to the ``typing``
module [6]_, that will have no effect at runtime, but will indicate to static
We propose to add a special decorator class ``@sealed`` to the :py:mod:`typing`
module, that will have no effect at runtime, but will indicate to static
type checkers that all subclasses (direct and indirect) of this class should
be defined in the same module as the base class.
@ -1293,7 +1291,7 @@ easy, just an addition to a table, or perhaps modification of a regular
expression.
**Deep** parsers understand the complete syntax of Python. An example of this
is the auto-formatter Black [9]_. A particular requirement with these kinds of
is the auto-formatter Black_. A particular requirement with these kinds of
tools is that they not only need to understand the syntax of the current version
of Python, but older versions of Python as well.
@ -1304,7 +1302,7 @@ time with the new syntax.
It has been noted that a number of these third-party tools leverage common parsing
libraries (Black for example uses a fork of the lib2to3 parser). It may be helpful
to identify widely used parsing libraries (such as parso [10]_ and libCST [11]_)
to identify widely used parsing libraries (such as parso_ and libCST_)
and upgrade them to be PEG compatible.
However, since this work would need to be done not only for the match statement,
@ -1322,7 +1320,7 @@ GitHub.
An `interactive playground
<https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb>`_
based on the above implementation was created using Binder [12]_ and Jupyter [13]_.
based on the above implementation was created using Binder_ and Jupyter_.
Example Code
============
@ -1348,7 +1346,7 @@ believe the proposed syntax significantly improves readability for a wide
range of code patterns, by allowing to express *what* one wants to do, rather
than *how* to do it. We hope the few real code snippets we included in the PEP
above illustrate this comparison well enough. For more real code examples
and their translations see Ref. [7]_.
and their translations see Ref. [1]_.
Don't do this, use existing method dispatching mechanisms
@ -1692,7 +1690,7 @@ A negation of a match pattern using the operator ``!`` as a prefix would match
exactly if the pattern itself does not match. For instance, ``!(3 | 4)``
would match anything except ``3`` or ``4``.
This was rejected because there is documented evidence [8]_ that this feature
This was rejected because there is `documented evidence`_ that this feature
is rarely useful (in languages which support it) or used as double negation
``!!`` to control variable scopes and prevent variable bindings (which does
not apply to Python). It can also be simulated using guard conditions.
@ -2195,44 +2193,17 @@ Version History
References
==========
.. [1]
https://en.wikipedia.org/wiki/Pattern_matching
.. [1] https://github.com/gvanrossum/patma/blob/master/EXAMPLES.md
.. [2]
https://en.wikipedia.org/wiki/Algebraic_data_type
.. [3]
https://doc.rust-lang.org/reference/patterns.html
.. [4]
https://docs.scala-lang.org/tour/pattern-matching.html
.. [5]
https://docs.python.org/3/library/dataclasses.html
.. [6]
https://docs.python.org/3/library/typing.html
.. [7]
https://github.com/gvanrossum/patma/blob/master/EXAMPLES.md
.. [8]
https://dl.acm.org/doi/abs/10.1145/2480360.2384582
.. [9]
https://black.readthedocs.io/en/stable/
.. [10]
https://github.com/davidhalter/parso
.. [11]
https://github.com/Instagram/LibCST
.. [12]
https://mybinder.org
.. [13]
https://jupyter.org
.. _algebraic data types: https://en.wikipedia.org/wiki/Algebraic_data_type
.. _Rust: https://doc.rust-lang.org/reference/patterns.html
.. _Scala: https://docs.scala-lang.org/tour/pattern-matching.html
.. _documented evidence: https://dl.acm.org/doi/abs/10.1145/2480360.2384582
.. _Black: https://black.readthedocs.io/en/stable/
.. _parso: https://github.com/davidhalter/parso
.. _LibCST: https://github.com/Instagram/LibCST
.. _Binder: https://mybinder.org
.. _Jupyter: https://jupyter.org
Appendix A -- Full Grammar
@ -2250,7 +2221,7 @@ Other notation used beyond standard EBNF:
- ``SEP.RULE+`` is shorthand for ``RULE (SEP RULE)*``
- ``!RULE`` is a negative lookahead assertion
::
.. code:: text
match_expr:
| star_named_expression ',' star_named_expressions?