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 jaraco
Recipients Jeffrey.Kintscher, Nick Henderson, jaraco, rishi93
Date 2020-07-24.14:00:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I'm a little surprised from Nick's original post that the behavior is triggered. After all, the code [already has a protection for a previously-closed zipfile]( and that value is [unconditionally set during close]( So how is it that Zipfile.__del__ is being called?

Jeffrey suggests that

> a copy of the zip_file object is getting created, probably by the Path constructor

And indeed, I can confirm the ZipFile [state is copied into a new object here]( The FastLookup and CompleteDirs functionality is for performance optimizations.

> I created a simpler test case that exercises the buggy code.

Although the simpler test does trigger the error, I'd argue that the error is _expected_ in this case and that the zip file will be invalid because `self._write_end_record` will never get called.

I expected this example to more accurately capture the failure:

import io
import zipfile
buf = io.BytesIO()
zf = zipfile.ZipFile(buf, mode='w')
zp = zipfile.Path(zf)
with zp.joinpath('zile-a').open('w') as fp:
    fp.write(b'contents of file-a')

But it does not. I'll need to do more investigation.

One option here is for `Path` to document that any zipfile passed to it is no longer valid and enforce that fact by disabling the original object passed to it.

Another approach could be to try to use an adapter pattern to adapt the original ZipFile rather than clone it into a subclass.
Date User Action Args
2020-07-24 14:00:37jaracosetrecipients: + jaraco, Jeffrey.Kintscher, rishi93, Nick Henderson
2020-07-24 14:00:37jaracosetmessageid: <>
2020-07-24 14:00:37jaracolinkissue41350 messages
2020-07-24 14:00:36jaracocreate