gh-129858: Special syntax error for elif block after else

[swfarnsworth]

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.

• Issue: Special syntax error for elif after else #129858

[swfarnsworth]

@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.

[picnixz]

I compiled cpython with this version of the parser and confirmed that it doesn't conflict with other special syntax or indentation errors.

Please add a test. There should be tests in some test_syntax.py file or test_parser.py files (I don't remember where we put them). Just Ctrl+F some error message to find the file.

[swfarnsworth]

@picnixz No problem--will do.

[swfarnsworth]

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.

[ghost]

All commit authors signed the Contributor License Agreement.

[swfarnsworth]

Those last two commits should appear as being from this GitHub account. Let me see if I can delete them and try again.

[picnixz]

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)

[swfarnsworth]

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.

[picnixz]

• For the detection issue, you should just merge main into that branch with the Update branch button!
• A NEWS entry and a What's New entry could be added in order to indicate that we have an improved message now. I don't have a good wording here though so maybe @hugovk may have some suggestion?

[swfarnsworth]

We can draw inspiration from here, I suppose?

[swfarnsworth]

What about this? I'm not sure if the blocks need something more realistic than pass.

elif statements that follow an else block now have a specific error message.

>>> 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

[picnixz]

We can draw inspiration from here, I suppose?

Yes that's what I had in mind.

[picnixz]

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

[swfarnsworth]

I like that, but I think I'll do "It's me!" and "It's not me!" in honor of Elphaba,

[picnixz]

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 :)

[swfarnsworth]

We also get a subtle homage to Britney :)

[hugovk]

I've updated the PR from main which will fix the unrelated "computed changes" error.

[picnixz]

Some markup nits and LGTM

[picnixz]

* :keyword:`elif` statements that follow an :keyword:`else` block
  now have a specific error message.

[picnixz]

:keyword:`elif` statements that follow an :keyword:`else` block now have a specific error message.

[picnixz]

You can also put the keyword syntax here.

[swfarnsworth]

@picnixz done!
Is this going to get squash merged?

[picnixz]

Is this going to get squash merged?

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).

[swfarnsworth]

I see that there are now merge conflicts with parser.c. I figure this means someone else has made changes to the grammar. Should I undo my changes to parser.c, pull the changes to the grammar, and rebuild parser.c?

[picnixz]

I see that there are now merge conflicts with parser.c. I figure this means someone else has made changes to the grammar.

You can just regenerate the parser files indeed (I think they are automatically generated right?)

[swfarnsworth]

@picnixz yeah, there's a make command to do it.

[picnixz]

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.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[hugovk]

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/

[swfarnsworth]

Apologies for the delay @hugovk @picnixz. I was having issues with the dev container I was using to develop this and didn't see the message from picnixz that soon followed my most recent message.

[hugovk]

Please check the CI failures.

[swfarnsworth]

@hugovk @picnixz I think everything is fixed.

[pablogsal]

LGTM!

Fantastic job @swfarnsworth! Thanks for your contribution :)