<story><title>PEP 622 – Structural Pattern Matching</title><url>https://www.python.org/dev/peps/pep-0622/</url></story><parent_chain><item><author>sillysaurusx</author><text>I have a visceral dislike of pattern matching. Lisp shows just how much people will abuse it in real-world production codebases. It becomes impossible to understand even simple logic without comments. I’d link to some examples, but I’m on mobile; suffice to say, pull up the emacs codebase and read through some of the more advanced modules like edebug.el. I’m not certain that one uses pattern matching, but it’s a perfect example of “this codebase cannot be understood without extensive study of language features.”&lt;p&gt;You may argue that I am simply not versed enough in pattern matching. “You should study harder.” I would argue that simplicity is worth striving for.&lt;p&gt;I hope this PEP never moves beyond draft.&lt;p&gt;It’s also shocking that most people here seem to be tacitly supporting this, or happy about it. Yes, it’s cool. Yes, it might simplify a few cases. But it will also give birth to codebases that &lt;i&gt;you can’t read&lt;/i&gt; in about, say, 5 years. And then you’ll have a bright line between people in the camp of “This is perfectly readable; it does so and so” and the rest of us regular humans that just want to build reliable systems.&lt;p&gt;And oh yes, it becomes impossible to backport to older python versions. Lovely.</text></item><item><author>justusw</author><text>Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts:&lt;p&gt;1) This is really close to Erlang&amp;#x2F;Elixir pattern matching and will make fail-early code much easier to write and easier to reason about.&lt;p&gt;2) match&amp;#x2F;case means double indentation, which I see they reasoned about later in the &amp;quot;Rejected ideas&amp;quot;. Might have a negative impact on readability.&lt;p&gt;3) Match is an already used word (as acknowledged by the authors), but I think this could have been a good case for actually using hard syntax. For me, perhaps because I&amp;#x27;m used to it, Elixir&amp;#x27;s &amp;quot;{a, b, c} = {:hello, &amp;quot;world&amp;quot;, 42}&amp;quot; just makes sense.&lt;p&gt;4) I hope there won&amp;#x27;t be a big flame-war debacle like with :=&lt;p&gt;5) And then finally there is the question of: &amp;quot;It&amp;#x27;s cool, but do we really need it? And will it increase the surprise factor?&amp;quot; And here I&amp;#x27;m not sure. And again, this was the concern with the new assignment expression. The assignment expression is legitimately useful in some use cases (no more silly while True), but it might reduce the learnability of Python. Python is often used as an introductory programming language, so the impact would be that curricula need to be adjust or beginner programmers will encounter some surprising code along the road.&lt;p&gt;I can&amp;#x27;t say this is a good or bad proposal, I want to see what other opinions are out there, and what kind of projects out there in the world would really benefit from syntax like this.</text></item></parent_chain><comment><author>kazinator</author><text>A good pattern matching library in Lisp makes code a heck of a lot more readable.&lt;p&gt;Firstly, even basic list destructuring with destructuring-bind is an improvement over a soup of car&amp;#x2F;cadar&amp;#x2F;caddr&amp;#x2F;.&lt;p&gt;Suppose we are in a compiler and would like to look for expressions of he pattern:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   (not (and (not e0) (not e1) (not e2) ...))
&lt;/code&gt;&lt;/pre&gt;
in order to apply DeMorgan&amp;#x27;s and rewrite them to&lt;p&gt;&lt;pre&gt;&lt;code&gt;   (or e0 e1 ...)
&lt;/code&gt;&lt;/pre&gt;
I would rather have a nice pattern matching case like this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   (match-case expr
      ...
      ((not (and @(zeromore not @term)))
       `(or ,term))  ;; rewrite done!
      ...)
&lt;/code&gt;&lt;/pre&gt;
than:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   (if (and (consp expr)
            (eq (car expr) &amp;#x27;not))
            (consp (cdr expr))
            (consp (cadr (expr)))
            (null (cddr expr))
            (eq (caadr (expr)) &amp;#x27;and)
            (eq (cadr expr) 
      ... ad nauseum)
&lt;/code&gt;&lt;/pre&gt;
Even if a fail-safe version of &lt;i&gt;destructuring-bind&lt;/i&gt; is used to validate and get the basic shape, it&amp;#x27;s still tedious:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    (destructuring-case expr
         ...
       ((a (b c))
        (if (and (eq a &amp;#x27;and)
                 (eq b &amp;#x27;not))
           ... now check that c is a list of nothing but (not x) forms
           )))

&lt;/code&gt;&lt;/pre&gt;
I don&amp;#x27;t have a pattern matcher in TXR Lisp. That is such a problem that it&amp;#x27;s holding up compiler work! Because having to write grotty code just to recognize patterns and pull out pieces is demotivating. It&amp;#x27;s not just demotivating as in &amp;quot;I don&amp;#x27;t feel like doing the gruntwork&amp;quot;, but demotivating as in, &amp;quot;I don&amp;#x27;t want to saddle my project with the technical debt caused by cranking out that kind of code&amp;quot;, which will have to be rewritten into  pattern matching later.</text></comment>
<story><title>PEP 622 – Structural Pattern Matching</title><url>https://www.python.org/dev/peps/pep-0622/</url></story><parent_chain><item><author>sillysaurusx</author><text>I have a visceral dislike of pattern matching. Lisp shows just how much people will abuse it in real-world production codebases. It becomes impossible to understand even simple logic without comments. I’d link to some examples, but I’m on mobile; suffice to say, pull up the emacs codebase and read through some of the more advanced modules like edebug.el. I’m not certain that one uses pattern matching, but it’s a perfect example of “this codebase cannot be understood without extensive study of language features.”&lt;p&gt;You may argue that I am simply not versed enough in pattern matching. “You should study harder.” I would argue that simplicity is worth striving for.&lt;p&gt;I hope this PEP never moves beyond draft.&lt;p&gt;It’s also shocking that most people here seem to be tacitly supporting this, or happy about it. Yes, it’s cool. Yes, it might simplify a few cases. But it will also give birth to codebases that &lt;i&gt;you can’t read&lt;/i&gt; in about, say, 5 years. And then you’ll have a bright line between people in the camp of “This is perfectly readable; it does so and so” and the rest of us regular humans that just want to build reliable systems.&lt;p&gt;And oh yes, it becomes impossible to backport to older python versions. Lovely.</text></item><item><author>justusw</author><text>Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts:&lt;p&gt;1) This is really close to Erlang&amp;#x2F;Elixir pattern matching and will make fail-early code much easier to write and easier to reason about.&lt;p&gt;2) match&amp;#x2F;case means double indentation, which I see they reasoned about later in the &amp;quot;Rejected ideas&amp;quot;. Might have a negative impact on readability.&lt;p&gt;3) Match is an already used word (as acknowledged by the authors), but I think this could have been a good case for actually using hard syntax. For me, perhaps because I&amp;#x27;m used to it, Elixir&amp;#x27;s &amp;quot;{a, b, c} = {:hello, &amp;quot;world&amp;quot;, 42}&amp;quot; just makes sense.&lt;p&gt;4) I hope there won&amp;#x27;t be a big flame-war debacle like with :=&lt;p&gt;5) And then finally there is the question of: &amp;quot;It&amp;#x27;s cool, but do we really need it? And will it increase the surprise factor?&amp;quot; And here I&amp;#x27;m not sure. And again, this was the concern with the new assignment expression. The assignment expression is legitimately useful in some use cases (no more silly while True), but it might reduce the learnability of Python. Python is often used as an introductory programming language, so the impact would be that curricula need to be adjust or beginner programmers will encounter some surprising code along the road.&lt;p&gt;I can&amp;#x27;t say this is a good or bad proposal, I want to see what other opinions are out there, and what kind of projects out there in the world would really benefit from syntax like this.</text></item></parent_chain><comment><author>logicchains</author><text>Apart from Clojure, lisps generally do not support destructuring pattern matching on an object&amp;#x2F;dict.</text></comment>