FWIW there are some differences here in the SyntaxErrors displayed.

FWIW there are some differences here in the SyntaxErrors displayed.

What syntax error are you referring to?

➜  cpython git:([bpo-41979](https://bugs.python.org/issue41979)) python3.8
Python 3.8.6 (default, Oct  3 2020, 16:26:47) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> with a as *b:
  File "<stdin>", line 1
    with a as *b:
              ^
SyntaxError: invalid syntax
>>> with a as (*b):
...     pass
... 
  File "<stdin>", line 1
SyntaxError: starred assignment target must be in a list or tuple
>>> 
➜  cpython git:([bpo-41979](https://bugs.python.org/issue41979)) ./python
Python 3.10.0a1+ (heads/[bpo-41979](https://bugs.python.org/issue41979):bc2fd55f74, Oct  9 2020, 11:30:38) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> with a as *b:
...     pass
... 
  File "<stdin>", line 1
SyntaxError: starred assignment target must be in a list or tuple
>>> with a as (*b):
  File "<stdin>", line 1
    with a as (*b):
               ^
SyntaxError: can't use starred expression here

I'm not saying we should change something here. I'm just mentioning the differences, so that we know about them. Thoughts?

I'm not saying we should change something here. I'm just mentioning the differences, so that we know about them. Thoughts?

Oh, thanks for the example! I think the second one may be a bit confusing to users (you can use star expressions there but as the first error mentions, must be in a list or a tuple). I will try to create a PR today for this, but I think we can treat it separately from this one, what do you think?

FWIW, this behavior is the exact same thing with other assignments;

(3.10)
>>> *a = [1,2]
  File "<stdin>", line 1
SyntaxError: starred assignment target must be in a list or tuple
>>> (*a) = [1,2]
  File "<stdin>", line 1
    (*a) = [1,2]
     ^
SyntaxError: can't use starred expression here

FWIW, this behavior is the exact same thing with other assignments;

Yeah, that's why I proposed to treat this independently of this PR. I will create a patch for this syntax error today if I find the time

FWIW, this behavior is the exact same thing with other assignments;

Yeah, that's why I proposed to treat this independently of this PR. I will create a patch for this syntax error today if I find the time

Agreed.

What bugs me most is that in the with a as *b example, I'm not immediately getting an error like in the old parser. I must complete the whole with statement before I get to the SyntaxError.

I must complete the whole with statement before I get to the SyntaxError.

But that only makes sense in the REPL no? We can look together later how to make this fail before if you wish. Likely is a matter of restricting some of that rule or checking the order. But I would be cautious of this as it probably will raise the complexity of the grammar a bit.

Thanks @isidentical for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

Sorry, @isidentical and @pablogsal, I could not cleanly backport this to 3.9 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 48f305fd122080a9181cbda33bdb42ea36a0136f 3.9

@isidentical Can you do the backport, please?

Agreed, let's merge this and come back to it later.

GH-22612 is a backport of this pull request to the 3.9 branch.