Issue 13672: Add co_qualname attribute in code objects (original) (raw)
Created on 2011-12-28 19:19 by Arfrever, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (10)
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * 
Date: 2011-12-28 19:19
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.
>>> frame.f_codeimport 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
", line 2>
>>> frame.f_code.co_name
'f1'
>>> frame.f_code.co_qualname
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'code' object has no attribute 'co_qualname'
Suggested behavior:
frame.f_code.co_qualname
'A.f1'
Author: Eric Snow (eric.snow) * 
Date: 2011-12-28 20:08
with f_func (see #12857) you would get that for free:
frame.f_func.qualname
'A.f1'
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *
Date: 2011-12-28 20:36
co_qualname could still be useful if somebody has code object without frame object.
Author: Eric Snow (eric.snow) *
Date: 2011-12-28 21:11
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?
Author: Meador Inge (meador.inge) *
Date: 2012-01-24 19:41
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':
''
compile('[i for i in [1, 2]]', '', 'exec').co_consts[0].co_qualname
''
compile('class T: pass', '', 'exec').co_consts[0].co_qualname
'T'
compile('class T: pass', '', 'exec').co_consts[0].co_name
'T'
compile('a = 12', '', 'exec').co_name
''
compile('a = 12', '', 'exec').co_qualname
''
compile('lambda x: x', '', 'exec').co_consts[0].co_qualname
''
compile('lambda x: x', '', 'exec').co_consts[0].co_name
''
Author: Meador Inge (meador.inge) *
Date: 2012-01-24 20:09
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..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.
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *
Date: 2012-06-25 20:17
Could this patch be included in Python 3.3?
Author: Antoine Pitrou (pitrou) *
Date: 2012-06-25 20:20
PyCode_New and PyCode_NewEmpty are documented public APIs, so you can't change their signatures like that.
Author: James Pye (James.Pye)
Date: 2013-04-13 19:26
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... =\
Author: Alex Hall (alexmojaki)
Date: 2020-02-19 10:15
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.
History
Date
User
Action
Args
2022-04-11 14:57:25
admin
set
github: 57881
2021-12-30 00:20:44
iritkatriel
set
status: open -> closed
superseder: Propagate qualname from the compiler unit to code objects for finer grained profiling data
resolution: duplicate
stage: patch review -> resolved
2020-02-19 10:15:17
alexmojaki
set
nosy: + alexmojaki
messages: +
2014-07-03 08:36:34
berker.peksag
set
versions: + Python 3.5, - Python 3.3
2013-04-13 19:26:10
James.Pye
set
nosy: + James.Pye
messages: +
2012-06-25 20:20:07
pitrou
set
nosy: + georg.brandl
messages: +
stage: needs patch -> patch review
2012-06-25 20:17:38
Arfrever
set
messages: +
2012-01-24 20:09:55
meador.inge
set
files: + issue13672-v0.patch
keywords: + patch
messages: +
2012-01-24 19:41:25
meador.inge
set
messages: +
2011-12-28 23:11:17
meador.inge
set
nosy: + meador.inge
type: enhancement
stage: needs patch
2011-12-28 22:36:29
jcea
set
nosy: + jcea
2011-12-28 21:11:24
eric.snow
set
messages: +
2011-12-28 20:36:35
Arfrever
set
messages: +
2011-12-28 20:08:10
eric.snow
set
nosy: + eric.snow
messages: +
2011-12-28 19:19:59
Arfrever
create