Funny behavior of IDLE 3.7.0

[Terry Reedy]

On 11/12/2019 8:29 AM, Chris Angelico wrote:

> The OP said that the equals sign in the *first* line was flagged as
> invalid syntax. Implication being that the error is being reported on
> the line "i = 4", not on the print at the end. And in fact, I can
> confirm this. Run | Check Module reports an error where i is assigned
> to. Here's how it looks in command-line Python:
> 
> $ python3.7 demo.py
>    File "<fstring>", line 1
>      (i=)
>        ^
> SyntaxError: invalid syntax
> 
> Newer Pythons are happy with this example, but if you replace the
> error with something else - say, f'{i+}' - then the same phenomenon
> occurs. Command-line Python reports the error on line 1 of
> "<fstring>", and Idle misinterprets that as line 1 of the original
> file.
> 
> This looks like an error reporting flaw in f-string handling.

Can you open a bug issue (if not one already) and nosy me?
This is awful for any IDE that processes error messages.

Replacing {} with () is a secondary bug.  The actual code
   {i=}
would be clearer, and make it easier for an IDE to search for the real line.

> IMO it
> should just count the entire f-string as being at the line and file
> that the f-string starts; when working with triple-quoted f-strings, I
> was only able to get line numbers above 1 by having a multi-line
> braced expression, and that's not something we should be encouraging.
> This is also consistent with the way other errors in triple-quoted
> strings are handled:
> 
> print('''hello
> world
> \N{ASDF}
> asdf
> qwer''')
> 
>    File "/home/rosuav/tmp/demo.py", line 1
>      print('''hello
>            ^
> SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes
> in position 12-19: unknown Unicode character name
> 
> If it can find the position of the specific braced expression within
> the string, great! But at very least, it should report the location of
> the string in its original file.


-- 
Terry Jan Reedy