I think we may want to add a finalize() or close() method on frame objects which would clear all local variables (as well as dereference the globals dict, perhaps), after having optionally run a generator's close() method (if the frame belongs to a generator).If I'm not mistaken, it should allow breaking reference cycles, and remove the need for complex traceback processing, which Twisted currently also does:http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py#L89Note that generator cleanup through the frame has a patch inissue17807.(spinned off fromissue17911)

Here is a patch. Guido, I would hope this may be useful to you.

Updated patch to avoid clearing executing frames.Note that the new f_executing member should be re-usable to compute gi_running without storing it.

Mostly looks good to me, but I think I'd prefer that attempts to clear a running frame raise RuntimeError with an appropriate message.I also wonder how this might relate to Eric Snow's proposal to reference the currently executing function from the frame object (seeissue 12857). It seems to me that the "f_func" pointer in that patch could serve the same purpose as the "f_executing" boolean flag in this patch, while providing additional information about the execution context.Some other possibly relevant traceback related resource management issues:issue 6116,issue 1565525,issue 9815 (picked up while searching for Eric's RFE above)(We may want to add a "clear_frames" convenience method to tracebacks as well)

> Mostly looks good to me, but I think I'd prefer that attempts to clear> a running frame raise RuntimeError with an appropriate message.Hmm, why not. My intuition was to make frame.clear() a best-effortmethod, but this sounds ok too.> I also wonder how this might relate to Eric Snow's proposal to> reference the currently executing function from the frame object (see>issue 12857). It seems to me that the "f_func" pointer in that patch> could serve the same purpose as the "f_executing" boolean flag in this> patch, while providing additional information about the execution> context.Yes, perhaps. Then Eric's patch can incorporate that change once theframe.clear() patch is committed.> (We may want to add a "clear_frames" convenience method to tracebacks> as well)That, or in the traceback module. The reason I'm proposing this one as aframe method is that it can't be done in pure Python.

+1 to all Antoine's replies :)

Here is an alternative patch raising RuntimeError on executing frames.Please tell which one you prefer :)

Updated patch addressing some of Nick's comments.

A downside of using this is that some extended traceback printers (such as cgitb.py in the stdlib, or and some things I've seen in web frameworks) won't be able to print the locals.  And pdb's pm() function would lose its value too.  So it'll remain a judgment call whether to use this.As for Tulip, I think I've broken the cycle I was most concerned about, and I've also gotten rid of the lambda that cost me so much time debugging. :-)

I will probably wait forPEP 442 adoption before finalizing this issue.

I may be safer to initialize f->f_executing to 1 at the creation of the frame, and only change its value to 0 when the execution is done. (The name of the attribute may also be changed.) I don't know if it is possible, but a frame should not be cleared just before it is used to execute code.

Here is an updated patch. Any objections to committing?

New changeset862ab99ab570 by Antoine Pitrou in branch 'default':Issue#17934: Add a clear() method to frame objects, to help clean up expensive details (local variables) and break reference cycles.http://hg.python.org/cpython/rev/862ab99ab570

Ok, I committed the RuntimeError-raising version.