Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636
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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On 2020-10-22 17:48, Guido van Rossum wrote:
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]'.
Is "syntax error" that the right term for it? Maybe it should be something different, a subclass of SyntaxError perhaps. [snip]
On Thu, Oct 22, 2020 at 10:42 AM MRAB <python@mrabarnett.plus.com> wrote:
[Guido]
- 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]'.
Is "syntax error" that the right term for it? Maybe it should be something different, a subclass of SyntaxError perhaps.
I think it is a SyntaxError. It is detected without needing to look at the symbol table, although it is not encoded in the grammar (we probably could, but it would be very tedious), so it's done during a later stage. We have many of these (e.g. 'return' outside function, also not encoded in the grammar). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Thu, Oct 22, 2020 at 09:48:54AM -0700, Guido van Rossum wrote:
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
Nice! (By coincidence, I had stumbled across them a few days ago, and hadn't realised that they were new. I hadn't looked at the dates and just assumed they were the original proposal.) I haven't read through them in detail but on broad skimming this looks very nice indeed. -- Steve
Woah, this is both exciting and scary. If adopted, it will be a major change to how Python programs are written. It seems a lot of work has been put into polishing the design. That's good because if we do this, will not be easy to fix things later if we made design errors. One of my first thoughts is this sounds similar to Clojure's "spec"[1]. Are the pattern matching PEP authors aware of it? I don't mean we need to copy what spec does (really, I'm not all that familiar with it). I do notice that spec patterns are not just used for case statement de-structuring. Maybe we should think about a future Python that would use similar patterns for those things too. I believe "spec" has been in use for a number of years and so the Clojure community has useful experience with the design. An example of something "spec" does and this proposal agrees on is the matching of mappings. I.e. that if there are additional key/value pairs, they don't cause the match to fail by default. That's important for loose coupling between systems. [1] https://clojure.org/about/spec
participants (4)
-
Guido van Rossum -
MRAB -
Neil Schemenauer -
Steven D'Aprano