Some comments: * What you call "Constant Value Patterns" can really refer to any local or non-local name, regardless of how complex the referred object is, right? Also, __eq__ is called in that case, not __match__? * If I understand correctly, these: case b"": print("it's an empty bytes object") and case bytes(): print("it's a bytes object") have entirely different meanings. Am I right? This sounds like I have to switch contexts when reading code, based on whether I am reading regular code or a match clause, given that semantics are quite different. Instead, it seems like the latter would be more explicitly spelled out as, e.g.: case instanceof(bytes): print("it's a bytes object") * The acronym "ADT" is never defined. * """If there are more positional items than the length of __match_args__, an ImpossibleMatchError is raised.""" What if there are less positional items than ``len(__match_args__)``? Can the match succeed rather than raise ImpossibleMatchError? This seems potentially error-prone. Overall, my main concern with this PEP is that the matching semantics and pragmatics are different from everything else in the language. When reading and understanding a match clause, there's a cognitive overhead because suddently `Point(x, 0)` means something entirely different (it doesn't call Point.__new__, it doesn't lookup `x` in the locals or globals...). Obviously, there are cases where this is worthwhile, but still. It may be useful to think about different notations for these new things, rather than re-use the object construction notation. For example: case Point with (x, y): print(f"Got a point with x={x}, y={y}") or: case Point @ (x, y): print(f"Got a point with x={x}, y={y}") (yes, "@" is the matrix multiplication operator... but it's probably much less likely to appear in common code and especially with a class object at the left) Regards Antoine. On Tue, 23 Jun 2020 09:01:11 -0700 Guido van Rossum <guido@python.org> wrote:
I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin.
Many people have thought about extending Python with a form of pattern matching similar to that found in Scala, Rust, F#, Haskell and other languages with a functional flavor. The topic has come up regularly on python-ideas (most recently yesterday :-).
I'll mostly let the PEP speak for itself: - Published: https://www.python.org/dev/peps/pep-0622/ (*) - Source: https://github.com/python/peps/blob/master/pep-0622.rst
(*) The published version will hopefully be available soon.
I want to clarify that the design space for such a match statement is enormous. For many key decisions the authors have clashed, in some cases we have gone back and forth several times, and a few uncomfortable compromises were struck. It is quite possible that some major design decisions will have to be revisited before this PEP can be accepted. Nevertheless, we're happy with the current proposal, and we have provided ample discussion in the PEP under the headings of Rejected Ideas and Deferred Ideas. Please read those before proposing changes!