[Python-ideas] Standard way to get caller name and easy call stack access

[Eric Snow]

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 [1].

>
> 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) [2].  I'd rather have a
co_func than a co_qualname.  Then you can do
code.co_func.__qualname__.

>
> 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)[3].

-eric


[1] http://bugs.python.org/issue13672
[2] discussion starting here:
http://mail.python.org/pipermail/python-ideas/2011-August/011053.html
[3] http://mail.python.org/pipermail/python-ideas/2011-August/011062.html


>
> Cheers,
>    Sven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas