6 ms·

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: 1) This is really c

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: 1) This is really close to Erlang/Elixir pattern matching and will make fail-early code much easier to write and easier to reason about. 2) match/case means double indentation, which I see they reasoned about later in the "Rejected ideas". Might have a negative impact on readability. 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'm used to it, Elixir's "{a, b, c} = {:hello, "world", 42}" just makes sense. 4) I hope there won't be a big flame-war debacle like with := 5) And then finally there is the question of: "It's cool, but do we really need it? And will it increase the surprise factor?" And here I'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. I can'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.

arusahni 6y ago
What's interesting here is this is gated on the new parser from PEP-617 [1]. Based on mailing list discussions [2], and the PEP, the use of `match` will be context-sensitive, so it shouldn't be as disruptive of an introduction as `async`. 1: https://www.python.org/dev/peps/pep-617/ https://www.python.org/dev/peps/pep-617/ 2: https://lwn.net/Articles/816922/ https://lwn.net/Articles/816922/
- herman_toothrot 6y ago
  missed a zero: https://www.python.org/dev/peps/pep-0617/ https://www.python.org/dev/peps/pep-0617/
wool_gather 6y ago
One difference I noticed from Elixir was this: > While matching against each case clause, a name may be bound at most once, having two name patterns with coinciding names is an error. match data: case [x, x]: # Error! ... Which is a bit of a shame. This comes in handy in Elixir to say "the same value must appear at these places in the collection". I.e. for a Python tuple pattern `(x, y, x)`, `(3, 4, 5)` would not match but `(3, 4, 3)` would. Overall, though, I think this will be a great addition to Python. Pattern matching is generally a huge boost for expressiveness and readability, in my opinion.
- Tyr42 6y ago
  Which equality will you use if it's not numbers, but something more complicated. What if `(x, y, x)` is matched against some `(a, b, c)` where `a == c`, but not `a is c`? If yes, and you mutate `x` in the body, does it mutate `a` or does it mutate `c`? I think at least making it an error now can leave it open to defining it later.
  - wool_gather 6y ago
    There's certainly no reason to use reference equality. In fact, I think equality is the wrong question: it should duplicate the match. `case (x, y, x)` should `__match__((a, b, c))` IFF `a.__match__(c)` (Not sure if that's exactly the right syntax for the Python calls, but hopefully the idea is clear.) (Elixir has a similar operation to "pin" in a match: if you use an existing variable as the pattern, but pin it, the value must match whatever the variable is already bound to.) > I think at least making it an error now can leave it open to defining it later. Fair point.
- CDSlice 6y ago
  Although it won't be as concise, you can use guards to emulate this feature with match data: case [x1, x2] if x1 == x2: ... I agree on this being a fantastic addition to the language. I've sorely missed not having pattern matching in Python after using Rust.
  - 6y ago
sillysaurusx 6y ago
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.” 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. I hope this PEP never moves beyond draft. 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 you can’t read 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. And oh yes, it becomes impossible to backport to older python versions. Lovely.
- logicchains 6y ago
  Apart from Clojure, lisps generally do not support destructuring pattern matching on an object/dict.
  - sillysaurusx 6y ago
    The defining feature of lisp is that it can support whatever you want, because the AST is available at compile time and is completely regular. If your point is about dicts specifically, then you might be technically correct, but I assure you that the majority of lisp codebases do support exactly the sort of pattern matching in this PEP. And the abuses are frankly egregious. Racket is the worst offender of them all, with syntax matching.
  - fiddlerwoaroof 6y ago
    Trivia or Optima in Common Lisp support that.
- fiddlerwoaroof 6y ago

arusahni 6y ago

What's interesting here is this is gated on the new parser from PEP-617 [1]. Based on mailing list discussions [2], and the PEP, the use of `match` will be context-sensitive, so it shouldn't be as disruptive of an introduction as `async`. 1: https://www.python.org/dev/peps/pep-617/ https://www.python.org/dev/peps/pep-617/ 2: https://lwn.net/Articles/816922/ https://lwn.net/Articles/816922/

herman_toothrot 6y ago
missed a zero: https://www.python.org/dev/peps/pep-0617/ https://www.python.org/dev/peps/pep-0617/

wool_gather 6y ago

One difference I noticed from Elixir was this: > While matching against each case clause, a name may be bound at most once, having two name patterns with coinciding names is an error. match data: case [x, x]: # Error! ... Which is a bit of a shame. This comes in handy in Elixir to say "the same value must appear at these places in the collection". I.e. for a Python tuple pattern `(x, y, x)`, `(3, 4, 5)` would not match but `(3, 4, 3)` would. Overall, though, I think this will be a great addition to Python. Pattern matching is generally a huge boost for expressiveness and readability, in my opinion.

Tyr42 6y ago
Which equality will you use if it's not numbers, but something more complicated. What if `(x, y, x)` is matched against some `(a, b, c)` where `a == c`, but not `a is c`? If yes, and you mutate `x` in the body, does it mutate `a` or does it mutate `c`? I think at least making it an error now can leave it open to defining it later.
- wool_gather 6y ago
  There's certainly no reason to use reference equality. In fact, I think equality is the wrong question: it should duplicate the match. `case (x, y, x)` should `__match__((a, b, c))` IFF `a.__match__(c)` (Not sure if that's exactly the right syntax for the Python calls, but hopefully the idea is clear.) (Elixir has a similar operation to "pin" in a match: if you use an existing variable as the pattern, but pin it, the value must match whatever the variable is already bound to.) > I think at least making it an error now can leave it open to defining it later. Fair point.
CDSlice 6y ago
Although it won't be as concise, you can use guards to emulate this feature with match data: case [x1, x2] if x1 == x2: ... I agree on this being a fantastic addition to the language. I've sorely missed not having pattern matching in Python after using Rust.
- 6y ago

sillysaurusx 6y ago

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.” 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. I hope this PEP never moves beyond draft. 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 you can’t read 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. And oh yes, it becomes impossible to backport to older python versions. Lovely.

logicchains 6y ago
Apart from Clojure, lisps generally do not support destructuring pattern matching on an object/dict.
- sillysaurusx 6y ago
  The defining feature of lisp is that it can support whatever you want, because the AST is available at compile time and is completely regular. If your point is about dicts specifically, then you might be technically correct, but I assure you that the majority of lisp codebases do support exactly the sort of pattern matching in this PEP. And the abuses are frankly egregious. Racket is the worst offender of them all, with syntax matching.
- fiddlerwoaroof 6y ago
  Trivia or Optima in Common Lisp support that.
fiddlerwoaroof 6y ago