You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2012-10-15.13:23:34.440>created_at=<Date2011-10-08.18:48:54.807>labels= ['library', 'expert-IO', 'performance']
title='FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()'updated_at=<Date2012-10-15.13:23:34.439>user='https://bugs.python.org/ValeryKhamenya'
"I can't reproduce this problem in either 2.7.2 or 3.3.0a0."
You probably mean CPython implementation of Python. No, I didn't mean this implementation.
"Do you mean that this problem is only reproducible when the attached
script is run with pypy?"
I can't say "only". I just could say yes, it is reproducible with pypy. Perhaps, there are others Python implementations that will suffer from the bug in current implementation of ZipFile
Yes, in 2.7 many parts of the stdlib relies on reference counting to close files. But 3.2 introduced a ResourceWarning which is emitted (in debug mode) each time a __del__ closes a valuable resource like a file or a socket. This was done exactly for this reason - help other implementations with a different garbage collector.
Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new member "close_fileobj", and the "with" statement in ZipFile.read().
PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply the same changes in pypy's own copy of zipfile.py.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: