Use code.co_qualname to provide richer information

[c9f73e94-5cae-4a7c-81f2-f7364bbee5df]

BPO	46652
Nosy	@aroberge, @pablogsal, @P403n1x87, @sweeneyde
PRs	python/cpython#31150

^{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-feature', '3.11'] title = 'Use code.co_qualname to provide richer information' updated_at = user = 'https://github.com/P403n1x87' ``` bugs.python.org fields: ```python activity = actor = 'Gabriele Tornetta' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'Gabriele Tornetta' dependencies = [] files = [] hgrepos = [] issue_num = 46652 keywords = ['patch'] message_count = 3.0 messages = ['412598', '412616', '412622'] nosy_count = 4.0 nosy_names = ['aroberge', 'pablogsal', 'Gabriele Tornetta', 'Dennis Sweeney'] pr_nums = ['31150'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue46652' versions = ['Python 3.11'] ```

[c9f73e94-5cae-4a7c-81f2-f7364bbee5df]

https://bugs.python.org/issue44530 introduced the co_qualname field to code objects. This could be used to, e.g. enrich the information provided by tracebacks. Consider this simple example

import traceback

```py
class Bogus:
    def __init__(self):
        traceback.print_stack()
        raise RuntimeError("Oh no!")

class Foo:
    def __init__(self):
        Bogus()

Foo()

The current output is

```pytb
~~~
❯ python3.10 test_tb_format.py                                                                                       
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in __init__
    traceback.print_stack()
Traceback (most recent call last):
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in __init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in __init__
    raise RuntimeError("Oh no!")
RuntimeError: Oh no!
~~~

The proposed change is to use the co_qualname field instead of coname to provide more immediate information about the distinct functions \_init__, viz.

~~~
❯ ./python test_tb_format.py   
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in Foo.__init__
    Bogus()
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 6, in Bogus.__init__
    traceback.print_stack()
Traceback (most recent call last):
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 15, in <module>
    Foo()
    ^^^^^
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 12, in Foo.__init__
    Bogus()
    ^^^^^^^
  File "/home/gabriele/Projects/cpython/test_tb_format.py", line 7, in Bogus.__init__
    raise RuntimeError("Oh no!")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Oh no!
~~~

This makes it clear that two distinct __init__ functions are involved, without having to look at sources.

[sweeneyde]

Similar changes at bpo-40679 accidentally broke Cython when it was assumed that co_qualname was non-null, which was then fixed by defaulting to co_name in that case. I don't know if Cython still produces cases like that, but we should make sure not to needlessly break such cases if it does.

[c9f73e94-5cae-4a7c-81f2-f7364bbee5df]

code.co_qualname was introduced in 2021 with bpo-44530 and shuold give the same guarantees as code.coname. The \_qualname__ attribute is derived from code.co_qualname, so perhaps Cython can benefit from accessing code.co_qualname directly instead?

[gvanrossum]

If you want another go at this, maybe bring it up on Discourse (discuss.python.org) and see if there's appetite for a PEP? I'm supportive.