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 bustawin, jaraco, xtreak
Date 2020-08-26.22:06:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I see a few options here:

- Implement CompleteDirs/FastLookup as adapters instead of subclasses, allowing the original ZipFile object to represent the state in a single place. This approach would likely be slower due to the indirection on all operations through the wrapper.
- Instead of constructing a new object and copying the state, CompleteDirs.make could mutate the existing ZipFile class, replacing `source.__class__` with the new class. This approach is messy and the caller would still need to be aware that this change could be applied to the zipfile object.
- Consider this use-case unsupported and document that any ZipFile object passed into Path is no longer viable and should not be referenced for another purpose.
- Eliminate the class-based performance optimizations and replace them with some functional/imperative form. This approach may provide less separation of concerns.
- Disable the close-on-delete behavior for the subclasses when state is copied from another.
Date User Action Args
2020-08-26 22:06:56jaracosetrecipients: + jaraco, xtreak, bustawin
2020-08-26 22:06:56jaracosetmessageid: <>
2020-08-26 22:06:56jaracolinkissue40564 messages
2020-08-26 22:06:56jaracocreate