Title: Improving Python ZIP Application Support
Author: Daniel Holth <dholth(a)gmail.com>
Type: Standards Track
Created: 30 March 2013
Post-History: 30 March 2013, 1 April 2013
Improving Python ZIP Application Support
Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6. When invoked with a zip file or
directory as its first argument the interpreter adds that directory to
sys.path and executes the __main__ module. These archives provide a
great way to publish software that needs to be distributed as a single
file script but is complex enough to need to be written as a
collection of modules.
This feature is not as popular as it should be, mainly because no
one’s heard of it because it wasn’t promoted as part of Python 2.6,
but also because Windows users don’t have a file extension (other than
.py) to associate with the launcher.
This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP Applications”
and “Windowed Python ZIP Applications”, and providing some simple
tooling to manage the format.
A New Python ZIP Application Extension
The Python 3.4 installer will associate .pyz and .pyzw “Python ZIP
Applications” with the platform launcher so they can be executed. A
.pyz archive is a console application and a .pyzw archive is a
windowed application, indicating whether the console should appear
when running the app.
Why not use .zip or .py? Users expect a .zip file would be opened with
an archive tool, and users expect .py to be opened with a text editor.
Both would be confusing for this use case.
For UNIX users, .pyz applications should be prefixed with a #! line
pointing to the correct Python interpreter and an optional
# This is a Python application stored in a ZIP archive.
(binary contents of archive)
As background, ZIP archives are defined with a footer containing
relative offsets from the end of the file. They remain valid when
concatenated to the end of any other file. This feature is completely
standard and is how self-extracting ZIP archives and the bdist_wininst
installer format work.
Minimal Tooling: The pyzaa Module
This PEP also proposes including a simple application for working with
these archives: The Python Zip Application Archiver “pyzaa” (rhymes
with “huzzah” or “pizza”). “pyzaa” can archive or extract these files,
compile bytecode, and can write the __main__ module if it is not
python -m pyzaa (pack | compile)
python -m pyzaa pack [-o path/name] [-m module.submodule:callable]
[-c] [-w] [-p interpreter] directory:
ZIP the contents of directory as directory.pyz or [-w]
directory.pyzw. Adds the executable flag to the archive.
-c compile .pyc files and add them to the archive
-p interpreter include #!interpreter as the first line of the archive
-o path/name archive is written to path/name.pyz[w] instead of
dirname. The extension is added if not specified.
-m module.submodule:callable __main__.py is written as “import
pyzaa pack will warn if the directory contains C extensions or if
it doesn’t contain __main__.py.
python -m pyzaa compile arcname.pyz[w]
The Python files in arcname.pyz[w] are compiled and appended to
the ZIP file.
A standard ZIP utility or Python’s zipfile module can unpack the archives.
Q. Isn’t pyzaa just a very thin wrapper over zipfile and compileall?
Q. How does this compete with existing sdist/bdist formats?
A. There is some overlap, but .pyz files are especially interesting as
a way to distribute an installer. They may also prove useful as a way
to deliver applications when users shouldn’t be asked to perform
virtualenv + “pip install”.
 http://bugs.python.org/issue1739468 “Allow interpreter to execute
a zip file”
 http://bugs.python.org/issue17359 “Feature is not documented”
This document has been placed into the public domain.
I have reviewed the latest version of PEP 435 and I see that it is
very good. I hereby declare PEP 435 as Accepted. Congratulations go to
Barry, Eli and Ethan for pulling it through one of the most thorough
reviewing and bikeshedding processes any PEP has seen. Thanks to
everyone else for the many review comments. It is a better PEP because
of the reviews.
Barry or Eli, you can update the PEP's status. (I also expect there
will be some copy-editing still.)
Ethan: the stdlib implementation should probably be assigned a bug
tracker issue (if there isn't one already) and start code review now.
--Guido van Rossum (python.org/~guido)
I have 3 computer and want to contribute to the project,
Windows 7, Interl I5 64bits
Ubuntu 13.04, Interl I5 32bits
Ubuntu 13.04, Interl I5 64bits
How i can proceed? I'm nice in this world of free software and python
“Do not go where the path may lead, go instead where there is no path and
leave a trail.” - Ralph Waldo Emerson
One of the contended issues with PEP 435 on which Guido pronounced was the
functional API, that allows created enumerations dynamically in a manner
similar to namedtuple:
Color = Enum('Color', 'red blue green')
The biggest complaint reported against this API is interaction with pickle.
As promised, I want to discuss here how we're going to address this concern.
At this point, the pickle docs say that module-top-level classes can be
pickled. This obviously works for the normal Enum classes, but is a problem
with the functional API because the class is created dynamically and has no
To solve this, the reference implementation is used the same approach as
namedtuple (*). In the metaclass's __new__ (this is an excerpt, the real
code has some safeguards):
module_name = sys._getframe(1).f_globals['__name__']
enum_class.__module__ = module_name
According to an earlier discussion, this is works on CPython, PyPy and
Jython, but not on IronPython. The alternative that works everywhere is to
define the Enum like this:
Color = Enum('the_module.Color', 'red blue green')
The reference implementation supports this as well.
Some points for discussion:
1) We can say that using the functional API when pickling can happen is not
recommended, but maybe a better way would be to just explain the way things
are and let users decide?
2) namedtuple should also support the fully qualified name syntax. If this
is agreed upon, I can create an issue.
3) Antoine mentioned that work is being done in 3.4 to enable pickling of
nested classes (http://www.python.org/dev/peps/pep-3154/). If that gets
implemented, I don't see a reason why Enum and namedtuple can't be adjusted
to find the __qualname__ of the class they're internal to. Am I missing
4) Using _getframe(N) here seems like an overkill to me. What we really
need is just the module in which the current execution currently is (i.e.
the metaclass's __new__ in our case). Would it make sense to add a new
function somewhere in the stdlib of 3.4 (in sys or inspect or ...) that
just provides the current module name? It seems that all Pythons should be
able to easily provide it, it's certainly a very small subset of the
functionality provided by walking the callframe stack. This function can
then be used for build fully qualified names for pickling of Enum and
namedtuple. Moreover, it can be general even more widely - dynamic class
building is quite common in Python code, and as Nick mentioned somewhere
earlier, the extra power of metaclasses in the recent 3.x's will probably
make it even more common.
(*) namedtuple uses an explicit function to build the resulting class, not
a metaclass (ther's no class syntax for namedtuple).
To Python-Dev committers:
I am working on a project to embed a slightly customized Python interpreter in our own software. For easy installation and setup, we want to be able to do the standard Python installation as part of the installation of our product. So far I have successfully customized and built Python 3.3.1 (including the subprojects) on Windows but I can't find anything in the source distribution to allow me package the binaries/modules etc into a MSI just like the one on the download page on python.org. So I am asking for information regarding how to package Python build for installation on both Windows and *NIX platforms. Your help will be greatly appreciated.
In http://bugs.python.org/issue17807 I've committed a patch to allow
generator finalization (execution of "finally" blocks) even when a
generator is part of a reference cycle. If you have some workload
which is known for problems with generator finalization (or otherwise
makes a heavy use of generators), it would nice to have some feedback on
(the commit is only on the default branch)
I asked this question here,
. I was advised to ask here
On Wed, May 8, 2013 at 4:56 PM, Alok Nayak <aloknayak29(a)gmail.com> wrote:
> This python string literals documentation<http://docs.python.org/2/reference/lexical_analysis.html#string-literals>couldn't explain: single quote presence inside double quoted string and
> I think both double quoted string and single quoted string need to be
> defined differently for representing the 'stringliteral' lexical definition.
> shortstringchar ::= <any source character except "\" or newline or the quote>
> here in this definition 'the quote' isn't specific whether single (') or
> double (").
> Alok Nayak
> Gwalior, India