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

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 sometest_syntax.py file ortest_parser.py files (I don't remember where we put them). Just Ctrl+F some error message to find the file.

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

All commit authors signed the Contributor License Agreement.

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)

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.

• For the detection issue, you should just merge main into that branch with theUpdate 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?

We can draw inspiration fromhere, I suppose?

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

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

>>>ifword.startswith('a'):...pass...else:...pass...elifword.startswith('b'):...passFile"<stdin>",line5elifword.startswith('b'):^^^^SyntaxError:'elif'blockfollowsan'else'block

We can draw inspiration fromhere, I suppose?

Yes that's what I had in mind.

Another possibility is:

>>>ifwho=="me":...print("This is me!")...else:...print("This is not me!")...elifwhoisNone:...print("Who is it?")File"<stdin>",line5elifwhoisNone:^^^^SyntaxError:'elif'blockfollowsan'else'block

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

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

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

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

I see that there are now merge conflicts withparser.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?

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

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

All commit authors signed the Contributor License Agreement.

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/

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.

Please check the CI failures.

@hugovk@picnixz I think everything is fixed.

LGTM!

Fantastic job@swfarnsworth! Thanks for your contribution :)