On 15 February 2015 at 18:14, Paul Moore <p.f.mo...@gmail.com> wrote: > OTOH, if the pyz/pyzw extensions are already (or will be) registered > by the installer then the only remaining feature of this PEP [1] is > the archive creation app. And designing that as we go is probably the > wrong way to get something in the stdlib. Maybe it would be better to > put something on PyPI and let it develop outside the stdlib first? > There's already at least pyzaa and pyzzer available...
Perhaps rather than creating yet another implementation of this, we should just add some "See Also" links to the relevant parts of the command line usage guide and the runpy module documentation? Particularly if the modules are pip-installable and we add the cross-references to the 2.7 and 3.4 docs as well - we didn't install pip by default back when Daniel first wrote PEP 441. > [1] Apart from the benefit of publicising executable zip files as a > means of deploying Python code by mentioning them in a "What's new" > section :-) That will be covered to some degree by the mention of the file associations being registered on Windows, and we can try to persuade Larry it's worth mentioning in the release announcement itself :) The other option would to cut PEP 441 way back to *just* be about standardising and registering the file associations, and recommending the use of pip to obtain the build machinery with (whether pyzaa, pyzzer or Twitter's more comprehensive pex). It would be a short PEP, but potentially still worth it for the improved visibility of the decision when folks are trying to figure out what "pyz" and "pyzw" files are later. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
