| msg188718 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-05-08 11:54 |
| 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#L89 Note that generator cleanup through the frame has a patch in . (spinned off from ) |
|
|
| msg188950 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-11 19:20 |
| Here is a patch. Guido, I would hope this may be useful to you. |
|
|
| msg188952 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-11 20:04 |
| 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. |
|
|
| msg188974 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2013-05-12 04:31 |
| 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 (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. 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) |
|
|
| msg189016 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-12 11:11 |
| > 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-effort method, 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 the frame.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 a frame method is that it can't be done in pure Python. |
|
|
| msg189026 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2013-05-12 12:54 |
| +1 to all Antoine's replies :) |
|
|
| msg189109 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-13 08:57 |
| Here is an alternative patch raising RuntimeError on executing frames. Please tell which one you prefer :) |
|
|
| msg189149 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-13 15:48 |
| Updated patch addressing some of Nick's comments. |
|
|
| msg189151 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2013-05-13 17:07 |
| 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. :-) |
|
|
| msg189768 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-05-21 16:17 |
| I will probably wait for PEP 442 adoption before finalizing this issue. |
|
|
| msg189975 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-05-25 16:00 |
| 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. |
|
|
| msg194214 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-08-02 22:10 |
| Here is an updated patch. Any objections to committing? |
|
|
| msg194511 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-08-05 21:28 |
| New changeset 862ab99ab570 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 |
|
|
| msg194512 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-08-05 21:32 |
| Ok, I committed the RuntimeError-raising version. |
|
|