[issue13672] Add co_qualname attribute in code objects

Change by Irit Katriel : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Propagate qualname from the compiler unit to code objects for finer grained profiling data ___ Python tracker

[issue13672] Add co_qualname attribute in code objects

Alex Hall added the comment: 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..wrapper` instead of just `wrapper` it would provide useful context to the frame. -- nosy: +al

[issue13672] Add co_qualname attribute in code objects

Changes by Berker Peksag : -- versions: +Python 3.5 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13672] Add co_qualname attribute in code objects

James Pye added the comment: 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/pr

[issue13672] Add co_qualname attribute in code objects

Antoine Pitrou added the comment: PyCode_New and PyCode_NewEmpty are documented public APIs, so you can't change their signatures like that. -- nosy: +georg.brandl stage: needs patch -> patch review ___ Python tracker

[issue13672] Add co_qualname attribute in code objects

Arfrever Frehtes Taifersar Arahesis added the comment: Could this patch be included in Python 3.3? -- ___ Python tracker ___ ___ Pyth

[issue13672] Add co_qualname attribute in code objects

Meador Inge added the comment: 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 .g at 0x7f1dac4d8ba0> >>> types.Function

[issue13672] Add co_qualname attribute in code objects

Meador Inge added the comment: On Wed, Dec 28, 2011 at 3:11 PM, Eric Snow 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 (par

[issue13672] Add co_qualname attribute in code objects

Changes by Meador Inge : -- nosy: +meador.inge stage: -> needs patch type: -> enhancement ___ Python tracker ___ ___ Python-bugs-lis

[issue13672] Add co_qualname attribute in code objects

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13672] Add co_qualname attribute in code objects

Eric Snow added the comment: 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

[issue13672] Add co_qualname attribute in code objects

Arfrever Frehtes Taifersar Arahesis added the comment: co_qualname could still be useful if somebody has code object without frame object. -- ___ Python tracker ___ ___

[issue13672] Add co_qualname attribute in code objects

Eric Snow added the comment: with f_func (see #12857) you would get that for free: >>> frame.f_func.__qualname__ 'A.f1' -- nosy: +eric.snow ___ Python tracker ___ _

[issue13672] Add co_qualname attribute in code objects

New submission from Arfrever Frehtes Taifersar Arahesis : 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(): ...