[Python-Dev] Reference cycles in Exception.__traceback__

[Xavier Morel]

On 2014-03-06, at 16:52 , Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le 06/03/2014 16:03, Yury Selivanov a écrit :
>> 
>> On 2014-03-06, 8:42 AM, Antoine Pitrou wrote:
>>> Le 05/03/2014 23:53, Nick Coghlan a écrit :
>>>> 
>>>> __traceback__ wouldn't change [...]
>>> 
>>> Uh, really? If you want to suppress all reference cycles, you *have*
>>> to remove __traceback__.
>>> 
>>> The problem is to make computation of the traceback summary
>>> lightweight enough that it doesn't degrade performance in the common
>>> case where you don't have to print the traceback later.
>> 
>> So why can't we allow instantiation of types.TracebackType &
>> types.FrameType?
> 
> IMO it is absolutely out of question to allow creation of arbitrary frames from Python code, because the structure and initialization of frames embody too many low-level implementation details.
> 
> We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be.

Some bits of the standard library (and probably third-party libraries
transitively relying on getinnerframes) really, really want traceback
objects and can't be used with a stack or frames extracted via
inspect.currentframe() or whatever. For instance cgitb.text calls
inspect.getinnerframes which accesses param.tb_frame then calls
getframeinfo(param). getframeinfo blows up if it does not get either an
actual traceback object or an actual frame object.

A frame object does not have a tb_frame attribute, and will thus fail
in getinnerframes, a fake traceback object will fail in getframeinfo.

Therefore it's not possible to call cgitb.text outside of an exception
handling context (that is, not possible to use it as a
traceback.print_stack providing extra information). If it were possible
to create traceback objects, there would be no issue there at least.