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.