Pattern Matching in Python

Remi Forax forax at univ-mlv.fr
Thu Feb 11 09:34:11 UTC 2021


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/


More information about the amber-spec-experts mailing list