`case ...:` generates unclear `SyntaxError` message

[sobolevn]

Feature or enhancement

Proposal:

I've noticed that this simple python code sample generates unclear error message:

>>> match 1:
...    case ...: ...
  File "<stdin>", line 2
    case ...: ...
         ^^^
SyntaxError: invalid syntax

I propose making the error message clearer:

>>> match 1:
...    case ...: ...
  File "<stdin>", line 2
    case ...: ...
         ^^^
SyntaxError: cannot use case statement with ellipsis

We already have this logic for := expressions:

>>> (a[0] := 1)
  File "<stdin>", line 1
    (a[0] := 1)
     ^^^^
SyntaxError: cannot use assignment expressions with subscript

Since case requires some special grammar (not regular python expression) it would be user-friendly to improve this message.

I have a PR ready.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-138864: Improve SyntaxError message for case with expression #138865

[ericvsmith]

Is there any indication that this is actually a problem for users? Is this a common error? There are a huge number of possible errors: I’m opposed to adding every one of them as a special case with a unique error message.

Whatever we need do needs to be weighed against how common the particular error is. Ultimately, “Syntax error” is correct, and the users will have to know how to handle them.

[sobolevn]

Is there any indication that this is actually a problem for users?

Yes, I think so. case has its own micro-language that is unique. You can use list-looking and tuple-looking expressions, but not set-looking expressions.

>>> match (1, 2):
...     case (1, 2):
...         print(1)
...         
1
>>> match {1, 2}:
...     case {1, 2}:
...         print(2)
...         
  File "<python-input-1>", line 2
    case {1, 2}:
         ^^^^^^
SyntaxError: invalid syntax                          # <- now
SyntaxError: cannot use set display as case pattern  # <- my proposal

Regular SyntaxError requires user to understand the reason behind this, which is not really clear.

You can write dict patterns, but not dict unpacking or comprehensions. The line between last 3 grammar pieces is very thin. We have real users reported this as a problem somewhere in the past.

And tests for these cases:

cpython/Lib/test/test_syntax.py

Lines 373 to 383 in 7168e98

	>>> match ...:
	... case {**rest, "key": value}:
	... ...
	Traceback (most recent call last):
	SyntaxError: invalid syntax
	>>> match ...:
	... case {**_}:
	... ...
	Traceback (most recent call last):
	SyntaxError: invalid syntax

And my proposal improves these cases as well.

Ultimately, “Syntax error” is correct, and the users will have to know how to handle them.

I don't agree with this, sorry. Let's say you have this code:

some_arg: Any
if some_arg == None:
     print('None')
elif some_arg == ...:
     print('...')

and then you refactor it to:

match some_arg:
    case None: 
         print('ok')
    case ...: 
         print('...')

-> You will get a SyntaxError: invalid syntax.
Is it easy to fix? Yes. Does it require you to know the little quirks of PM? Yes. Is it user friendly? No.

I think that we should care about users and show them the best diagnostics we can.
Especially, when it costs us little to nothing: invalid_ rules do not slow down initial successful parsing and only are run when the code is broken.

Many languages like Rust, Gleam, etc are exceptional in these diagnostics. Basically, allowing users to copy-paste suggestions from the error messages. Which is super cool for beginners (which is one of our target audiences).

I’m opposed to adding every one of them as a special case with a unique error message.

Can you please specify - why? What do we lose when doing so?
I can see several potential problems:

• Potential errors while parsing, it is critical. We need to test this very well
• Support cost, we have to maintain good standard of good error messages

Is there something I am missing here? :)
I would love to hear your opinion and your technical concerns.

Is this a common error?

One last thing: users don't report these problems usually, because technically all is correct. This is an issue with the syntax. But, they don't report their frustrations when they spend X minutes understanding the problem and fixing it, when there can be a better way :)

[Eclips4]

Many new programming tools provide extensive diagnostics and for good reason :)
If clarifying an error doesn’t hurt performance, what’s the downside?

The only aspect I don’t particularly like in this case is that python.gram keeps growing with each invalid rule. I’d prefer to keep invalid rules in a separate file, but that’s a different discussion.

[ericvsmith]

My point is that I think there need to be some guidelines, otherwise the grammar will grow and grow, and become harder to maintain over time. What is the bar that a given specific error condition needs to clear before it's added as a special case? Can it be made an objective test? If there is no standard to meet, then the temptation is to accept every such special case, which I think is a mistake.

[efimov-mikhail]

IMO, this change worth it. It may not be obvious just for Ellipsis, but adding general rule for "broken match" looks good to me.