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 vstinner
Recipients python-dev, serhiy.storchaka, vstinner, yselivanov
Date 2016-03-19.01:25:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
It looks like io.FileIO has a strong implementation of the destructor. If the object becomes alive again because of random code called in the destructor, the object is not removed.

socket and os.scandir have a classical unsafe destructor.

Moreover, I'm no more sure about the chosen design. When warnings.catch_warnings() is used and an unclosed io.FileIO is destroyed, the object is kept alive because it is stored in the "source" attribute of a warnings.WarningMessage.

I don't know if keeping WarningMessaging alive longer than the call to showwarning() (or _showarnmsg) is a common use case or not. The issue #26568 wants to promote the WarningMessage class, so some users may start to keep it alive.

An alternative is to format the object traceback and pass the traceback to WarningMessage. It requires to decide the format of the traceback (list of ..., string, something else?).
Date User Action Args
2016-03-19 01:25:59vstinnersetrecipients: + vstinner, python-dev, serhiy.storchaka, yselivanov
2016-03-19 01:25:59vstinnersetmessageid: <>
2016-03-19 01:25:59vstinnerlinkissue26567 messages
2016-03-19 01:25:57vstinnercreate