PEP 622: Update Appendix A Grammar

[brandtbucher]

Deliberately omitting the mini-grammar on 139.

[gvanrossum]

Hm, on second thought, I think it should be star_named_expressions so you can write match x := f() + g(): to capture the whole expression. You can do this in if, so match should be able to do it too.

[brandtbucher]

Hm, that will be tricky. I'm playing with the implementation, and it looks like star_named_expressions doesn't give us a good way to distinguish between a length-one tuple or a bare expression.

[brandtbucher]

I don't think we currently have a rule for "named expression or unparenthesized tuple", so I'll probably have to make one.

[brandtbucher]

How's this? Seems to work:

match_expr[expr_ty]:
    | value=star_named_expression ',' values=star_named_expressions? {
        _Py_Tuple(CHECK(_PyPegen_seq_insert_in_front(p, value, values)), Load, EXTRA) }
    | named_expression

match_stmt[stmt_ty]:
    | "match" target=match_expr ':' NEWLINE INDENT cases=case_block+ DEDENT {
        _Py_Match(target, cases, EXTRA) }

[gvanrossum]

Let @lysnikolaou review this.

[lysnikolaou]

I'm currently offline. I'll review a bit later tonight. (I'll probably be back in about 3-4 hours)

[lysnikolaou]

I'm not sure what exact syntax you want to allow but this would allow things like match 1,: or match *a,: or even
match a := 1,:, which is pretty counter-intuitive and is not valid syntax anywhere else. Is this your intention?

[brandtbucher]

Yeah, that's my intent with it. It comes from two motivations:

• Mirroring the pattern grammar in the case statements. Since we can do case 1, 2, we want to allow match 1, 2 as well.
• Allowing anything that's valid in an if test. This is basically any expression except an unparenthesized tuple, but the reasons for disallowing that in if don't apply here.

[brandtbucher]

I agree that match x := 1,: is odd, though. At the same time, I don't see a reason to disallow it.

[lysnikolaou]

I agree that match x := 1,: is odd, though. At the same time, I don't see a reason to disallow it.

I feel that I'd need to google this every time to find out if it means match (x := 1,) or match x := (1,):.

[lysnikolaou]

And if I were to guess, I'd probably guess the opposite of what it is, if I knew nothing about the grammar.

[brandtbucher]

I'll defer to @gvanrossum's judgement here, but I'm fine with it. I think he's out for a few days, so this can just be tabled until then.

While I have you here: the new grammar gives a sort of odd error message for the string "match *x,:\n\n":

>>> match *x,:
... 
  File "<stdin>", line 1
    
    ^
SyntaxError: only single target (not tuple) can be annotated

I'm guessing that I need to look ahead somewhere to avoid this and get a normal "invalid syntax" message, but I haven't been able to figure it out. The grammar is here.

[brandtbucher]

By the way, I love your syntax highlighting VSCode extension.

[lysnikolaou]

I'll defer to @gvanrossum's judgement here, but I'm fine with it. I think he's out for a few days, so this can just be tabled until then.

While I have you here: the new grammar gives a sort of odd error message for the string "match *x,:\n\n":

>>> match *x,:
... 
  File "<stdin>", line 1
    
    ^
SyntaxError: only single target (not tuple) can be annotated

I'm guessing that I need to look ahead somewhere to avoid this and get a normal "invalid syntax" message, but I haven't been able to figure it out. The grammar is here.

This is odd indeed. I'd have to take a closer look at this to find out what's going on. I'll make up some time tomorrow.

By the way, I love your syntax highlighting VSCode extension.

Thanks thanks! Glad you like it!

[lysnikolaou]

Had some time to spare, so I looked a bit into this. It seems to be a bug in invalid_assignment, which has the following alternatives:

...
| list ':'
| tuple ':'
| star_named_expression ',' star_named_expressions* ':'
...

This meanns that, even without an expression after the colon, something could be considered an invalid annotation. This is what happens here, because match is a soft keyword and thus match *x,: is parsed as an annotation of a tuple that contains the multiplication match * x.

Opened bpo-41119 and python/cpython#21160.

[brandtbucher]

Thanks for the quick fix!