After the pattern matching discussion died out, we discussed it with the Steering Council. Our discussion ended fairly positive, but there were a lot of problems with the text. We decided to abandon the old PEP 622 and break it up into three parts:
- PEP 634: Specification
- PEP 635: Motivation and Rationale
- PEP 636: Tutorial
This turned out to be more work than I had expected (basically we wrote all new material) but we've finally made it to a point where we can request feedback and submit the new version to the SC for approval.
While the text of the proposal is completely different, there aren't that many substantial changes:
- We changed walrus patterns ('v := p') to AS patterns ('p as v').
- We changed the method of comparison for literals None, False, True to use 'is' instead of '=='.
- SyntaxError if an irrefutable case[1] is followed by another case block.
- SyntaxError if an irrefutable pattern[1] occurs on the left of '|', e.g. 'x | [x]'.
- We dropped the `@sealed` decorator and everything aimed at static type checkers.
[1] An irrefutable pattern is one that never fails, notably a wildcard or a capture. An irrefutable case has an irrefutable pattern at the top and no guard. Irrefutability is defined recursively, since an '|' with an irrefutable pattern on either side is itself irrefutable, and so is an AS pattern with an irrefutable pattern before 'as'.
The following issues were specifically discussed with the SC:
- Concerns about side effects and undefined behavior. There's now some specific language about this in a few places (giving the compiler freedom to optimize), and a section "Side Effects and Undefined Behavior".
- Footgun if `case NAME:` is followed by another case. This is now a SyntaxError.
- Adding an 'else' clause. We decided not to add this; motivation in PEP 635.
- Alternative 'OR' symbol. Not changed; see PEP 635.
- Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which proposes '?' as a general assignment target. PEP 635 has some language against that idea.
- Alternative indentation schemes. We decided to stick with the original proposal; see PEP 635.
- Marking all capture variables with a sigil. We all agreed this was a bad idea; see PEP 635.