Funny behavior of IDLE 3.7.0

[Chris Angelico]

On Wed, Nov 13, 2019 at 12:14 AM Heinrich Kruger <heindsight at kruger.dev> wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, November 12, 2019 12:39 PM, Pieter van Oostrum <pieter-l at vanoostrum.org> wrote:
>
> > ram at zedat.fu-berlin.de">--protonSignature--ram at zedat.fu-berlin.de (Stefan Ram) writes:
> >
> > > When I enter
> > > i = 4
> > > x = 2.3
> > > s = 'abc'
> > > print( f'{i=}' )
> > > into a file window of IDLE 3.7.0, it marks the '='
> > > sign in the /first/ line and says 'invalid syntax'.
> > > Remove the »f«, and the error will disappear.
> >
> > I did this in IDLE 3.7.5, and it gives a syntax error on the last line.
> > This is correct, because the f-string is in error. Between the curly
> > braces there should be an expression, possibly followed by a conversion
> > (!...) and/or a format specification (:...). {i=} is not a correct
> > expression. When you remove the »f«, it becomes a normal string, where
> > the {} don't have a special meaning.
>
> What the OP was trying to do is valid in python 3.8 (see https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging) but not in older versions. To achieve the same result in python 3.7, you have to do something like
>
> print(f'i={i}')
>

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. 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.

ChrisA