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

[Paul Moore]

On 24 February 2015 at 18:24, Guido van Rossum  wrote:
> Here's my review. I really like where this is going but I have a few
> questions and suggestions (I can't help myself :-).

OK, I've updated both the PEP and the patch based on follow-up
discussions. I think (again!) it is ready to go.

I've included the updated PEP inline below, it'll be available at
peps.python.org as soon as someone has a chance to upload it.

Thanks to everyone for the various comments. If I've missed anything
that someone thinks I'd said I would change, please let me know.

Paul

PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth ,
Paul Moore 
Discussions-To:
https://mail.python.org/pipermail/python-dev/2015-February/138277.html
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 March 2013
Post-History: 30 March 2013, 1 April 2013, 16 February 2015

Improving Python ZIP Application Support


Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6 [1]_.  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 it was
not promoted as part of Python 2.6 [2]_, so that it is relatively
unknown, but also because the Windows installer does not register a
file extension (other than ``.py``) for this format of file, 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 terminology "Python Zip Application" will be the formal term used
for a zip-format archive that contains Python code in a form that can
be directly executed by Python (specifically, it must have a
``__main__.py`` file in the root directory of the archive).  The
extension ``.pyz`` will be formally associated with such files.

The Python 3.5 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.

On Unix, it would be ideal if the ``.pyz`` extension and the name
"Python Zip Application" were registered (in the mime types database?).
However, such an association is out of scope for this PEP.

Python Zip applications can be prefixed with a ``#!`` line
pointing to the correct Python interpreter and an optional
explanation::

#!/usr/bin/env python3
#  Python application packed with zipapp module
(binary contents of archive)

On Unix, this allows the OS to run the file with the correct
interpreter, via the standard "shebang" support.  On Windows, the
Python launcher implements shebang support.

However, it is always possible to execute a ``.pyz`` application by
supplying the filename to the Python interpreter directly.

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 zipapp Module
==

This PEP also proposes including a module for working with these
archives.  The module will contain functions for working with Python
zip application archives, and a command line interface (via ``python
-m zipapp``) for their creation and manipulation.

More complete tools for managing Python Zip Applications are
encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
and pex [6]_ are two such tools.

Module Interface


The zipapp module will provide the following functions:

``create_archive(source, target=None, interpreter=None, main=None)``


Create an application archive from *source*.  The source can be any
of the following:

* The name of a directory, in which case a new application archive
  will be created from the content of that directory.
* The name of an existing application archive file, in which case the
  file is copied to the target.  The file name should include the
  ``.pyz`` extension, if required.
* A file object open for reading in bytes mode.  The content of the
  file should be an application archive, and the file object is
  assum

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

[Glenn Linderman]

On 2/26/2015 9:05 AM, Paul Moore wrote:

On 24 February 2015 at 18:24, Guido van Rossum  wrote:

Here's my review. I really like where this is going but I have a few
questions and suggestions (I can't help myself :-).

OK, I've updated both the PEP and the patch based on follow-up
discussions. I think (again!) it is ready to go.

I've included the updated PEP inline below, it'll be available at
peps.python.org as soon as someone has a chance to upload it.

Thanks to everyone for the various comments. If I've missed anything
that someone thinks I'd said I would change, please let me know.


Three very, very, very minor nits below.



Paul

PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth ,
 Paul Moore 
Discussions-To:
https://mail.python.org/pipermail/python-dev/2015-February/138277.html
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 March 2013
Post-History: 30 March 2013, 1 April 2013, 16 February 2015

Improving Python ZIP Application Support


Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6 [1]_.  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 it was
not promoted as part of Python 2.6 [2]_, so that it is relatively
unknown, but also because the Windows installer does not register a
file extension (other than ``.py``) for this format of file, 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 terminology "Python Zip Application" will be the formal term used
for a zip-format archive that contains Python code in a form that can
be directly executed by Python (specifically, it must have a
``__main__.py`` file in the root directory of the archive).  The
extension ``.pyz`` will be formally associated with such files.

The Python 3.5 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.

On Unix, it would be ideal if the ``.pyz`` extension and the name
"Python Zip Application" were registered (in the mime types database?).
However, such an association is out of scope for this PEP.

Python Zip applications can be prefixed with a ``#!`` line
pointing to the correct Python interpreter and an optional
explanation::

 #!/usr/bin/env python3
 #  Python application packed with zipapp module
 (binary contents of archive)

On Unix, this allows the OS to run the file with the correct
interpreter, via the standard "shebang" support.  On Windows, the
Python launcher implements shebang support.

However, it is always possible to execute a ``.pyz`` application by
supplying the filename to the Python interpreter directly.

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 zipapp Module
==

This PEP also proposes including a module for working with these
archives.  The module will contain functions for working with Python
zip application archives, and a command line interface (via ``python
-m zipapp``) for their creation and manipulation.

More complete tools for managing Python Zip Applications are
encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
and pex [6]_ are two such tools.

Module Interface


The zipapp module will provide the following functions:

``create_archive(source, target=None, interpreter=None, main=None)``


Create an application archive from *source*.  The source can be any
of the following:

* The name of a directory, in which case a new application archive
   will be created from the content of that directory.
* The name of an existing application archive file, in which case the
   file is copied to the target.  The file name should include the
   ``.pyz`` extension, if required.


Or   ".pyzw", I presume.


* A file object ope

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

[Ethan Furman]

On 02/26/2015 09:28 AM, Glenn Linderman wrote:
> On 2/26/2015 9:05 AM, Paul Moore wrote:

>> ``create_archive(source, target=None, interpreter=None, main=None)``
>> 
>>
>> Create an application archive from *source*.  The source can be any
>> of the following:
>>
>> * The name of a directory, in which case a new application archive
>>   will be created from the content of that directory.
>> * The name of an existing application archive file, in which case the
>>   file is copied to the target.  The file name should include the
>>   ``.pyz`` extension, if required.
> 
> Or   ".pyzw", I presume.

Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a .pyz 
(or .py) file?

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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

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

[Paul Moore]

On 26 February 2015 at 17:28, Glenn Linderman  wrote:
> * The name of a directory, in which case a new application archive
>   will be created from the content of that directory.
> * The name of an existing application archive file, in which case the
>   file is copied to the target.  The file name should include the
>   ``.pyz`` extension, if required.
>
>
> Or   ".pyzw", I presume.

Yes.

> * If it is an open file object, the archive will be written to that
>   file object, which must be open for writing in bytes mode.
> * If the target is omitted (or None), the source must be a directory
>   and the target will be a file with the same name as the source, with
>   a ``.pyz`` extension added.
>
>
> Hmm. So one _must_ specify a target if one wants a .pyzw.

Correct. Generally I don't think pyzw will be used often, so I don't
see that as a major problem. I'll add a clarifying note if the PEP
needs another round of edits, but I'm inclined not to bother the PEP
editors if this is all that needs changing.

> The destination archive will have the specified name.  The
> given name will be used as written, so should include the
> ".pyz" extension.
>
>
> Or ".pyzw", I presume.  You used ``funny quotes`` around extensions earlier,
> but not here.

Again yes.
Normal quotes because this chunk is already in a literal block, so
``...`` is redundant.

Paul
___
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

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

[Paul Moore]

On 26 February 2015 at 18:23, Ethan Furman  wrote:
> On 02/26/2015 09:28 AM, Glenn Linderman wrote:
>> On 2/26/2015 9:05 AM, Paul Moore wrote:
>
>>> ``create_archive(source, target=None, interpreter=None, main=None)``
>>> 
>>>
>>> Create an application archive from *source*.  The source can be any
>>> of the following:
>>>
>>> * The name of a directory, in which case a new application archive
>>>   will be created from the content of that directory.
>>> * The name of an existing application archive file, in which case the
>>>   file is copied to the target.  The file name should include the
>>>   ``.pyz`` extension, if required.
>>
>> Or   ".pyzw", I presume.
>
> Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a 
> .pyz (or .py) file?

No. The launcher doesn't handle pythonw, because it won't do what you
expect. On Windows, the difference between a GUI and a console program
is baked into the executable (the "subsystem" field in the exe file
header). That's why we have python/pythonw and py/pyw executables.

A .pyz with a #!pythonw shebang would be run by py.exe, which would
launch pythonw.exe. So if you double click the file, a console window
will open (for py.exe) but the script won't use it (because it's being
run by pythonw). So you'll have a useless console window hanging
round.

Paul
___
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

Re: [Python-Dev] PEP 448 review

[Guido van Rossum]

As a follow-up, Joshua updated the PEP to remove *comprehensions, and it is
now accepted.

On Wed, Feb 25, 2015 at 11:42 AM, Guido van Rossum  wrote:

> I'm back, I've re-read the PEP, and I've re-read the long thread with "(no
> subject)".
>
> I think Georg Brandl nailed it:
>
> """
>
>
>
>
>
>
>
>
> *I like the "sequence and dict flattening" part of the PEP, mostly because
> itis consistent and should be easy to understand, but the comprehension
> syntaxenhancements seem to be bad for readability and "comprehending" what
> the codedoes.The call syntax part is a mixed bag on the one hand it is nice
> to be consistent with the extended possibilities in literals (flattening),
> but on the other hand there would be small but annoying inconsistencies
> anyways (e.g. the duplicate kwarg case above).*
> """
>
> Greg Ewing followed up explaining that the inconsistency between dict
> flattening and call syntax is inherent in the pre-existing different rules
> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
> **{'a': 1}) is a TypeError.)
>
> For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations
> for function calls proposed by the PEP is an easy +1 -- it's a
> straightforward extension of the existing pattern, and anybody who knows
> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
> **e) means shouldn't be hard either. Understanding the edge case for
> duplicate keys with f(**d, **e) is a little harder, but the error messages
> are pretty clear, and it is not a new edge case.
>
> The sequence and dict flattening syntax proposals are also clean and
> logical -- we already have *-unpacking on the receiving side, so allowing
> *x in tuple expressions reads pretty naturally (and the similarity with *a
> in argument lists certainly helps). From here, having [a, *x, b, *y] is
> also natural, and then the extension to other displays is natural: {a, *x,
> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>
> So that leaves comprehensions. IIRC, during the development of the patch
> we realized that f(*x for x in xs) is sufficiently ambiguous that we
> decided to disallow it -- note that f(x for x in xs) is already somewhat of
> a special case because an argument can only be a "bare" generator
> expression if it is the only argument. The same reasoning doesn't apply (in
> that form) to list, set and dict comprehensions -- while f(x for x in xs)
> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
> same as [(x for x in xs)] (that's a list of one element, and the element is
> a generator expression).
>
> The basic premise of this part of the proposal is that if you have a few
> iterables, the new proposal (without comprehensions) lets you create a list
> or generator expression that iterates over all of them, essentially
> flattening them:
>
> >>> xs = [1, 2, 3]
> >>> ys = ['abc', 'def']
> >>> zs = [99]
> >>> [*xs, *ys, *zs]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> But now suppose you have a list of iterables:
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xss[0], *xss[1], *xss[2]]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> Wouldn't it be nice if you could write the latter using a comprehension?
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xs for xs in xss]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> This is somewhat seductive, and the following is even nicer: the *xs
> position may be an expression, e.g.:
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xs[:2] for xs in xss]
> [1, 2, 'abc', 'def', 99]
> >>>
>
> On the other hand, I had to explore the possibilities here by
> experimenting in the interpreter, and I discovered some odd edge cases
> (e.g. you can parenthesize the starred expression, but that seems a
> syntactic accident).
>
> All in all I am personally +0 on the comprehension part of the PEP, and I
> like that it provides a way to "flatten" a sequence of sequences, but I
> think very few people in the thread have supported this part. Therefore I
> would like to ask Neil to update the PEP and the patch to take out the
> comprehension part, so that the two "easy wins" can make it into Python 3.5
> (basically, I am accepting two-thirds of the PEP :-). There is some time
> yet until alpha 2.
>
> I would also like code reviewers (Benjamin?) to start reviewing the patch
> , taking into account that the
> comprehension part needs to be removed.
>
> --
> --Guido van Rossum (python.org/~guido)
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 448 review

[Guido van Rossum]

One more thing. This PEP would never have been accepted without a working
implementation. Thanks Neil and Joshua for that! (And for being flexible.)

On Thu, Feb 26, 2015 at 12:19 PM, Guido van Rossum  wrote:

> As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> On Wed, Feb 25, 2015 at 11:42 AM, Guido van Rossum 
> wrote:
>
>> I'm back, I've re-read the PEP, and I've re-read the long thread with
>> "(no subject)".
>>
>> I think Georg Brandl nailed it:
>>
>> """
>>
>>
>>
>>
>>
>>
>>
>>
>> *I like the "sequence and dict flattening" part of the PEP, mostly
>> because itis consistent and should be easy to understand, but the
>> comprehension syntaxenhancements seem to be bad for readability and
>> "comprehending" what the codedoes.The call syntax part is a mixed bag on
>> the one hand it is nice to be consistent with the extended possibilities in
>> literals (flattening), but on the other hand there would be small but
>> annoying inconsistencies anyways (e.g. the duplicate kwarg case above).*
>> """
>>
>> Greg Ewing followed up explaining that the inconsistency between dict
>> flattening and call syntax is inherent in the pre-existing different rules
>> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
>> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
>> **{'a': 1}) is a TypeError.)
>>
>> For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations
>> for function calls proposed by the PEP is an easy +1 -- it's a
>> straightforward extension of the existing pattern, and anybody who knows
>> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
>> **e) means shouldn't be hard either. Understanding the edge case for
>> duplicate keys with f(**d, **e) is a little harder, but the error messages
>> are pretty clear, and it is not a new edge case.
>>
>> The sequence and dict flattening syntax proposals are also clean and
>> logical -- we already have *-unpacking on the receiving side, so allowing
>> *x in tuple expressions reads pretty naturally (and the similarity with *a
>> in argument lists certainly helps). From here, having [a, *x, b, *y] is
>> also natural, and then the extension to other displays is natural: {a, *x,
>> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>>
>> So that leaves comprehensions. IIRC, during the development of the patch
>> we realized that f(*x for x in xs) is sufficiently ambiguous that we
>> decided to disallow it -- note that f(x for x in xs) is already somewhat of
>> a special case because an argument can only be a "bare" generator
>> expression if it is the only argument. The same reasoning doesn't apply (in
>> that form) to list, set and dict comprehensions -- while f(x for x in xs)
>> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
>> same as [(x for x in xs)] (that's a list of one element, and the element is
>> a generator expression).
>>
>> The basic premise of this part of the proposal is that if you have a few
>> iterables, the new proposal (without comprehensions) lets you create a list
>> or generator expression that iterates over all of them, essentially
>> flattening them:
>>
>> >>> xs = [1, 2, 3]
>> >>> ys = ['abc', 'def']
>> >>> zs = [99]
>> >>> [*xs, *ys, *zs]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> But now suppose you have a list of iterables:
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xss[0], *xss[1], *xss[2]]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> Wouldn't it be nice if you could write the latter using a comprehension?
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xs for xs in xss]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> This is somewhat seductive, and the following is even nicer: the *xs
>> position may be an expression, e.g.:
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xs[:2] for xs in xss]
>> [1, 2, 'abc', 'def', 99]
>> >>>
>>
>> On the other hand, I had to explore the possibilities here by
>> experimenting in the interpreter, and I discovered some odd edge cases
>> (e.g. you can parenthesize the starred expression, but that seems a
>> syntactic accident).
>>
>> All in all I am personally +0 on the comprehension part of the PEP, and I
>> like that it provides a way to "flatten" a sequence of sequences, but I
>> think very few people in the thread have supported this part. Therefore I
>> would like to ask Neil to update the PEP and the patch to take out the
>> comprehension part, so that the two "easy wins" can make it into Python 3.5
>> (basically, I am accepting two-thirds of the PEP :-). There is some time
>> yet until alpha 2.
>>
>> I would also like code reviewers (Benjamin?) to start reviewing the patch
>> , taking into account that the
>> comprehension part needs to be removed.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>

Re: [Python-Dev] PEP 448 review

[Ethan Furman]

On 02/26/2015 12:19 PM, Guido van Rossum wrote:

> As a follow-up, Joshua updated the PEP to remove *comprehensions, and it is 
> now accepted.

Congratulations Thomas, Joshua, and Neil!!

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] PEP 448 review

[Brett Cannon]

On Thu, Feb 26, 2015 at 3:38 PM Ethan Furman  wrote:

> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>
> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> Congratulations Thomas, Joshua, and Neil!!
>

I'll add a "thanks" to everyone involved with the PEP since it was an
involved one implementation-wise and discussion-wise.

-Brett
___
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

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

[Guido van Rossum]

Accepted!

Thanks for your patience, Paul, and thanks everyone for their feedback.

I know there are still a few small edits to the PEP, but those don't affect
my acceptance. Congrats!

--Guido

On Thu, Feb 26, 2015 at 9:05 AM, Paul Moore  wrote:

> On 24 February 2015 at 18:24, Guido van Rossum  wrote:
> > Here's my review. I really like where this is going but I have a few
> > questions and suggestions (I can't help myself :-).
>
> OK, I've updated both the PEP and the patch based on follow-up
> discussions. I think (again!) it is ready to go.
>
> I've included the updated PEP inline below, it'll be available at
> peps.python.org as soon as someone has a chance to upload it.
>
> Thanks to everyone for the various comments. If I've missed anything
> that someone thinks I'd said I would change, please let me know.
>
> Paul
>
> PEP: 441
> Title: Improving Python ZIP Application Support
> Version: $Revision$
> Last-Modified: $Date$
> Author: Daniel Holth ,
> Paul Moore 
> Discussions-To:
> https://mail.python.org/pipermail/python-dev/2015-February/138277.html
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 30 March 2013
> Post-History: 30 March 2013, 1 April 2013, 16 February 2015
>
> Improving Python ZIP Application Support
> 
>
> Python has had the ability to execute directories or ZIP-format
> archives as scripts since version 2.6 [1]_.  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 it was
> not promoted as part of Python 2.6 [2]_, so that it is relatively
> unknown, but also because the Windows installer does not register a
> file extension (other than ``.py``) for this format of file, 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 terminology "Python Zip Application" will be the formal term used
> for a zip-format archive that contains Python code in a form that can
> be directly executed by Python (specifically, it must have a
> ``__main__.py`` file in the root directory of the archive).  The
> extension ``.pyz`` will be formally associated with such files.
>
> The Python 3.5 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.
>
> On Unix, it would be ideal if the ``.pyz`` extension and the name
> "Python Zip Application" were registered (in the mime types database?).
> However, such an association is out of scope for this PEP.
>
> Python Zip applications can be prefixed with a ``#!`` line
> pointing to the correct Python interpreter and an optional
> explanation::
>
> #!/usr/bin/env python3
> #  Python application packed with zipapp module
> (binary contents of archive)
>
> On Unix, this allows the OS to run the file with the correct
> interpreter, via the standard "shebang" support.  On Windows, the
> Python launcher implements shebang support.
>
> However, it is always possible to execute a ``.pyz`` application by
> supplying the filename to the Python interpreter directly.
>
> 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 zipapp Module
> ==
>
> This PEP also proposes including a module for working with these
> archives.  The module will contain functions for working with Python
> zip application archives, and a command line interface (via ``python
> -m zipapp``) for their creation and manipulation.
>
> More complete tools for managing Python Zip Applications are
> encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
> and pex [6]_ are two such tools.
>
> Module Interface
> 
>
> The zipapp module will provide the following functions:
>
> ``create_archive(source, target=None, interpreter=None, main=None)``
> 
>
> Create an application archive from *source*.  The source can be any
> 

Re: [Python-Dev] Request for Pronouncement: PEP 486 - Make the Python Launcher aware of virtual environments

[Guido van Rossum]

PEP 486 is hereby accepted. You can fix the typo at the same time as
marking it as accepted.

Paul, thanks and congrats, everyone else, thanks for the feedback!

--Guido

On Tue, Feb 24, 2015 at 12:45 PM, Guido van Rossum  wrote:

> Thanks for doing this, Paul!
>
> I think this is a fine PEP and I have no comments. (Note that I am not
> much of a Windows user so I am just taking most of the things you claim at
> face value. :-) I will accept the PEP in 1-3 days unless a storm of
> objections gets piled onto this thread.
>
> --Guido
>
> On Sat, Feb 21, 2015 at 1:31 AM, Paul Moore  wrote:
>
>> The discussion on PEP 486 (started at
>> https://mail.python.org/pipermail/python-dev/2015-February/138171.html,
>> following from the thread at
>> https://mail.python.org/pipermail/python-dev/2015-February/138160.html)
>> seems to have died down. There's an implementation at
>> http://bugs.python.org/issue23465.
>>
>> So, I think this is ready for pronouncement.
>>
>> Thanks,
>> Paul
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--Guido van Rossum (python.org/~guido)
___
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

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

[Paul Moore]

On 26 February 2015 at 21:34, Guido van Rossum  wrote:
> Accepted!
>
> Thanks for your patience, Paul, and thanks everyone for their feedback.
>
> I know there are still a few small edits to the PEP, but those don't affect
> my acceptance. Congrats!

Excellent, thanks to everyone for the helpful comments throughout.

Paul
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Gonzalez]

DOES NOBODY HAVE AN ANSWER TO THIS???

I'm REALLY relying on someone who works on Python to answer this. PLEASE??

On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez  wrote:

> So...
>
> There was a recent discussion here on porting Python to Android. Well, for
> those of you who saw too many unread messages and marked the whole thread
> as read like I usually do, I helped Cyd figure out some patches that make
> it work. Cyd then opened Issue 23496 .
> Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial
> language).
>
> Which leads me to the question. See, of course, the patches should only be
> enabled if Python is being built targeting Android, but I'm not sure how
> that should be detected.
>
> I know that the Android target triple is arm-linux-androideabi. Should I
> test for the __ANDROID__ macro in the source file, or should I modify
> configure.ac to detect Android and define its own macro? Also, if a
> configure.ac edit is preferred, where should it be? It's slightly painful
> to scan through all 4000 lines of Python's configure script. ;)
>
> --
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-terminated."
> Personal reality distortion fields are immune to contradictory evidence. -
> srean
> Check out my website: http://kirbyfan64.github.io/
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ethan Furman]

On 02/25/2015 10:17 AM, Ryan Gonzalez wrote:

> Which leads me to the question. See, of course, the patches should only be 
> enabled if Python is being built targeting
> Android, but I'm not sure how that should be detected.
> 
> I know that the Android target triple is arm-linux-androideabi. Should I test 
> for the __ANDROID__ macro in the source
> file, or should I modify configure.ac  to detect Android 
> and define its own macro? Also, if a
> configure.ac  edit is preferred, where should it be? 
> It's slightly painful to scan through all 4000
> lines of Python's configure script. ;)

Anybody have any words of wisdom on this?

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Smith-Roberts]

I'm not an official cpython developer but ifdef __ANDROID__ is quite in
line with other per-platform support (__FreeBSD__, __linux__, etc), as well
as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not
being defined when it should be?

On Thu, Feb 26, 2015 at 4:20 PM, Ryan Gonzalez  wrote:

> DOES NOBODY HAVE AN ANSWER TO THIS???
>
> I'm REALLY relying on someone who works on Python to answer this. PLEASE??
>
> On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez  wrote:
>
>> So...
>>
>> There was a recent discussion here on porting Python to Android. Well,
>> for those of you who saw too many unread messages and marked the whole
>> thread as read like I usually do, I helped Cyd figure out some patches that
>> make it work. Cyd then opened Issue 23496
>> . Now, I'm going to try to redo the
>> patches against HEAD (or tip in Mercurial language).
>>
>> Which leads me to the question. See, of course, the patches should only
>> be enabled if Python is being built targeting Android, but I'm not sure how
>> that should be detected.
>>
>> I know that the Android target triple is arm-linux-androideabi. Should I
>> test for the __ANDROID__ macro in the source file, or should I modify
>> configure.ac to detect Android and define its own macro? Also, if a
>> configure.ac edit is preferred, where should it be? It's slightly
>> painful to scan through all 4000 lines of Python's configure script. ;)
>>
>> --
>> Ryan
>> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
>> nul-terminated."
>> Personal reality distortion fields are immune to contradictory evidence.
>> - srean
>> Check out my website: http://kirbyfan64.github.io/
>>
>
>
>
> --
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-terminated."
> Personal reality distortion fields are immune to contradictory evidence. -
> srean
> Check out my website: http://kirbyfan64.github.io/
>
> ___
> 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/rmsr%40lab.net
>
>
___
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

Re: [Python-Dev] ubuntu buildbot

[Benjamin Peterson]

On Wed, Feb 25, 2015, at 22:38, David Bolen wrote:
> On Mon, Nov 24, 2014 at 11:07 AM, Benjamin Peterson 
> wrote:
> >
> > On Mon, Nov 24, 2014, at 00:33, David Bolen wrote:
> >> Yeah, it definitely needs it.  Historically it was intentional as my own
> >> servers were all on 8.04, but the last of those moved 12.04 last year.
> >>
> >> I think there's already a 12.04 buildbot, so perhaps 14.04 would be
> >> better?  I do prefer sticking with an LTS.
> >
> > 14.04 would be good.
> >
> >> It'll need to move to 64-bit given the hosting environment, at least for
> >> the kernel.  I could do 32-bit userspace via multiarch if keeping a 32-bit
> >> buildbot in the mix is attractive.
> >
> > It'd be nice to keep a 32-bit bot around.
> 
> Took a bit longer than anticipated, but the slave upgrade is complete.
> 
> The bolen-ubuntu slave is now a 32-bit Ubuntu 14.04.2 LTS system.
> I've re-run the most recent 2.7, 3.4 and 3.x builds which all pass
> (though with a few new compiler warnings in some cases).

Thank you very much!
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ethan Furman]

On 02/26/2015 05:13 PM, Ryan Smith-Roberts wrote:

> I'm not an official cpython developer but ifdef __ANDROID__ is quite in line 
> with
> other per-platform support (__FreeBSD__, __linux__, etc), as well as already 
> being
> in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being defined when it
> should be?

I believe the issue is adding in Android support, and how best to do it.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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

[Python-Dev] [RELEASED] Python 3.4.3 is now available

[Larry Hastings]

On behalf of the Python development community and the Python 3.4 release 
team, I'm pleased to announce the availability of Python 3.4.3.   Python 
3.4.3 has many bugfixes and other small improvements over 3.4.2.


You can find it here:

   https://www.python.org/downloads/release/python-343/


The release slipped by two or three days, depending on what time zone 
you're in.  This is my fault--I apologize for the inconvenience.


Cheers,


//arry/
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Smith-Roberts]

On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts  wrote:
> I'm not an official cpython developer but ifdef __ANDROID__ is quite in line
> with other per-platform support (__FreeBSD__, __linux__, etc), as well as
> already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not being
> defined when it should be?

Might as well spend the time to answer my own question:

Some Googling indicates that __ANDROID__ is baked into the NDK
toolchain, so it's definitely what one would use to wrap
Android-specific code.

"__ANDROID__ shall always be defined by the toolchain, without a need
for special flags though, so please rely on that instead in your
code." - David Turner, Android NDK Lead, 2010.
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ethan Furman]

On 02/26/2015 05:52 PM, Ryan Smith-Roberts wrote:


> Might as well spend the time to answer my own question:

Thanks!  Much appreciated.  :)

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan]

Thank you so much!

Ryan Smith-Roberts  wrote:
>On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts 
>wrote:
>> I'm not an official cpython developer but ifdef __ANDROID__ is quite
>in line
>> with other per-platform support (__FreeBSD__, __linux__, etc), as
>well as
>> already being in use in Modules/_posixsubprocess.c. Is __ANDROID__
>not being
>> defined when it should be?
>
>Might as well spend the time to answer my own question:
>
>Some Googling indicates that __ANDROID__ is baked into the NDK
>toolchain, so it's definitely what one would use to wrap
>Android-specific code.
>
>"__ANDROID__ shall always be defined by the toolchain, without a need
>for special flags though, so please rely on that instead in your
>code." - David Turner, Android NDK Lead, 2010.
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Check out my website: http://kirbyfan64.github.io/___
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