This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.7, Python 3.6
Status: closed Resolution: duplicate
Dependencies: Superseder: Syntax error caret confused by indentation
View: 25677
Assigned To: Nosy List: eric.smith, martin.panter, serhiy.storchaka, yan12125
Priority: normal Keywords:

Created on 2016-11-01 18:23 by eric.smith, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg279888 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2016-11-01 18:23
See msg279799 from issue28128, repeated here:

Seems the ^ pointer is not always correct. For example, in the function scope it's correct:

$ cat 
def foo():
    s = 'C:\Program Files\Microsoft'

$ python3.7 -W error
  File "", line 2
    s = 'C:\Program Files\Microsoft'
SyntaxError: invalid escape sequence \P

On the other hand, top-level literals confuses the pointer:

$ cat               
s = 'C:\Program Files\Microsoft'

$ python3.7 -W error
  File "", line 1
    s = 'C:\Program Files\Microsoft'
SyntaxError: invalid escape sequence \P

Is that expected?
msg279894 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-11-01 21:51
This is known issue. See issue25677.
msg282887 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-12-10 23:47
I think there are actually two issues at play here:

1. The caret is not compensated for indentation removed from the code. This is what Issue 25677 was originally about. The current patch there will ensure that the behaviour is always like the second (top-level) case, no matter what the indentation was.

2. The caret points at the character before SyntaxError.offset. Sometimes the offset identifies the _end_ of the erroneous syntax, and the caret makes sense, because it points at the end of an invalid word (or directly at an invalid character). But other times, such as the invalid escape sequence, offset points at the _start_ of the invalid syntax, and the caret will point to the end of the previous valid syntax. This issue was brought up at the end of Issue 25677, but should probably be dealt with separately.

If you take the first case (indented function), and change the size of the indentation, you will see that the caret is no longer correct. It just happens that with four spaces, the two bugs kind of cancel each other out, and the positioning is actually better than it was designed to be :)
Date User Action Args
2022-04-11 14:58:38adminsetgithub: 72768
2016-12-10 23:47:46martin.pantersetnosy: + martin.panter
messages: + msg282887
2016-11-02 14:56:18eric.smithsetstatus: open -> closed
stage: resolved
2016-11-01 21:51:57serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg279894
resolution: duplicate

superseder: Syntax error caret confused by indentation
2016-11-01 18:23:42eric.smithcreate