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 <m...@hotpy.org>: > > 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-le...@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/MJ4RQ3R5RGNJAZGRPZUSMFDM6QT26VR6/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/XZYI6BZX3KZUBCEKZNXF7MK6VXCYVSWV/ Code of Conduct: http://python.org/psf/codeofconduct/
