Author john.admanski
Recipients john.admanski, pitrou
Date 2010-09-14.00:03:01
SpamBayes Score 1.69396e-05
Marked as misclassified No
Message-id <>
I'm not sure that's much of an improvement on the existing behavior, though; as I mentioned you can already work around it by killing all the references to the ZipExtFile and the underlying file object will get automatically closed if the ZipExtFile is the only object using it, so adding an explicit __del__ that does the same thing isn't much of an improvement.

Since ZipExtFile is supposed to be a file-like object (albeit a read-only one) it would make sense to be able to release the underlying resources the same way you normally do with a closing it.
Date User Action Args
2010-09-14 00:03:04john.admanskisetrecipients: + john.admanski, pitrou
2010-09-14 00:03:04john.admanskisetmessageid: <>
2010-09-14 00:03:02john.admanskilinkissue9846 messages
2010-09-14 00:03:01john.admanskicreate