traceback reports "wrong" file and line

[Skaperen]

technically, it's correct, but useless:

Output:
lt2a/forums /home/forums 5> cat foo.py
a=1
b=2
c=3
d=f'hello {world{}}'
lt2a/forums /home/forums 6> python3.6 foo.py
  File "<fstring>", line 1
    (world{})
          ^
SyntaxError: invalid syntax
lt2a/forums /home/forums 7>

in a big script with lots of similar messages, you won't know which line the error in the f-string is at. did they get this fixed in 3.6.9 or 3.7 or 3.8?

[perfringo]

I can quite clearly see that this is 'line 1'

But on more serious note - what should be desired behaviour?

[Malt]

I can quite clearly see that this is 'line 1'

But on more serious note - what should be desired behaviour?

Would be the exact line number. In this case, line #4

[ChislaineWijdeven]

I can quite clearly see that this is 'line 1'

But on more serious note - what should be desired behaviour?

Hi! In your case particularly you'll have the number of the line (4). Good luck!

[perfringo]

First of all - I didn't pay enough attention. So - Mea culpa

So far I have managed to get SyntaxErrors caused by f-strings with correct line and file numbers. However, this particular instance indeed behaves unexpectedly.

[Skaperen]

I can quite clearly see that this is 'line 1'

But on more serious note - what should be desired behaviour?

desired behavior should be something that (also) indicates the name of the file and line number the f'string is on. it could do this in much the same way it shows where a function was called from or where a module was imported from. the guts of a f-string seem to be compiled like code. i don't know how that gets put together but it is obvious that the f-string gets constructed into a regular string at the point where the f-string appeared in the source code (as executed). hypothetically, an f-string could even appear inside an f-string (i've never tried this, but maybe i should). there should be a stack of data items showing where the code is invoked, which in the case of f-strings would also show where they are. that stack should (also) be shown at that point in the traceback dump. if that information is not recorded, then it should be.

---

within an f-string there are zero or more clauses within {} that should be enumerated so that which an error exists in (whether detected at compile time or at run time) can be revealed as part of the error traceback. in the case of an f-string inside an f-string (i don't know, yet, if this is allowed), this could be a stack of enumerations identifying the nesting of f-strings (making it even easier to find which expression has the error).