On 6/30/2021 12:30 PM, Ammar Askar wrote:
I don't think we're making strong claims that the full `(line,
end_line, column, end_column)` should be the canonical representation
for exception locations. The only concrete place we suggest their
usage is in the printing of tracebacks.
sys.__excepthook__ will have access to the information, but will censor
it for long lines or slices that span more than one line.
The information is not exposed
in the exception or traceback objects intentionally as part of this.
Then how will modules that customizes traceback presentation, such as
idlelib, be able to get the 4-tuple for a particular traceback entry?
This seems like a repeat of attribute and name error name hints being
not accessible from the traceback module and only accessible from Python
via a workaround such as in idlelib.run: 218:
if typ in (AttributeError, NameError):
# 3.10+ hints are not directly accessible from python (#44026).
err = io.StringIO()
with contextlib.redirect_stderr(err):
sys.__excepthook__(typ, exc, tb)
return [err.getvalue().split("\n")[-2] + "\n"]
As Pablo explained on #44026, the length hints are not part of the tb
object because they are expensive to compute and are not useful when
AttributeError and NameError are expected and are caught in code for
flow control purposes. Therefore the hints are only computed when an
uncaught exception is displayed to users.
However, the position information is already computed and it is just a
matter of passing it along *all the way* to the python coder.
For slices within normal lines, the new caret line can be turned back
into position, as IDLE does now for SyntaxErrors. But that does not
work when the caret represents a truncated slice.
The PEP says co_positions will be added code objects but makes no
mention of an API for accessing information within it. And that still
leaves the issue of getting the code object.
Summary: the position information would be much more useful if it were
added to traceback items and if the traceback functions then exposed it.
Note: the current co_lines and co_linetable seems to be undocumented --
no index entries, nothing in
https://docs.python.org/3.11/reference/datamodel.html#index-56
and no docstring for co_lines. So I have no idea how these work.
Note 2: "Opt-out mechanism" says new environmental variable, new
-Xnodebugranges flag. "Have a configure flag to opt out" says "we have
decided to the -O flag". I presume the latter is obsolete.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RQYVQXJXZRLCWXVXKICJXB2RQLL2ZEXM/
Code of Conduct: http://python.org/psf/codeofconduct/
