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

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

Daniel Holth dholth at gmail.com
Tue Feb 24 20:23:05 CET 2015

On Tue, Feb 24, 2015 at 1:58 PM, Guido van Rossum <guido at python.org> wrote:

[Sorry, accidentally dropped the list from this message.]

Here's my review. I really like where this is going but I have a few questions and suggestions (I can't help myself :-). [I sneaked a peek at the update you sent to peps at python.org.] "Currently, pyyzer [5] and pex [6] are two tools known to exist." -> "... are two such tools." It's not stated whether the archive names include the .pyz[w] extension or not (though I'm guessing it's not -- this should be stated). The naming of the functions feels inconsistent -- maybe pack(directory, target) -> createarchive(directory, archive), and setinterpreter() -> copyarchive(archive, newarchive)? Why no command-line equivalent for the other two methods? I propose the following interface: if there's only one positional argument, we're asking to print its shebang line; if there are two and the input position is an archive instead of a directory, we're copying. (In the future people will want an option to print more stuff, e.g. the main function or even a full listing.) I've not seen the pkg.mod:fn notation before. Where is this taken from? Why can't it be pkg.mod.fn?

Translates to import pkg.mod; pkg.mod.fn() with no exception handling to figure out which part is importable. pkg.mod:ob.prop.fn would turn into import pkg.mod; pkg.mod.ob.prop.fn()

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.

More information about the Python-Dev mailing list