bpo-45249: Ensure the traceback module prints correctly syntax errors with ranges #28575
Conversation
pablogsal
force-pushed
the
bpo-45249
branch
from
a6e7698 to
16bf58a
Compare
|
Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10. |
|
GH-28587 is a backport of this pull request to the 3.10 branch. |
… with ranges (pythonGH-28575) (cherry picked from commit 20f439b) Co-authored-by: Pablo Galindo Salgado <[email protected]>
… with ranges (GH-28575) (cherry picked from commit 20f439b) Co-authored-by: Pablo Galindo Salgado <[email protected]>
… with ranges (GH-28575) (cherry picked from commit 20f439b) Co-authored-by: Pablo Galindo Salgado <[email protected]>
| - :attr:`text` For syntax errors - the text where the error | ||
| occurred. | ||
| - :attr:`offset` For syntax errors - the offset into the text where the | ||
| error occurred. | ||
| - :attr:`end_offset` For syntax errors - the offset into the text where the | ||
| error occurred. Can be `None` if not present. |
There was a problem hiding this comment.
It is not None, but an unset attribute for non-SyntaxErrors, since it gets set for if exc_type and issubclass(exc_type, SyntaxError) only.
I think it should either get initialized always (to None), or at least the doc should get fixed (both places above).
There was a problem hiding this comment.
I think it should either get initialized always (to None), or at least the doc should get fixed (both places above).
I disagree. The text is the same as for other syntax errors fields. It says:
attr:
end_offsetFor syntax errors
the same way offset is also for syntax errors:
:attr:
offsetFor syntax errors
The thing here is that end_offset can be None if not present even for syntax errors.
| offset = self.offset | ||
| end_offset = self.end_offset if self.end_offset is not None else offset | ||
| if offset == end_offset or end_offset == -1: | ||
| end_offset = offset + 1 |
There was a problem hiding this comment.
I've noticed that self.end_offset is 0 with https://bugs.python.org/msg403588 (https://bugs.python.org/issue45249).
This might boil down to / coming from the C code using -1 for "not given/used", and then 1 being added, and therefore 0 should also get handled as "no end offset provided, use a length of 1".
https://bugs.python.org/issue45249