3.11 backtrace visual indicators are too verbose #93883

belm0 · 2022-06-16T01:46:13Z

I understand that the new visual indicators can be disabled, but we shouldn't have to choose between guaranteed 50% longer backtraces and pertinent column information.

Often, the visual indicator spans the entire line for a large percentage of the backtrace. (I've seen cases in our app where it's true for 100% of the backtrace.)

Proposal: elide the indicators when they span the whole line

Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws more attention to the remaining (very relevant) indicators.

before:

Traceback (most recent call last):
  File "query.py", line 99, in <module>
    bar()
    ^^^^^
  File "query.py", line 66, in bar
    foo()
    ^^^^^
  File "query.py", line 37, in foo
    magic_arithmetic('foo')
    ^^^^^^^^^^^^^^^^^^^^^^^
  File "query.py", line 18, in magic_arithmetic
    return add_counts(x) / 25
           ^^^^^^^^^^^^^
  File "query.py", line 24, in add_counts
    return 25 + query_user(user1) + query_user(user2)
                ^^^^^^^^^^^^^^^^^
  File "query.py", line 32, in query_user
    return 1 + query_count(db, response['a']['b']['c']['user'], retry=True)
                               ~~~~~~~~~~~~~~~~~~^^^^^
TypeError: 'NoneType' object is not subscriptable

after:

Traceback (most recent call last):
  File "query.py", line 99, in <module>
    bar()
  File "query.py", line 66, in bar
    foo()
  File "query.py", line 37, in foo
    magic_arithmetic('foo')
  File "query.py", line 18, in magic_arithmetic
    return add_counts(x) / 25
           ^^^^^^^^^^^^^
  File "query.py", line 24, in add_counts
    return 25 + query_user(user1) + query_user(user2)
                ^^^^^^^^^^^^^^^^^
  File "query.py", line 32, in query_user
    return 1 + query_count(db, response['a']['b']['c']['user'], retry=True)
                               ~~~~~~~~~~~~~~~~~~^^^^^
TypeError: 'NoneType' object is not subscriptable

The text was updated successfully, but these errors were encountered:

Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws even more attention to the remaining (very relevant) indicators. Example: ``` Traceback (most recent call last): File "query.py", line 99, in <module> bar() File "query.py", line 66, in bar foo() File "query.py", line 37, in foo magic_arithmetic('foo') File "query.py", line 18, in magic_arithmetic return add_counts(x) / 25 ^^^^^^^^^^^^^ File "query.py", line 24, in add_counts return 25 + query_user(user1) + query_user(user2) ^^^^^^^^^^^^^^^^^ File "query.py", line 32, in query_user return 1 + query_count(db, response['a']['b']['c']['user'], retry=True) ~~~~~~~~~~~~~~~~~~^^^^^ TypeError: 'NoneType' object is not subscriptable ``` WORK IN PROGRESS TODO: * C traceback implementation * update documentation

belm0 · 2022-06-19T05:10:09Z

I've prototyped the change for traceback.py. Making the equivalent change to C traceback code and updating documentation is still required. I'd like to hear if this change has some support from Python devs before putting more time into the PR.

Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws even more attention to the remaining (very relevant) indicators. Example: ``` Traceback (most recent call last): File "query.py", line 99, in <module> bar() File "query.py", line 66, in bar foo() File "query.py", line 37, in foo magic_arithmetic('foo') File "query.py", line 18, in magic_arithmetic return add_counts(x) / 25 ^^^^^^^^^^^^^ File "query.py", line 24, in add_counts return 25 + query_user(user1) + query_user(user2) ^^^^^^^^^^^^^^^^^ File "query.py", line 32, in query_user return 1 + query_count(db, response['a']['b']['c']['user'], retry=True) ~~~~~~~~~~~~~~~~~~^^^^^ TypeError: 'NoneType' object is not subscriptable ``` WORK IN PROGRESS TODO: * C traceback implementation * update documentation

Zac-HD · 2022-06-23T05:43:11Z

I am very, very keen on this change! Thanks very much @belm0 for thinking of this and implementing a patch 😍

Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws even more attention to the remaining (very relevant) indicators. Example: ``` Traceback (most recent call last): File "query.py", line 99, in <module> bar() File "query.py", line 66, in bar foo() File "query.py", line 37, in foo magic_arithmetic('foo') File "query.py", line 18, in magic_arithmetic return add_counts(x) / 25 ^^^^^^^^^^^^^ File "query.py", line 24, in add_counts return 25 + query_user(user1) + query_user(user2) ^^^^^^^^^^^^^^^^^ File "query.py", line 32, in query_user return 1 + query_count(db, response['a']['b']['c']['user'], retry=True) ~~~~~~~~~~~~~~~~~~^^^^^ TypeError: 'NoneType' object is not subscriptable ``` WORK IN PROGRESS TODO: * C traceback implementation * update documentation

belm0 · 2022-06-24T14:28:02Z

PR #93994 is ready for review

* gh-93883: elide traceback indicators when possible Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws even more attention to the remaining (very relevant) indicators. Example: ``` Traceback (most recent call last): File "query.py", line 99, in <module> bar() File "query.py", line 66, in bar foo() File "query.py", line 37, in foo magic_arithmetic('foo') File "query.py", line 18, in magic_arithmetic return add_counts(x) / 25 ^^^^^^^^^^^^^ File "query.py", line 24, in add_counts return 25 + query_user(user1) + query_user(user2) ^^^^^^^^^^^^^^^^^ File "query.py", line 32, in query_user return 1 + query_count(db, response['a']['b']['c']['user'], retry=True) ~~~~~~~~~~~~~~~~~~^^^^^ TypeError: 'NoneType' object is not subscriptable ``` Rather than going out of our way to provide indicator coverage in every traceback test suite, the indicator test suite should be responible for sufficient coverage (e.g. by adding a basic exception group test to ensure that margin strings are covered).

) * pythongh-93883: elide traceback indicators when possible Elide traceback column indicators when the entire line of the frame is implicated. This reduces traceback length and draws even more attention to the remaining (very relevant) indicators. Example: ``` Traceback (most recent call last): File "query.py", line 99, in <module> bar() File "query.py", line 66, in bar foo() File "query.py", line 37, in foo magic_arithmetic('foo') File "query.py", line 18, in magic_arithmetic return add_counts(x) / 25 ^^^^^^^^^^^^^ File "query.py", line 24, in add_counts return 25 + query_user(user1) + query_user(user2) ^^^^^^^^^^^^^^^^^ File "query.py", line 32, in query_user return 1 + query_count(db, response['a']['b']['c']['user'], retry=True) ~~~~~~~~~~~~~~~~~~^^^^^ TypeError: 'NoneType' object is not subscriptable ``` Rather than going out of our way to provide indicator coverage in every traceback test suite, the indicator test suite should be responible for sufficient coverage (e.g. by adding a basic exception group test to ensure that margin strings are covered). (cherry picked from commit da71751) Co-authored-by: John Belmonte <john@neggie.net>

belm0 added the type-bug label Jun 16, 2022

arhadthedev mentioned this issue Jun 19, 2022

gh-93883: elide traceback indicators when possible #93994

Merged

2 tasks

miss-islington mentioned this issue Jul 11, 2022

[3.11] gh-93883: elide traceback indicators when possible (GH-93994) #94734

Closed

3.11 backtrace visual indicators are too verbose #93883

3.11 backtrace visual indicators are too verbose #93883

belm0 commented Jun 16, 2022 •

edited

belm0 commented Jun 19, 2022

Zac-HD commented Jun 23, 2022

belm0 commented Jun 24, 2022 •

edited

3.11 backtrace visual indicators are too verbose #93883

3.11 backtrace visual indicators are too verbose #93883

Comments

belm0 commented Jun 16, 2022 • edited

Proposal: elide the indicators when they span the whole line

belm0 commented Jun 19, 2022

Zac-HD commented Jun 23, 2022

belm0 commented Jun 24, 2022 • edited

belm0 commented Jun 16, 2022 •

edited

belm0 commented Jun 24, 2022 •

edited