All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

@gvanrossum, @pablogsal, @lysnikolaou (as PEG experts)

You need to regenerate the parser files (one of the checks is failing).

Apart from that I am not sure this is really what we want. What this PR seems to be doing is validating that we can parse an empty string, which is somehow better than what we have now but it doesn't validate that the generated parser works correctly and you don't need to reach back to the previous one.

Maybe what we need here is a backup system so when the metagrammar is regenerated you can easily get back the previous one. In any case, what I normally do is just do git checkout HEAD path_to_grammar_parser and I get back the previous file.

@lysnikolaou what are your thoughts?

Thanks for the PR, @Marwanmhks!

@pablogsal I agree! This is not really solving the problem of there being cases, where we need to fall back to the previous version of the metagrammar parser. But yeah, in general, is this a problem worth solving? I feel the answer is no, since the work-around of using git to just go back in time is so straightforward.

But yeah, in general, is this a problem worth solving? I feel the answer is no, since the work-around of using git to just go back in time is so straightforward.

👍

Without the fix, the build will succeed the first time, writing a bad output file, and it will fail every time thereafter, even if you restore the old metagrammar.gram, it would require to regenerate the grammar_parser.py