I'm late, but I still wanted to add that I share some of the criticism that Mark has brought up. I'm in love with Rust's pattern matching, so I feel like I'm not against pattern matching generally. However I feel like while the PEP is well written, there are some things that it does not tackle: - Sum Types aka Tagged Unions are what makes pattern matching necessary. I think we should rather have a discussion about inclusion of Sum Types. - Match in Python would not be an expression, which would be the most useful application in Python IMO. - It's quite a lot of additional syntax and complexity for a feature that does not enable something fundamental. I feel like in my 10 years of Python I have rarely wished to have pattern matching. I would have wished to have Sum Types, because that would have enabled me to structure my code in a more readable way. Python enums are unfortunately not as useful and dataclasses/namedtuples don't feel right either. I also think that using isinstance is usually a sign of code smell and I'm trying to avoid it whenever I can (except for `assert isinstance`). Many of the examples in PEP 635 (Motivation & Rationale) I would consider to be a bit smelly. The examples about tree traversal are useful, but it's exactly where I wished I had Sum Types to make my code more readable. Pattern matching wouldn't even be necessary in these cases, because something like Rust's `if let ...` would be good enough. Since I'm obviously quite late for this discussion, I can understand if this comment is ignored. I also understand that not everyone can be happy with the final decision about pattern matching. I just think that this is not the best addition. Thanks anyway to the people working on this and continue to have a civil discussion. Happy New Year & Stay Safe! ~ Dave Am Fr., 30. Okt. 2020 um 15:43 Uhr schrieb Mark Shannon :
Hi everyone,
PEP 634/5/6 presents a possible implementation of pattern matching for Python.
Much of the discussion around PEP 634, and PEP 622 before it, seems to imply that PEP 634 is synonymous with pattern matching; that if you reject PEP 634 then you are rejecting pattern matching.
That simply isn't true.
Can we discuss whether we want pattern matching in Python and the broader semantics first, before dealing with low level details?
Do we want pattern matching in Python at all? ---------------------------------------------
Pattern matching works really well in statically typed, functional languages.
The lack of mutability, constrained scope and the ability of the compiler to distinguish let variables from constants means that pattern matching code has fewer errors, and can be compiled efficiently.
Pattern matching works less well in dynamically-typed, functional languages and statically-typed, procedural languages. Nevertheless, it works well enough for it to be a popular feature in both erlang and rust.
In dynamically-typed, procedural languages, however, it is not clear (at least not to me) that it works well enough to be worthwhile.
That is not say that pattern matching could never be of value in Python, but PEP 635 fails to demonstrate that it can (although it does a better job than PEP 622).
Should match be an expression, or a statement? ----------------------------------------------
Do we want a fancy switch statement, or a powerful expression? Expressions have the advantage of not leaking (like comprehensions in Python 3), but statements are easier to work with.
Can pattern matching make it clear what is assigned? ----------------------------------------------------
Embedding the variables to be assigned into a pattern, makes the pattern concise, but requires discarding normal Python syntax and inventing a new sub-language. Could we make patterns fit Python better?
Is it possible to make assignment to variables clear, and unambiguous, and allow the use of symbolic constants at the same time? I think it is, but PEP 634 fails to do this.
How should pattern matching be integrated with the object model? ----------------------------------------------------------------
What special method(s) should be added? How and when should they be called? PEP 634 largely disregards the object model, meaning it has many special cases, and is inefficient.
The semantics must be well defined. -----------------------------------
Language extensions PEPs should define the semantics of those extensions. For example, PEP 343 and PEP 380 both did. https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement https://www.python.org/dev/peps/pep-0380/#formal-semantics
PEP 634 just waves its hands and talks about undefined behavior, which horrifies me.
In summary, I would ask anyone who wants pattern matching adding to Python, to not support PEP 634. PEP 634 just isn't a good fit for Python, and we deserve something better.
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MJ4RQ3R5... Code of Conduct: http://python.org/psf/codeofconduct/