gh-146492: Improve SyntaxError for missing comma between import clauses

[brianschubert]

Demo:

>>> import a as a  b
  File "<python-input-0>", line 1
    import a as a  b
                ^^^^
SyntaxError: expected comma between import clauses

>>> from x import a as a  b
  File "<python-input-1>", line 1
    from x import a as a  b
                       ^^^^
SyntaxError: expected comma between import clauses

• Issue: Confusing syntax error for missing comma after import-as target #146492

[pablogsal]

Unless I'm missing something, is this rule a bit too broad now?

compile("import a b()", "<repro>", "exec")
compile("import a b + c", "<repro>", "exec")
compile("from x import a b[c]", "<repro>", "exec")

This prints:

expected comma between import clauses | line=1 col=8 end_line=1 end_col=11
expected comma between import clauses | line=1 col=8 end_line=1 end_col=11
expected comma between import clauses | line=1 col=15 end_line=1 end_col=18

In all three cases, adding a comma still wouldn't make the code valid, so this doesn't seem like a real missing comma between import clauses situation. Should this only trigger when the would-be second clause is actually a valid import target?

[pablogsal]

Are we only pinning the message text for a few simple one-line cases here? For example, these both reproduce the new behavior:

compile("import a, b c", "<repro>", "exec")
compile("from x import (a\n b)", "<repro>", "exec")

with:

expected comma between import clauses | line=1 col=11 end_line=1 end_col=14
expected comma between import clauses | line=1 col=16 end_line=2 end_col=3

But from what I can see, the new tests here don't assert the caret/range at all, and they also don't cover either a later-clause case or the parenthesized multiline form. Would it make sense to add at least one range-aware assertion and one nontrivial shape, so the main user-visible part of the change is actually locked down?

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.