-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid mapping patterns give confusing SyntaxErrors #88534
Comments
Here are a few that I found. Not sure when they were introduced: match ...: match ...: match ...: These all give the following error while parsing the second line: File "<stdin>", line 1 |
Perhaps we need something like invalid_mapping_pattern or invalid_mapping_pattern_double_star rules? |
Probably, otherwise is going to hurt because the syntax errors that you describe trigger when two names are place together, which in general is a missing comma. The error message also doesn't say: "you are missing a comma" it says that the most typical reason is a missing comma, which is important to distinguish :) |
The backtracking with the soft keyword may make this very annoying, by the way. |
Oh, wait, I think I misunderstood the problem. The problem is that the parser is backtracking and identifying match as a name. Indeed, the soft keyword is a pain :( |
I think it actually will be very useful to explain that these cases are invalid in the Syntax error, which will also solve this problem. This on the other hand shows a bigger problem: any generic syntax error that happens inside "match" will probably end identifying the keyword as a name, even if we don't have specific errors, the parser will point to it and complain about "match". |
Oh, turns out I already added machinery to solved this but I was missing a piece! |
Wow, that was quite a roller-coaster ride. Thanks Pablo. :) |
I found a similar one, by the way (not related to mapping patterns): >>> match ...:
... case 42 as _:
... pass
File "<stdin>", line 2
case 42 as _:
^
SyntaxError: expected ':' Is this covered by your fix? |
No, that is not a backtracking error (is not going all the way to the "match" expression). |
I will fix that one in another PR |
Oh, this one is actually correct: match ...: File "<stdin>", line 2 That is literally expecting a ":" and that's the error. It has identified "case 42" correctly and it now expects a ":". Is just that the error marker is wrong because it has reached the "as and _" as part of the parsing so the error is there. That is going to be a bit tricky to "fix" |
Could we just try parsing "as _" and raise if so? That wouldn't conflict with any existing rules, and that way we could actually have a helpful error message. |
Like "SyntaxError: can't capture into a wildcard (consider removing)". |
No, the same happens with other targets such as: File "/home/pablogsal/github/python/master/lel.py", line 2 |
Checkout PR 26632, and see if this works for you |
@pablogsal @brandtbucher The issue seems to be solved. We can close the issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: