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.

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... =\