Hi Terry,Thanks for your message!> Then how will modules that customizes traceback presentation, such asidlelib, be able to get the 4-tuple for a particular traceback entry?From the exception, you can get the code object and from the code object the extra information usingthe Python API:Example:>>> try:
... 1/0
... except Exception as e:
... f = e
...
>>> list(f.__traceback__.tb_frame.f_code.co_positions())
[(1, 4, 1, 8), (2, 2, 3, 4), (2, 2, 5, 6), (2, 2, 3, 6), (2, 2, 3, 6), (2, 4, 3, 8), (2, 4, 3, 8), (None, 2, 3, 6), (3, 4, 1, 8), (3, 3, 8, 17), (3, 4, 1, 8), (3, 4, 1, 8), (3, 4, 1, 8), (3, 4, 1, 8), (4, 4, 7, 8), (4, 4, 3, 4), (4, 4, 3, 8), (4, 4, 3, 8), (4, 4, 3, 8), (4, 4, 3, 8), (4, 4, 3, 8), (4, 4, 3, 8), (None, 4, 3, 8), (None, 4, 3, 8), (None, 4, 3, 8), (None, 4, 3, 8), (None, 4, 3, 8), (3, 4, 3, 8)]This is equivalent (and more efficient) to have this information in the traceback itself (as it would have been duplicated and would require more changes).We would document this a bit better with some examples. And we will make sure to add docs about this for sure :)PabloOn Wed, 30 Jun 2021 at 22:16, Terry Reedy <tjreedy@udel.edu> wrote: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-leave@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/