3 ms·

x = match y: case 0: "zero" case 1: "one" case x: y = f(x) y+y print(x) it can require semicolons or parentheses or even braces so

by uryga 5y ago

x = match y: case 0: "zero" case 1: "one" case x: y = f(x) y+y print(x) it can require semicolons or parentheses or even braces somewhere if that's necessary to make the grammar work, idc. just don't make me type out `x = ...` a hundred times... (yes, i know you could use the walrus operator in the third case) (also, if anyone wants to reply with "use a named function because READABILITY", please save it)

toxik 5y ago
Judging by the votes you got, your proposal is not well-liked. In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end. However, your proposal actually misses the mark in the same way as the actual match/case does as well. What would be /really/ handy in Python is something like {'some_key': bind_value_to_this_name} = a_mapping because it is so common, especially if you're consuming a JSON API. You of course see the myriad problems with the above. I think you should read the PEPs on match/case, these things have actually been considered. One idea was to introduce a keyword to say which variables are inputs and which are outputs, but that also violates the general grammar in a way that isn't very nice. The accepted solution has warts, I agree, but at some point you just have to accept that you can't reach some perfect solution.
- uryga 5y ago
  > Judging by the votes you got, your proposal is not well-liked. i'm at peace with that :) [1] > In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end. that's your opinion, i disagree! i think Python would be a better, more pleasant to use language if they figured this out. a girl can dream, ok? > What would be /really/ handy in Python is something like {'some_key': bind_value_to_this_name} = a_mapping yes, extending the destructuring syntax would be nice, i agree! but the original question was "Please suggest a pattern matching expression syntax [...]", and the post you were responding to was specifically talking about `match`'s syntax. [2] > I think you should read the PEPs on match/case i read them when they came out. i'm assuming you're referring to this section from PEP 622: > "In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python." https://www.python.org/dev/peps/pep-0622/#id77 https://www.python.org/dev/peps/pep-0622/#id77 i believe Python's statement-orientatation kinda sucks, so to me this is just "things aren't great, let's stay consistent with that". yeah, yeah, "use a different language if you don't like it" etc. --- [1] well, maybe not quite, after all i'm here arguing about it. [2] `match` uses patterns like the one you described in `case` arms, but is distinct from them. i don't see why dict-destructuring syntax couldn't be added in a separate PEP.
  - uryga 5y ago
    pedantic addendum: looks like i messed up my PEPs -- i linked to PEP622, which was superseded by PEP635 [1]. the gist of it hasn't changed though. --- [1] https://www.python.org/dev/peps/pep-0635/#the-match-statement https://www.python.org/dev/peps/pep-0635/#the-match-statemen..., Ctrl+F "Statement vs. Expression"
adsharma 5y ago
I'm interested in similar proposals that can provide the basis of some common syntax that could be transpiled to other functional programming languages https://github.com/adsharma/py2many https://github.com/adsharma/py2many I'm less interested in the syntax (will take anything accepted by a modified ast module), more in the semantics. Here's a syntax I played with in the past: def area(s: Shape): pmatch(s): Circle(c): pi * c.r * c.r Rectangle(w, h): w * h ;; def times10(i): x = pmatch(i): 1: 10 2: 20 ;; return x Two notes: * Had to be pmatch, since match is more likely to run into namespace collision with existing code. * The delimiter `;;` at the end was necessary to avoid ambiguity in the grammar for the old parser. Perhaps things are different with the new PEG parser. Code is on my github.

by uryga 5y ago

toxik 5y ago

Judging by the votes you got, your proposal is not well-liked. In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end. However, your proposal actually misses the mark in the same way as the actual match/case does as well. What would be /really/ handy in Python is something like {'some_key': bind_value_to_this_name} = a_mapping because it is so common, especially if you're consuming a JSON API. You of course see the myriad problems with the above. I think you should read the PEPs on match/case, these things have actually been considered. One idea was to introduce a keyword to say which variables are inputs and which are outputs, but that also violates the general grammar in a way that isn't very nice. The accepted solution has warts, I agree, but at some point you just have to accept that you can't reach some perfect solution.

uryga 5y ago
> Judging by the votes you got, your proposal is not well-liked. i'm at peace with that :) [1] > In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end. that's your opinion, i disagree! i think Python would be a better, more pleasant to use language if they figured this out. a girl can dream, ok? > What would be /really/ handy in Python is something like {'some_key': bind_value_to_this_name} = a_mapping yes, extending the destructuring syntax would be nice, i agree! but the original question was "Please suggest a pattern matching expression syntax [...]", and the post you were responding to was specifically talking about `match`'s syntax. [2] > I think you should read the PEPs on match/case i read them when they came out. i'm assuming you're referring to this section from PEP 622: > "In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python." https://www.python.org/dev/peps/pep-0622/#id77 https://www.python.org/dev/peps/pep-0622/#id77 i believe Python's statement-orientatation kinda sucks, so to me this is just "things aren't great, let's stay consistent with that". yeah, yeah, "use a different language if you don't like it" etc. --- [1] well, maybe not quite, after all i'm here arguing about it. [2] `match` uses patterns like the one you described in `case` arms, but is distinct from them. i don't see why dict-destructuring syntax couldn't be added in a separate PEP.
- uryga 5y ago
  pedantic addendum: looks like i messed up my PEPs -- i linked to PEP622, which was superseded by PEP635 [1]. the gist of it hasn't changed though. --- [1] https://www.python.org/dev/peps/pep-0635/#the-match-statement https://www.python.org/dev/peps/pep-0635/#the-match-statemen..., Ctrl+F "Statement vs. Expression"

adsharma 5y ago

I'm interested in similar proposals that can provide the basis of some common syntax that could be transpiled to other functional programming languages https://github.com/adsharma/py2many https://github.com/adsharma/py2many I'm less interested in the syntax (will take anything accepted by a modified ast module), more in the semantics. Here's a syntax I played with in the past: def area(s: Shape): pmatch(s): Circle(c): pi * c.r * c.r Rectangle(w, h): w * h ;; def times10(i): x = pmatch(i): 1: 10 2: 20 ;; return x Two notes: * Had to be pmatch, since match is more likely to run into namespace collision with existing code. * The delimiter `;;` at the end was necessary to avoid ambiguity in the grammar for the old parser. Perhaps things are different with the new PEG parser. Code is on my github.