Message375964
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:56 | jaraco | set | recipients:
+ jaraco, xtreak, bustawin |
2020-08-26 22:06:56 | jaraco | set | messageid: <1598479616.68.0.394914200655.issue40564@roundup.psfhosted.org> |
2020-08-26 22:06:56 | jaraco | link | issue40564 messages |
2020-08-26 22:06:56 | jaraco | create | |
|