[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) -> create_archive(directory, archive), and set_interpreter() ->
> copy_archive(archive, new_archive)?
>
> 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