[Python-Dev] Reference cycles in Exception.__traceback__

[Yury Selivanov]

But having exceptions without '__traceback__' affects not
only the inspect module, but also lots of other code.  It
will make harder to write generic error reporting code, as
you'd need to check for __traceback__ first, and then, if
it's None, look for some other, asyncio specific attribute.

I think that having tracebacks with fake frames is much
more backwards compatible and consistent solution. I don't
understand why we should break the established protocol
here.

[Or we can allow instantiation of immutable frame objects
without __code__]

Yury

On 2014-03-06, 1:32 PM, Guido van Rossum wrote:
> But inspect is in the stdlib. Surely changing inspect.py is less
> controversial than amending the semantics of frame objects.
>
>
> On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel <python-dev at masklinn.net>wrote:
>
>> 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.
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com