This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vojtechfried
Recipients mark.dickinson, vojtechfried
Date 2017-07-24.12:59:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500901176.99.0.206197889018.issue31005@psf.upfronthosting.co.za>
In-reply-to
Content
Ok. As an input for a potential discussion:

Should all cases in the std library that store an exception be reported as a bug (because it can potentially mess with reference counting?) One such case is function create_connection in socket.py.

If "hold_world" is a function in an external code and the reference cycle problem only appears in an exceptional case it is hard to debug and it can hardly be easily fixed.

If "hold_world" is in an external code, it may be impossible to deal with. You can only diligently set to None or del in each function on the stack. But if you have a factory function that actually produces an object you don't want to be garbage collected, you can't set the reference to None before returning it.

It is surprising that the object is affected by a function that does not know about it. It is not stored globally, it is not passed to it. It just happens to be at a wrong time at a wrong place.

Should traceback.clear_frames clear the "back referenced" frames?
History
Date User Action Args
2017-07-24 12:59:37vojtechfriedsetrecipients: + vojtechfried, mark.dickinson
2017-07-24 12:59:36vojtechfriedsetmessageid: <1500901176.99.0.206197889018.issue31005@psf.upfronthosting.co.za>
2017-07-24 12:59:36vojtechfriedlinkissue31005 messages
2017-07-24 12:59:36vojtechfriedcreate