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.

Author martin.panter
Recipients eric.smith, martin.panter, serhiy.storchaka, yan12125
Date 2016-12-10.23:47:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1481413666.46.0.424386400866.issue28582@psf.upfronthosting.co.za>
In-reply-to
Content
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 :)
History
Date User Action Args
2016-12-10 23:47:46martin.pantersetrecipients: + martin.panter, eric.smith, serhiy.storchaka, yan12125
2016-12-10 23:47:46martin.pantersetmessageid: <1481413666.46.0.424386400866.issue28582@psf.upfronthosting.co.za>
2016-12-10 23:47:46martin.panterlinkissue28582 messages
2016-12-10 23:47:46martin.pantercreate