search

jaraco / zipp

MIT License
61 stars 53 forks source link

Provide better support for unnamed zip files. #107

Closed jaraco closed 7 months ago

jaraco commented 1 year ago 
          > but is perhaps overwrought within a CPython context

I'm not sure I understand the distinction. zipp means to provide the same behavior (just earlier, to older Pythons), so the two implementations should be kept in sync.

IMO it would suffice to make the original ZipFile available...

And it does currently through .root, which has its own issues (the name conflicts with the meaning of pathlib.Path.root).

I don't like the implementation of Path.filename. I'm tempted to deprecate it altogether. __str__ provides something similar but different. .name, .parent and newly .suffix, .suffixes, and .stem all are ill-defined when the zipfile has no filename, so I believe an exception is appropriate in those cases.

But you're right, it's not great to not have a good __str__ representation if the zipfile has no name. I'll work on it.

Originally posted by @jaraco in https://github.com/python/cpython/issues/100609#issuecomment-1636331936

jaraco commented 1 year ago

I looked into this issue briefly yesterday and ascertained that it's not going to be an easy "fix". The original design intentionally did not attempt to provide full support for zip files without names, so providing such support is likely to break some (even documented) assumptions. Any fix is likely to be accompanied by a change in behavior that will likely preclude backporting. Users affected by this issue should supply a filename for their zipfile, even if it's just "<unnamed>".