[Python-Dev] Fwd: Request for Pronouncement: PEP 441 (original) (raw)

[Python-Dev] Fwd: Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

Paul Moore p.f.moore at gmail.com
Tue Feb 24 20:33:57 CET 2015

On 24 February 2015 at 19:23, Daniel Holth <dholth at gmail.com> wrote:

I'd specify that when the output argument is a file open for writing, it is the caller's responsibility to close the file. Also, can the file be a pipe? (I.e. are we using seek()/tell() or not?) And what about the input archive? Can that be a file open for reading? It seems like the very next thing I would want after trying pack() would be to pass a callback that returns True iff a file should be included in the archive. After that I might just want a ZipFile subclass or a regular ZipFile to which I could add my own files? "return ZipFile with shebang already filled in". It's hard for me to say where the boundary between the convenience API and re-implementing this simple thing yourself if you have complex needs should be.

Yes, it's a slippery slope.

The whole API is a pretty thin wrapper over a ZipFile object. I'd rather keep it to the most basic requirements, and defer anything even slightly complicated to the ZipFile API. The one exception is the set_interpreter/get_interpreter APIs, which are messy to do with ZipFile, and a pain to do "by hand" (because working with part-text, part-binary files is just naturally messy).

It would be possible to write up how easy it is to create a pyz file by hand using the zipfile module, but doing so would (IMO) lose the nice simple message of this PEP - "use zipapp to bundle your code into an app that's supported all the way back to Python 2.6".

Paul

More information about the Python-Dev mailing list