PEP-3155 added qualified name as __qualname__ attribute in classes and functions. It would be useful if qualified name was also available as co_qualname attribute of code objects.

>>> import sys
>>> class A:
...     def f1():
...         return B.f2()
... 
>>> class B:
...     def f2():
...         return sys._getframe(1)
...
>>> A.f1.__name__
'f1'
>>> A.f1.__qualname__
'A.f1'
>>> B.f2.__name__
'f2'
>>> B.f2.__qualname__
'B.f2'
>>> frame = A.f1()
>>> frame
<frame object at 0x7f9c1adca3a0>
>>> frame.f_code
<code object f1 at 0x7f9c1ae4be40, file "<stdin>", line 2>
>>> frame.f_code.co_name
'f1'
>>> frame.f_code.co_qualname
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'code' object has no attribute 'co_qualname'


Suggested behavior:
>>> frame.f_code.co_qualname
'A.f1'

co_qualname could still be useful if somebody has code object without frame object.

True. I wonder, though if perhaps a co_func (as a weak ref) or co_orig_func would be better, since co_qualname would be built from the original function anyway. Then you could call "code.co_func.func_qualname".

One sticky point is that there isn't a guarantee of one-to-one between function object and code object. A code object could be bound to several different functions as happens with function definitions (particularly lambdas) inside comprehensions.

Also, if a code object is not associated with a function, i.e. one generated by exec, what should the qualname for the code object be? How about, in CPython, the code objects created for classes and modules?

On Wed, Dec 28, 2011 at 3:11 PM, Eric Snow <report@bugs.python.org> wrote:

One sticky point is that there isn't a guarantee of one-to-one between function object and code object.  A code object could be bound to several
different functions as happens with function definitions (particularly lambdas) inside comprehensions.

Also, if a code object is not associated with a function, i.e. one generated by exec, what should the qualname for the code object be?  How
about, in CPython, the code objects created for classes and modules?

We already these issues with 'co_name', though. These cases can be
treated the same as they are for 'co_name':

'<listcomp>'
>>> compile('[i for i in [1, 2]]', '<foo>', 'exec').co_consts[0].co_qualname
'<listcomp>'
>>> compile('class T: pass', '<foo>', 'exec').co_consts[0].co_qualname
'T'
>>> compile('class T: pass', '<foo>', 'exec').co_consts[0].co_name
'T'
>>> compile('a = 12', '<foo>', 'exec').co_name
'<module>'
>>> compile('a = 12', '<foo>', 'exec').co_qualname
'<module>'
>>> compile('lambda x: x', '<foo>', 'exec').co_consts[0].co_qualname
'<lambda>'
>>> compile('lambda x: x', '<foo>', 'exec').co_consts[0].co_name
'<lambda>'

This seems to be a useful feature to me. Another area where it can help
is with fixing function types. Currently the qualname can be lost:

>>> def f():
...    def g():
...       pass
...    return g
... 
>>> g = f()
>>> g
<function f.<locals>.g at 0x7f1dac4d8ba0>
>>> types.FunctionType(f.__code__, {})
<function f at 0x7f1dac4dfae0>
>>> types.FunctionType(g.__code__, {})

There is no way to specify a qualname when constructing a
'FunctionType'. The name is derived from the code object. The
qualname could be too if we fix this issue. I will open another issue
for the 'FunctionType' problem.

I have attached a WIP patch. It passes the full test suite. I am
somewhat unsure about the CAPI changes, though. They are a breaking API
change. Do we need a *_QualName version instead like we did for
'PyFunction_NewWithQualName'? I think probably so. I will add doc
updates to the patch once the API stuff gets worked out.

Could this patch be included in Python 3.3?

PyCode_New and PyCode_NewEmpty are documented public APIs, so you can't change their signatures like that.

Considering the API changes necessary for adding qualname, perhaps a better solution would be to just start using the qualname instead of the function's "basename"--co_name is the qualname. This would offer an automatic improvement to the readability of coverage/profiling tool reports. Admittedly, not sure what kind of breakage might ensue... =\

I think this would be very useful in tracebacks. If a traceback line had a more useful name like MyClass.__init__ instead of just __init__ or my_decorator.<locals>.wrapper instead of just wrapper it would provide useful context to the frame.