Pattern Matching in Python

[Gavin Bierman]

Yes, it’s interesting, and it’s a real improvement to the language. Tobias Kohn gave a very nice talk at SPLASH last year that’s worth watching. (It’s purely a coincidence that Cambridge seems to be a centre for pattern matching!)

https://www.youtube.com/watch?v=pxQZhL2ZHJU

The treatment of a pattern being an expression with named holes is very nice. Unfortunately, it’s really not so simple for us - we’d end up with something like : e instanceof new R(x, y). The `new` feels like clutter, doesn’t fit so well with subtyping, and we don’t allow local variable declarations like `x`, etc etc.

That said, we are aiming for a lot more (although I haven’t followed their discussions very closely). Once we get to defining instance patterns etc we have gone way beyond simple pattern matching of many languages.

Gavin

On 11 Feb 2021, at 09:34, Remi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>> wrote:

Hi all,
in the news, Python have been accepted the PEP 642, Pattern Matching in Python [1].

The accepted PEP is https://www.python.org/dev/peps/pep-0642/
And the rational is https://www.python.org/dev/peps/pep-0635/

Compared to us,
- bindings are visually like variables not a special keyword (a previous proposal was using 'as')
 so "case foo:" capture the value inside and store it into foo which is obviously very controversial
 (it's even worst because "foo" doesn't have to be a fresh variable).
 I'm happy that we have not chosen that way :)

- guards are introduced with "if", which i find more readable than & or &&.
 Using 'if' can be an issue for us because it means that we can not have a guard inside the instanceof pattern, but i am not sure this is really a problem.

- constants can be used directly
 I'm still on the fence about that, it's certainly confusing that case Point(0,0) means case Point(var x, var y) if x == 0 && y == 0 and not
 equals(new Point(0,0)) but i understand the arguments that people don't care because the result is identical and bloating the syntax to make the semantics extra clear
 like in C#, case Point(== 0, == 0) doesn't worth the fuss.

- no support for comma separated values because the syntax is too close to the tuple syntax,
 we have already chosen to support comma separated values but only at top level, not inside a nested pattern.
 They have introduced '|' for OR and it can be used as top level and inside nested patterns.
 Note: in Java, using ',' vs '|' in the syntax is not something new, we are using '|' for catch and not ','.
 So question, should we introduce a OR pattern ??

- no support for AND and NOT pattern,
 because as i said in an early mail, using tuples is already an implicit AND.

regards,
Rémi

[1] https://lwn.net/Articles/845480/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210211/203953bc/attachment-0001.htm>