[Python-ideas] Standard way to get caller name and easy call stack access
ericsnowcurrently at gmail.com
Wed Mar 28 03:24:37 CEST 2012
On Tue, Mar 27, 2012 at 10:32 AM, Sven Marnach <sven at marnach.net> wrote:
> Nick Coghlan schrieb am Tue, 27. Mar 2012, um 23:00:49 +1000:
>> There are other potentially beneficial use cases for the new
>> qualname attribute as well (e.g. the suggestion of using it in
>> tracebacks instead of __name__ is a good idea)
> I think that including the qualified name in tracebacks would indeed
> be an worthwhile improvement, and it would be nice if this could be
> included in 3.3. It would put __qualname__ to an excellent use.
There is already an outstanding issue on co_qualname .
> There are some open questions to adding a 'co_qualname' attribute.
The same questions stand for adding a co_func (for the function whose
definition resulted in the code object) . I'd rather have a
co_func than a co_qualname. Then you can do
> 1. What should be done for code objects that don't correspond to
> something having a __qualname__, like list comprehensions? There
> are two options: Using "function_name.<locals>.<listcomp>", similar
> to lambda functions, or simply using 'None' or the same string as
> 'co_name' to avoid the overhead of computing a qualified name for
> every code object.
> 2. What about module names and PEP 395 qualified module names? One
> option would of course be to add both of them to the code object as
> well. Steven D'Aprano suggested giving full access to the function
> objects instead. The function object cannot be referenced in the
> code object, though, because this would create reference cycles in
> CPython. It *can* be referenced in the frame object (and this way,
> the change would only affect implementations having stack frames in
> the first place). This would only partially solve the use case of
> including qualified names in the traceback, since it only covers
> functions, not modules and classes. (For classes, we can't do
> something like this anyway, since the class object does not yet
> exist while the class body code executes.)
> What would have to be done to push this proposal?
I'm all for introspection, but I think it needs to be exposed
carefully. Otherwise those APIs become attractive nuisances. An
implicit self-referencing name (like __function__) in a function's
locals is one such example where it would be nice, but would likely
get abused (a concern that Guido had).
 discussion starting here:
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas