PEP 634, PEP 635, PEP 636: Create the structure for the PEP 622 split #1598

gvanrossum · 2020-09-12T17:36:55Z

Also change PEP 622 status to "Superseded", and mark that as "Superseded-By: 634".

We won't land this until we have a decent amount of content in each of the three new PEPs (but we'll still iterate after that).

…o the new style

brandtbucher · 2020-09-12T19:56:19Z

pep-0634.rst

+TODO: rewrite the ``patterns`` rule to be easier to follow -- why
+isn't it just ``','.value_pattern+ [',']``?  Also, ``value_pattern``
+is a confusing name, since it is unrelated to "constant value


It's this way because you can't have a starred pattern without a comma.

Hm, then I still propose to give it a better name.

Hm. elts_pattern and elt_pattern instead of values_pattern and value_pattern? items_pattern is already taken by mappings.

Let me ponder that, I'm not crazy about the abbreviated name. Maybe multi_pattern? Also, could we define the name open_pattern to mean multi_pattern | pattern? It somewhat nicely contrasts with closed_pattern. (Although then apparently walrus and OR patterns are neither closed nor open. :-)

pep-0634.rst

pep-0636.rst

pep-0634.rst

brandtbucher · 2020-09-12T21:20:19Z

pep-0634.rst

+TODO: Do we use "the subject matches the pattern" or "the pattern
+matches the subject"?


Good question. The latter feels right to me, since our match protocol uses "smart" patterns and "dumb" subjects.

pep-0634.rst

brandtbucher · 2020-09-12T22:53:13Z

How do you feel about reserving the "magical" optimizations like caching and decision trees for -OO mode? I think it will appease users who want well-defined behavior, but also allow significant speedup for those who desire it. It will probably also make life easier for implementers, since users are opting-in and have less excuses for relying on implementation details.

The SC seemed responsive to the idea when I brought it up during our meeting. I've thought about it more and think it's a good compromise (and could maybe even open the door to more aggressive optimizations elsewhere).

brandtbucher · 2020-09-12T23:08:06Z

Stopping for now. I'll be back at it later.

pep-0634.rst

brandtbucher · 2020-09-13T00:25:10Z

pep-0634.rst

+interpreter may cache this value in a similar manner as described for
+constant value patterns.
+
+TODO: Do we have left-to-right semantics here?


Yes. Actually, I think everything is left-to-right except walrus patterns (which in my mind is a decent argument for switching to as syntax).

I'll remove this line.

gvanrossum · 2020-09-13T00:26:07Z

How do you feel about reserving the "magical" optimizations like caching and decision trees for -OO mode? I think it will appease users who want well-defined behavior, but also allow significant speedup for those who desire it. It will probably also make life easier for implementers, since users are opting-in and have less excuses for relying on implementation details.

The SC seemed responsive to the idea when I brought it up during our meeting. I've thought about it more and think it's a good compromise (and could maybe even open the door to more aggressive optimizations elsewhere).

Hm, I consider -O and -OO failed experiments, and would rather not invoke them. There are often good reasons why people can't use them, especially since they are global -- a single module that abuses assert to inspects docstrings means you can't use them.

Also tweak remark about scope

Add a TODO, remove another

- Remove redundant text about exceptions - Side effects becomes a toplevel section - Reflow stdlib section

dmoisset · 2020-09-24T23:07:20Z

@doisset -- Looks like you didn't get to all my feedback from the first round yet?

No... I may have some time for this tomorrow an on the weekend, and to get a first draft of the rest.

gvanrossum

I really like the new text you've added! Just two small wording nits.

gvanrossum · 2020-09-26T19:46:16Z

pep-0635.rst

+Python's establish structural paradigm, leading to additional syntactic
+rules:
+
+- *Do no indent case clauses.*


I've always found the conventional style in "Rejected ideas" sections in PEPs confusing. By tradition, each rejected idea has a heading that says "Do X" or "Do not do X" (followed by text that explains the idea and then argues why it is rejected), where the sense of the heading is what the PEP doesn't do. The confusion arises when you see such a heading out of context, e.g. after searching the document.

My proposed alternative to this style is to make the headings more neutral. In this case I would perhaps write "unindented case clauses", and for the next section I'd write "Putting the expression on a line after match" (there are linguistic terms for these different forms but I've never learned them :-).

pep-0635.rst

gvanrossum · 2020-09-26T20:29:07Z

@Tobias-Kohn See my last comments.

gvanrossum

I am going to apply my remaining suggestions.

pep-0635.rst

None of these should be controversial.

gvanrossum

@Tobias-Kohn
Excellent progress! Here are some nits.

You may also want to go over past comments. There is no great way to do that in GitHub, but scrolling down and looking over every comment that hasn't been resolved yet usually works. Then mark as resolved every comment that has either been acted upon or no longer requires action.

gvanrossum · 2020-09-30T23:51:09Z

pep-0635.rst

@@ -294,6 +294,12 @@ that a subject might safely fail to match a specific pattern at any point
 pattern should avoid side effects wherever possible, including binding
 values to attributes or subscripts.

+A corner stone of pattern matching is the possibility of arbitrarily


Suggested change

A corner stone of pattern matching is the possibility of arbitrarily

A cornerstone of pattern matching is the possibility of arbitrarily

gvanrossum · 2020-09-30T23:54:22Z

pep-0635.rst

+section above).  At any level of the nesting, several patterns can be
+combined to form alternatives.


So, hm, what exactly is "combining patterns"? I know nesting: C(P1, P2) is a class pattern that has two subpatterns P1 and P2 nested inside it. But what's "combining to form alternatives"? Is this just a reference to P1 | P2? To me that's still a nested pattern -- it's an OR pattern with two subpatterns, P1 and P2. Maybe we can simplify things by dropping the whole "combining" concept altogether?

gvanrossum · 2020-10-01T00:08:17Z

pep-0635.rst

+hand, builds a generalized concept of iterable unpacking.  Binding values
+extracted from a data structure is at the very core of the concept.  Explicit
+markers for capture patterns would thus betray the objective of the proposed
+pattern matching syntax.


Maybe we could clarify this a bit more by pointing out that we expect capture patterns to be (significantly) more common than constant value patterns? (So if we were to have to mark either captures or values, we'd have to mark values and keep captures "plain".)

gvanrossum · 2020-10-01T03:00:05Z

pep-0635.rst

@@ -475,13 +495,56 @@ patterns impossible.
 Group Patterns
 ~~~~~~~~~~~~~~

+Allowing users to explicitly specify the grouping is particularly helpful
+in case of alternatives or sequence patterns written as tuples.


Suggested change

in case of alternatives or sequence patterns written as tuples.

in case of OR patterns.

Dropping sequence patterns because (P1, P2) is not a group -- it's a (closed) sequence pattern. The parentheses are a syntactic part of the sequence pattern (unlike tuple expressions).

gvanrossum · 2020-10-01T03:42:43Z

pep-0635.rst

+Moreover, the sequence pattern only matches a narrow set of possible
+subjects, whereas iterable unpacking can be applied to any iterable.


Hm, "a narrow set of possible subjects" sounds a bit too narrow. How about "a carefully selected set"?

gvanrossum · 2020-10-01T03:46:19Z

pep-0635.rst

+
+- As in iterable unpacking, we do not distinguish between 'tuple' and
+  'list' notation.  ``[a, b, c]``, ``(a, b, c)`` and ``a, b, c`` are all
+  equivalent.


Maybe add something like "While this means we have a redundant notation and checking specifically for lists or tuples requires more effort (e.g. case list([a, b, c])), we want to match user-defined sequence types as well.

Or say something about mimicking (sequence) unpacking is much as we can.

gvanrossum · 2020-10-01T03:53:51Z

pep-0635.rst

+- The sequence pattern does *not* iterate through an iterable subject.  All
+  elements are accessed through subscripting and slicing, and the subject must
+  be an instance of ``collections.abc.Sequence`` (including, in particular,
+  lists and tuples, but excluding strings and bytes).


Maybe also mention that this specifically excludes sets (whose order is randomized, making it hard to imagine use cases for pattern matching that aren't footguns) and dictionaries (where we'd lose the keys, and for which we already have a separate pattern).

gvanrossum · 2020-10-01T03:54:39Z

pep-0635.rst

+  lists and tuples, but excluding strings and bytes).
+
+A sequence pattern cannot just iterate through any iterable object.  The
+consumation of elements from the iteration would have to be undone if the


Suggested change

consumation of elements from the iteration would have to be undone if the

consumption of elements from the iteration would have to be undone if the

gvanrossum · 2020-10-01T03:57:06Z

pep-0635.rst

+cases for strings and bytes seems different enough from that of tuples and
+lists to warrant a clear distinction.  Strings and bytes are therefore not
+matched by a sequence pattern, limiting the sequence pattern to a very
+narrow and specific understanding of 'sequence'.


Maybe mention that this understanding is actually more intuitive? It's a common footgun and we get regular complaints about it, but in other contexts, sequence operations on strings are so common that even Python 4 won't be able to fix this.

gvanrossum · 2020-10-01T03:59:04Z

pep-0635.rst

+===================
+
+Pattern matching emerged in the late 1970s in the form of tuple unpacking
+and as a means to handle recursive data structures such as linked lists or


Hm... I tried to come up with a reasonable example, but it came rather short, so I think this may not be such a great idea.

gvanrossum · 2020-10-02T00:03:39Z

This PR has become unmanageable. :-(

I am landing it as-is (with strong notes at the top of each that these drafts are for the authors' convenience) and then see if I can get the pep-622-split branch to become the new starting point.

X

Create the structure for the PEP 622 split

f64f069

the-knights-who-say-ni added the CLA signed label Sep 12, 2020

gvanrossum mentioned this pull request Sep 12, 2020

[WIP] Create the structure for the PEP 622 split #1597

Closed

gvanrossum marked this pull request as draft September 12, 2020 17:37

Checkpoint -- converted up to and including Constant Value Patterns t…

b3da517

…o the new style

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0634.rst Outdated Show resolved Hide resolved

gvanrossum added 2 commits September 12, 2020 13:11

Target->subject; started on sequence and mapping

8220a48

Always use match statement

aaa3180

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0636.rst Show resolved Hide resolved

gvanrossum and others added 3 commits September 12, 2020 13:31

Finish mapping pattern, some tweaks

9b46594

PEP 636: Sponsored by GvR

5879ee5

Remove bool from "match self" examples

f3b262c

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0634.rst Outdated Show resolved Hide resolved

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0634.rst Outdated Show resolved Hide resolved

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0634.rst Outdated Show resolved Hide resolved

brandtbucher added 2 commits September 12, 2020 15:38

Clean up the simplified grammar

520a68f

Change float example to use bool

15fdb0f

brandtbucher added 3 commits September 12, 2020 16:04

Patterns match subjects

4295a58

Mapping patterns use get()

1518f84

Clean up TODOs

8c63baf

brandtbucher reviewed Sep 12, 2020

View reviewed changes

pep-0634.rst Outdated Show resolved Hide resolved

Allow "_" in class patterns.

846df5b

brandtbucher reviewed Sep 13, 2020

View reviewed changes

Remove comment

cfd9e74

Say 'the pattern matches the subject', not vice versa

944bda9

gvanrossum added 8 commits September 23, 2020 15:28

Modernize walrus pattern

68c7226

Also tweak remark about scope

Fix markup errors

a03c44a

Modernize description of guards

f694459

Move guards, walrus and OR to the top

d342c4b

Make stdlib section toplevel

0b1c43c

Add a TODO, remove another

Deal with a few more TODOs

71ce943

- Remove redundant text about exceptions - Side effects becomes a toplevel section - Reflow stdlib section

Add main TODOs

1a313d2

Add TODO: disallow open pattern w. guard

8b3f98c

gvanrossum and others added 2 commits September 25, 2020 08:59

Twiddle TODOs

4d775de

Rewrote sections on match statement rationale

502f0a9

gvanrossum commented Sep 26, 2020

View reviewed changes

Cleaning up pep-0635

51bd141

gvanrossum commented Sep 29, 2020

View reviewed changes

pep-0635.rst Outdated Show resolved Hide resolved

gvanrossum and others added 3 commits September 29, 2020 11:51

Apply various tweaks I proposed

8cf80e7

None of these should be controversial.

Added sequence patterns

cdab17d

More target->subject

d6fdb24

gvanrossum commented Oct 1, 2020

View reviewed changes

Tobias-Kohn and others added 5 commits October 1, 2020 12:17

Added some more patterns and examples

a0be300

Resolve discrepancies between syntax sections and Appending A

402e2df

Add notes about PEP incompleteness

698164c

Remove trailing whitespace and fix British spelling

71f3c21

Fix more trailing whitespace

6f18499

gvanrossum marked this pull request as ready for review October 2, 2020 00:03

gvanrossum merged commit 0c87b5a into python:master Oct 2, 2020

gvanrossum deleted the pep-622-split branch October 2, 2020 00:06

dmoisset added a commit to dmoisset/peps that referenced this pull request Oct 16, 2020

Applied most of the pending feedback from python#1598

bcc533c

X

mnm678 pushed a commit to mnm678/peps that referenced this pull request Oct 22, 2020

PEP 634, PEP 635, PEP 636: Split PEP 622 in three parts (python#1598)

fb7fab5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PEP 634, PEP 635, PEP 636: Create the structure for the PEP 622 split #1598

PEP 634, PEP 635, PEP 636: Create the structure for the PEP 622 split #1598

gvanrossum commented Sep 12, 2020 •

edited

Loading

brandtbucher Sep 12, 2020

gvanrossum Sep 12, 2020

brandtbucher Sep 12, 2020

gvanrossum Sep 12, 2020

brandtbucher Sep 12, 2020 •

edited

Loading

brandtbucher commented Sep 12, 2020

brandtbucher commented Sep 12, 2020

brandtbucher Sep 13, 2020 •

edited

Loading

gvanrossum commented Sep 13, 2020

dmoisset commented Sep 24, 2020

gvanrossum left a comment

gvanrossum Sep 26, 2020

gvanrossum commented Sep 26, 2020

gvanrossum left a comment

gvanrossum left a comment

gvanrossum Sep 30, 2020

gvanrossum Sep 30, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum Oct 1, 2020

gvanrossum commented Oct 2, 2020

		TODO: Do we use "the subject matches the pattern" or "the pattern
		matches the subject"?

	A corner stone of pattern matching is the possibility of arbitrarily
	A cornerstone of pattern matching is the possibility of arbitrarily

		section above). At any level of the nesting, several patterns can be
		combined to form alternatives.

	in case of alternatives or sequence patterns written as tuples.
	in case of OR patterns.

		Moreover, the sequence pattern only matches a narrow set of possible
		subjects, whereas iterable unpacking can be applied to any iterable.

	consumation of elements from the iteration would have to be undone if the
	consumption of elements from the iteration would have to be undone if the

PEP 634, PEP 635, PEP 636: Create the structure for the PEP 622 split #1598

PEP 634, PEP 635, PEP 636: Create the structure for the PEP 622 split #1598

Conversation

gvanrossum commented Sep 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brandtbucher Sep 12, 2020 • edited Loading

Choose a reason for hiding this comment

brandtbucher commented Sep 12, 2020

brandtbucher commented Sep 12, 2020

brandtbucher Sep 13, 2020 • edited Loading

Choose a reason for hiding this comment

gvanrossum commented Sep 13, 2020

dmoisset commented Sep 24, 2020

gvanrossum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gvanrossum commented Sep 26, 2020

gvanrossum left a comment

Choose a reason for hiding this comment

gvanrossum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gvanrossum commented Oct 2, 2020

gvanrossum commented Sep 12, 2020 •

edited

Loading

brandtbucher Sep 12, 2020 •

edited

Loading

brandtbucher Sep 13, 2020 •

edited

Loading