[Python-Dev] Evil reference cycles caused Exception.__traceback__

Nick Coghlan ncoghlan at gmail.com
Mon Sep 18 06:07:42 EDT 2017


On 18 September 2017 at 19:48, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 18 Sep 2017 11:31:12 +0200
> Victor Stinner <victor.stinner at gmail.com> wrote:
>>
>> Ideally, CPython 3.x should never create reference cycles. Removing
>> Exception.__traceback__ is the obvious "fix" for the issue. But I
>> expect that slowly, a lot of code started to rely on the attribute,
>> maybe even for good reasons :-)
>
> The real issue is not reference cycles, but the fact that a traceback
> frame keeps all locals alive.  When the frame's execution is finished,
> that information is practically almost always useless, but is kept for
> the rare cases of debugging (and perhaps dubious features such as
> some of py.test's magic).

As another use case, IPython tracebacks will include details of
referenced local variables, and
https://docs.python.org/3/library/traceback.html#tracebackexception-objects
offers the ability to readily capture the repr() of locals referenced
from a traceback for the same reason.

>  So we're constantly paying the price of this
> minor, albeit probably useful (*), debugging-related feature with
> annoying object lifetime issues that are sometimes quite difficult to
> track down and solve.
>
> (*) (I've hardly ever used pdb so I don't know if people often examine
> the locals of finished frames, but I suppose some do)
>
> Perhaps it would be useful to have a way to tell the interpreter to
> automatically clear all locals on frames when they have finished
> executing.  It could be a thread-local setting (or, better, a PEP 550
> context variable setting).

I wonder if it might be reasonable to have tracebacks only hold a weak
reference to their frame objects when "__debug__ == False".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list