Here are some examples from mypy test cases where we no longer output specialised error messages:

x, (y, 1) = 1
x, [y, 1] = 1
x, [y, [z, 1]] = 1
x, (y, (z, 1)) = 1
with f() as 1: pass

Yes, that is also an issue with the current targets situation. There are many errors case in assignment, where we don't output the correct message. Hopefully, #123 will resolve that, if we decide to implement it.

Forgot this above, a fairly minor one since you need to parse with type_comments=True for it to happen, but:

def f(
    *, # type: int
    x  # type: str
): ...

throws bare * has associated type comment

Oh dear, I tried that, and ast.parse() produces a syntax error that has the entire rest of the file as the text attribute. This gets formatted really weirdly. I just was looking at this code for python#20072, but the problem here is in the ast module and how it interfaces to pegen, not in the formatting of exceptions.

UPDATE: It seems to be happening whenever compile() can't read the source code. (But only for the new parser.) I opened https://bugs.python.org/issue40619

All the specialised error messages listed here are now supported by the new parser. See among others: python#20076, python#19865, python#20151, python#20153 and python#19911.

Maybe there's an unmerged PR I haven't seen, but it looks like the following doesn't have a specialised error message on CPython master: with f() as 1: pass

Maybe there's an unmerged PR I haven't seen, but it looks like the following doesn't have a specialised error message on CPython master: with f() as 1: pass

That should be handled by python#20106