Also, notice we are extending the traceback module (in Python) to support
this, so you probably can also leverage those changes so you don't need to
mess with code objects yourself :)

On Wed, 30 Jun 2021 at 22:29, Pablo Galindo Salgado <pablog...@gmail.com>
wrote:

> 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/CLHMM3I423I3K5SEWPBHFR6STAWX6S6E/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to