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 so
