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 serhiy.storchaka
Recipients Arfrever, akira, benjamin.peterson, martin.panter, piotr.dobrogost, pitrou, serhiy.storchaka, stutzbach, vstinner
Date 2016-03-26.06:59:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458975584.35.0.496380367141.issue19829@psf.upfronthosting.co.za>
In-reply-to
Content
> Serhiy: why did you add 2.7 to this bug? For 2.7, I don’t think anything should be done. There is no ResourceWarning in 2.7.

Just for the case.

Not calling close() in __del__() is one option, and it looks attractive. But there are possible hidden catches. There is no guarantee that flush() writes all buffered data, some stateful encoder or compressor can left some data in the buffer unless explicitly closed. close() can write required footer or close connection. If not call close() in __del__(), GzipFile will produce incorrect file.

May be this is appropriate. This is why explicit close() should be called or context manager should be used.

Other option is to use some API through all closable objects. _dealloc_warn() is not the only option.

1. Add an optional parameter to close() methods to denote that it is called from __del__. This is backward incompatible option, it is too late to do this.

2. __del__() calls special method instead of close() if exists.

3. The _dealloc_warn() option (the name should be changed). The wrapper delegates emitting a warning to wrapped object by calling the _dealloc_warn() method if exists. Unlike to previous option this method is called in addition to close(), not instead.

4. The wrapper checks special attribute (or calls a method) of wrapped object. If it exists and is true, the wrapper emits a warning.
History
Date User Action Args
2016-03-26 06:59:44serhiy.storchakasetrecipients: + serhiy.storchaka, pitrou, vstinner, benjamin.peterson, stutzbach, Arfrever, akira, martin.panter, piotr.dobrogost
2016-03-26 06:59:44serhiy.storchakasetmessageid: <1458975584.35.0.496380367141.issue19829@psf.upfronthosting.co.za>
2016-03-26 06:59:44serhiy.storchakalinkissue19829 messages
2016-03-26 06:59:43serhiy.storchakacreate