Hi Terry,
Thanks for your message!
> Then how will modules that customizes traceback presentation, such as
idlelib, 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 using
the 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 :)
Pablo
On Wed, 30 Jun 2021 at 22:16, Terry Reedy <tjre...@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-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/
>
_______________________________________________
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/Y5BYJ4XXY4EHIDUCZD3BO3VWMXQHJP2I/
Code of Conduct: http://python.org/psf/codeofconduct/
