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

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
pep-0622.rst
View File

@ -1,7 +1,5 @@
PEP: 622 PEP: 622
Title: Structural Pattern Matching Title: Structural Pattern Matching
Version: $Revision$
Last-Modified: $Date$
Author: Brandt Bucher <brandt@python.org>, Author: Brandt Bucher <brandt@python.org>,
Daniel F Moisset <dfmoisset@gmail.com>, Daniel F Moisset <dfmoisset@gmail.com>,
Tobias Kohn <kohnt@tobiaskohn.ch>, 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 Pattern matching as present in many other languages provides an
elegant solution to this problem. These range from statically compiled elegant solution to this problem. These range from statically compiled
functional languages like F# and Haskell, via mixed-paradigm languages 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 Ruby, and is under consideration for JavaScript. We are indebted to
these languages for guiding the way to Pythonic pattern matching, as these languages for guiding the way to Pythonic pattern matching, as
Python is indebted to so many other languages for many of its 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 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 must be defined in the same module. This will allow effective static
exhaustiveness checks, and together with dataclasses, will provide 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. <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 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 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 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`` We propose to add a special decorator class ``@sealed`` to the :py:mod:`typing`
module [6]_, that will have no effect at runtime, but will indicate to static 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 type checkers that all subclasses (direct and indirect) of this class should
be defined in the same module as the base class. 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. expression.
**Deep** parsers understand the complete syntax of Python. An example of this **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 tools is that they not only need to understand the syntax of the current version
of Python, but older versions of Python as well. 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 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 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. and upgrade them to be PEG compatible.
However, since this work would need to be done not only for the match statement, However, since this work would need to be done not only for the match statement,
@ -1322,7 +1320,7 @@ GitHub.
An `interactive playground An `interactive playground
<https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb>`_ <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 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 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 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 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 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)`` exactly if the pattern itself does not match. For instance, ``!(3 | 4)``
would match anything except ``3`` or ``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 is rarely useful (in languages which support it) or used as double negation
``!!`` to control variable scopes and prevent variable bindings (which does ``!!`` to control variable scopes and prevent variable bindings (which does
not apply to Python). It can also be simulated using guard conditions. not apply to Python). It can also be simulated using guard conditions.
@ -2195,44 +2193,17 @@ Version History
References References
========== ==========
.. [1] .. [1] https://github.com/gvanrossum/patma/blob/master/EXAMPLES.md
https://en.wikipedia.org/wiki/Pattern_matching
.. [2] .. _algebraic data types: https://en.wikipedia.org/wiki/Algebraic_data_type
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
.. [3] .. _documented evidence: https://dl.acm.org/doi/abs/10.1145/2480360.2384582
https://doc.rust-lang.org/reference/patterns.html .. _Black: https://black.readthedocs.io/en/stable/
.. _parso: https://github.com/davidhalter/parso
.. [4] .. _LibCST: https://github.com/Instagram/LibCST
https://docs.scala-lang.org/tour/pattern-matching.html .. _Binder: https://mybinder.org
.. _Jupyter: https://jupyter.org
.. [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
Appendix A -- Full Grammar Appendix A -- Full Grammar
@ -2250,7 +2221,7 @@ Other notation used beyond standard EBNF:
- ``SEP.RULE+`` is shorthand for ``RULE (SEP RULE)*`` - ``SEP.RULE+`` is shorthand for ``RULE (SEP RULE)*``
- ``!RULE`` is a negative lookahead assertion - ``!RULE`` is a negative lookahead assertion
:: .. code:: text
match_expr: match_expr:
| star_named_expression ',' star_named_expressions? | star_named_expression ',' star_named_expressions?