Error.__traceback__.tb_lineno is wrong

[fc61c0bb-f966-4243-9268-ccd563dd4e77]

BPO	45191
Nosy	@markshannon, @pablogsal, @NaHCO314
PRs	python/cpython#28325 python/cpython#28753

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['interpreter-core', 'type-bug', '3.8', '3.9', '3.10', '3.11'] title = 'Error.__traceback__.tb_lineno is wrong' updated_at = user = 'https://github.com/NaHCO314' ``` bugs.python.org fields: ```python activity = actor = 'pablogsal' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'nahco314' dependencies = [] files = [] hgrepos = [] issue_num = 45191 keywords = ['patch'] message_count = 1.0 messages = ['401748'] nosy_count = 3.0 nosy_names = ['Mark.Shannon', 'pablogsal', 'nahco314'] pr_nums = ['28325', '28753'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue45191' versions = ['Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11'] ```

[fc61c0bb-f966-4243-9268-ccd563dd4e77]

I think that the emphasis of the errors caused by some of these equivalent expressions is wrong or inconsistent. expr1: 1 .bit_length("aaa") expr2: 1 \ .bit_length("aaa") expr3: 1 \ .bit_length(*["aaa"])

Below is the __traceback__.tb_lineno of the error given when running each version of the expression. (kubuntu20.0.4, CPython (pyenv)) The line number and location shown in the error message also correspond to this.

in 3.6.14, 3,7,11 expr1: 0 expr2: 1 expr3: 1

in 3.8.11, 3.9.6 expr1: 0 expr2: 0 expr3: 0

in 3.10.0rc1, 3.11-dev(3.11.0a0) expr1: 0 expr2: 1 expr3: 0

I think the results in 3.6.14 and 3.7.11 are correct.

[markshannon]

The current behavior (3.14a0) seems correct to me:

expr1: 0 expr2: 1 expr3: 1

For method calls, the line number matches that of the attribute, not the start of the call expression. This is to provide meaningful line events when calls are chained. See https://github.com/python/cpython/issues/83497.

[nahco314]

I now understand that the line number conforms to the position of the attribute. I have run the #83497 code through several evaluation strategies, and it certainly seems that behavior like 3.6.14, 3,7,11 would generate the best events. But even in the latest main, the traceback of these expressions still seems to be inconsistent:

Python 3.14.0a0 (heads/main:d9efa45d74, Jul 26 2024, 19:40:24) [GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 \
... .bit_length("aaa")
Traceback (most recent call last):
  File "<python-input-0>", line 2, in <module>
    .bit_length("aaa")
     ~~~~~~~~~~^^^^^^^
TypeError: int.bit_length() takes no arguments (1 given)

>>> 1 \
... .bit_length(*["aaa"])
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    1 \
    ~~~
    .bit_length(*["aaa"])
    ~~~~~~~~~~~^^^^^^^^^^
TypeError: int.bit_length() takes no arguments (1 given)

My PR gives error messages like the latter for both of the two expressions, but (given #83497) a more preferable behavior might be to show error messages like the former in both. At the very least, I think it should be standardized to one or the other.