Author haypo
Recipients haypo, python-dev, serhiy.storchaka, yselivanov
Date 2016-03-19.01:25:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458350759.2.0.352065324425.issue26567@psf.upfronthosting.co.za>
In-reply-to
Content
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?).
History
Date User Action Args
2016-03-19 01:25:59hayposetrecipients: + haypo, python-dev, serhiy.storchaka, yselivanov
2016-03-19 01:25:59hayposetmessageid: <1458350759.2.0.352065324425.issue26567@psf.upfronthosting.co.za>
2016-03-19 01:25:59haypolinkissue26567 messages
2016-03-19 01:25:57haypocreate