[Python-Dev] Evil reference cycles caused Exception.traceback (original) (raw)

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