sorrow <lynx1...@gmail.com> added the comment:
>how common is this use-case I don't know about that. I just know that I have to make my program work with these files. Asking the clients to stop using this (presumably incorrect) format (or the program that makes it) is not an option. >It appears the file your client has sent and the minimal example you've >generated represents an invalid zip file. Well, I didn't know that. But it doesn't change the matter for me. >What I recommend is that you develop a subclass of zipfile.Path that supports >the abnormal format, use that for your work, and publish it (perhaps here, >perhaps as a library) for others with the same problem to use. I guess I'll have to go this way. >It opens up lots of questions, like: I'll share my considerations about how I see it should be implemented. >- should `at` include the leading slash? I think it doesn't matter, because `at` property is not part of `Path` public AP. Ideally, the files with leading slashes and without them should be treated exactly the same (as if they didn't have the leading slash). So, the only thing I'm concerned with is `at` argument of `Path.__init__`. It shouldn't require leading slash in any case. >- should the class support zip files with mixed leading and non-leading >slashes? No, this is definitely an error and shouldn't work. >- at what point does `Path` become aware of the format used? When the class is created? >- are there emergent performance concerns? For me - no, there aren't. I don't know how this kind of questions is resolved in python community though. >Can we close this as invalid? I guess you can. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41035> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
