[Python-ideas] Add a .pop() method to ZipFile

[Daniel Holth]

On Fri, May 10, 2013 at 11:53 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On May 10, 2013, at 6:22, Masklinn <masklinn at masklinn.net> wrote:
>
>> Although technically it's only simple if you assume file content and
>> central directory entries are in the same order, which is unwarranted.
>
> Correct me if I'm wrong, but you can detect this case, and the case where there's a gap between the last file and the directory, and anything else that would break this code, just by parsing the directory, right?
>
>> So, guessing it's because you can do a half-assed job at implementing
>> pop(), it will usually work (and will silently corrupt your archive
>> when it does not)
>
> ... but a version that had the checks would instead usually work, and raise an exception when it does not.
>
> If I'm right, that's just a reason to fix the implementation, not to throw the idea out.

The improved implementation would need to sort the central directory
entries by the location of their data, making sure the files to be
affected had no extra bytes between them and did not overlap. Archives
created by zipfile follow those rules already.

> That being said, I'm still not sure what the benefit is. Sure, you could use a zipfile as a stack of temporary files or something, but it's still going to be slower than just a temp dir full of gzip files. Or you could destructively recursive-process a zipfile (reversed), but why? There must be a use case I'm missing that made the OP write this in the first place.

I wrote it because the last file in a particular zip archive is an
embedded digital signature. To re-sign the file you may remove the
file, add or remove signatures from that file, and append the new
signatures file.