Funny behavior of IDLE 3.7.0
Terry Reedy
tjreedy at udel.edu
Tue Nov 12 11:55:59 EST 2019
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
More information about the Python-list
mailing list