After closing a file object opened from a ZipFile, attempting i/o operations raises AttributeError because the underlying fd has been set to None. We should be raising ValueErrors consistent with io.FileIO behaviour. Similar inconsistencies exist for the following operations on a closed ZipExtFile: - seek - seekable - read - readable - tell

Could you please test what performance effect it has on read()?

Here's the script I used for profiling and the results I observed with and without the closed check in read: import zipfile test_zip = "time_test.zip" test_name = "test_name.txt" with zipfile.ZipFile(test_zip, "w") as zf: zf.writestr(test_name, "Hi there! " * 300) with zipfile.ZipFile(test_zip) as zf: for i in range(100000): zf.read(test_name) # Current code (no closed check), three different profiling sessions: # ncalls tottime percall cumtime percall filename:lineno(function) # 100000 0.612 0.000 6.638 0.000 zipfile.py:884(read) # 100000 0.598 0.000 6.489 0.000 zipfile.py:884(read) # 100000 0.600 0.000 6.485 0.000 zipfile.py:884(read) # With closed check, three different profiling sessions: # ncalls tottime percall cumtime percall filename:lineno(function) # 100000 0.632 0.000 6.587 0.000 zipfile.py:884(read) # 100000 0.623 0.000 6.564 0.000 zipfile.py:884(read) # 100000 0.638 0.000 6.700 0.000 zipfile.py:884(read) ------- I based this change on the what BytesIO does: https://github.com/python/cpython/blob/master/Lib/_pyio.py#L912 Let me know if you want me to make any changes.

Thank you Daniel. But profiling is not good for benchmarking, it adds too much overhead. It can help to find narrow places, but for measuring effect of optimization you need to measure the raw time on non-debug build. Semantically your changes are correct. I just want to know whether this adds a significant overhead. If it is, we should consider some kind of optimizations. It does not matter for Python implementation of BytesIO because in normal we use the C implementation.

Good point. Thanks for the advice. I've updated it to use timeit. Does that give a better indication? import zipfile test_zip = "time_test.zip" test_name = "test_name.txt" # with zipfile.ZipFile(test_zip, "w") as zf: # zf.writestr(test_name, "Hi there! " * 300) def test(): with zipfile.ZipFile(test_zip) as zf: for i in range(100000): zf.read(test_name) if __name__ == "__main__": import timeit print(timeit.repeat("test()", setup="from __main__ import test", number=1, repeat=10)) On my machine (running a usual workload) the best of 10 was: master: 3.812s check closed: 3.874s But I think my machine had a quite a bit of variance between runs.

 New changeset 8d62df60d8733d0fa9aee14ef746d0009a7a9726 by Serhiy Storchaka (Daniel Hillier) in branch 'master': bpo-37523: Raise ValueError for I/O operations on a closed zipfile.ZipExtFile. (GH-14658) https://github.com/python/cpython/commit/8d62df60d8733d0fa9aee14ef746d0009a7a9726