gh-129858: Special syntax error for elif block after else#129902
gh-129858: Special syntax error for elif block after else#129902pablogsal merged 12 commits intopython:mainfrom
elif block after else#129902Conversation
Previously, having an elif block after an else block would raise a standard syntax error.
|
@pablogsal I see that you've been tagged for review. Please see the associated issue for discussion about whether an even more sophisticated error message is possible. |
Please add a test. There should be tests in some |
|
@picnixz No problem--will do. |
|
I've implemented a test as requested, though I'll hold off on committing or pushing it until we decide on the exact wording of the error message. |
|
Those last two commits should appear as being from this GitHub account. Let me see if I can delete them and try again. |
|
In general, we avoid force-pushing, but you can do it in this case and amend the commit author and put the correct email address. (Not sure if it could help in this though) |
62996a0 to
883ada9
Compare
|
The force push seems to have fixed the problem without any issues. The usernames for my work and personal email differ by one letter, which is occasionally inconvenient. |
|
|
We can draw inspiration from here, I suppose? |
|
What about this? I'm not sure if the blocks need something more realistic than
>>> if word.startswith('a'):
... pass
... else:
... pass
... elif word.startswith('b'):
... pass
File "<stdin>", line 5
elif word.startswith('b'):
^^^^
SyntaxError: 'elif' block follows an 'else' block |
Yes that's what I had in mind. |
|
Another possibility is: >>> if who == "me":
... print("This is me!")
... else:
... print("This is not me!")
... elif who is None:
... print("Who is it?")
File "<stdin>", line 5
elif who is None:
^^^^
SyntaxError: 'elif' block follows an 'else' block |
|
I like that, but I think I'll do "It's me!" and "It's not me!" in honor of Elphaba, |
Let's go for this one :) |
|
We also get a subtle homage to Britney :) |
Misc/NEWS.d/next/Core_and_Builtins/2025-02-12-01-36-13.gh-issue-129858.M-f7Gb.rst
Outdated
Show resolved
Hide resolved
hugovk
left a comment
There was a problem hiding this comment.
I've updated the PR from main which will fix the unrelated "computed changes" error.
Misc/NEWS.d/next/Core_and_Builtins/2025-02-12-01-36-13.gh-issue-129858.M-f7Gb.rst
Outdated
Show resolved
Hide resolved
…e-129858.M-f7Gb.rst Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Doc/whatsnew/3.14.rst
Outdated
| ^^^^^^^ | ||
| ValueError: too many values to unpack (expected 3, got 4) | ||
|
|
||
| * ``elif`` statements that follow an ``else`` block now have a specific error message. |
There was a problem hiding this comment.
* :keyword:`elif` statements that follow an :keyword:`else` block
now have a specific error message.| @@ -0,0 +1 @@ | |||
| ``elif`` statements that follow an ``else`` block now have a specific error message. | |||
There was a problem hiding this comment.
:keyword:`elif` statements that follow an :keyword:`else` block now have a specific error message.There was a problem hiding this comment.
You can also put the keyword syntax here.
|
@picnixz done! |
Yes, that's why contributors don't need to force-push unless they know what they're doing and/or it's a draft PR. Force-pushing rewrites the history and makes reviews harder if we want to compare with a previous commit (and that's the main reason why we don't want force pushes). I personally do force-push when I have no PR open or if it's a draft or if I need to amend a commit due to git issues (like you had). |
|
I see that there are now merge conflicts with |
You can just regenerate the parser files indeed (I think they are automatically generated right?) |
|
@picnixz yeah, there's a make command to do it. |
|
Just merge the grammar from main, and regenerate the Parser/parser.c file then. When there are conflicts in auto-generated files, just regenerating them is fine. |
|
Please can you fix the merge conflict? Note the 3.14 feature freeze is in just under three weeks: https://peps.python.org/pep-0745/ |
… not implement changes from this PR.
|
Please check the CI failures. |
|
LGTM! Fantastic job @swfarnsworth! Thanks for your contribution :) |
Previously, having an elif block after an else block would raise a standard syntax error. This PR implements a special syntax error saying "elif not allowed after else".
I compiled cpython with this version of the parser and confirmed that it doesn't conflict with other special syntax or indentation errors.
elifafterelse#129858