IDLE highlights the location of a SyntaxError according to its .lineno and .offset attributes.  For expressions within braces within f strings, the reported offset is respect to the expression augmented with surrounding ()s added, not the actual physical line.  From my perspective as IDLE maintainer, I consider this undocumented 'feature' a design bug.

Pablo, I know you did not do this, but you helped design and understand the new compiler.  If we cannot change .offset to report the real offset, can we add a new attribute, .line_offset for 3.9 and 3.10?  Does the new compiler know where within the line the expression starts?  Are there any other cases where .offset is not the real offset with respect to the actual code?  Or rather, are there other cases where the actual line is replaced with a constructed line?  Is so, are confusing fake ()s always added, that make the replacement *not* a substring of the original?  Are there any plans to add new cases like this?

In the absence of compile providing the line offset, every IDE that marks errors in the actual line has to separately code a workaround.  However, a change in 3.9 makes this harder.  In 3.8, errors within fstring expressions were tagged with .filename '<fstring>'.  In 3.9, this is attribute is ''.


The REPL in 3.7 (very soon security fixes only) and 3.8:
>>> f'{*a}'
  File "<stdin>", line 1
SyntaxError: can't use starred expression here
>>> f'{**a}'
  File "<fstring>", line 1
    (**a)
     ^
SyntaxError: invalid syntax
>>> f'{a a}'
  File "<fstring>", line 1
    (a a)
       ^
SyntaxError: invalid syntax


The REPL in 3.9/3.10 with the new parser is more consistent.
>>> f'{*a}'
  File "<stdin>", line 1
    (*a)                  # Does not ^ belong under *?  See below.
       ^
SyntaxError: invalid syntax
>>> f"{'abc' + *a}"
  File "<stdin>", line 1
    ('abc' + *a)          # This was the same in 3.8.
             ^
SyntaxError: invalid syntax