On 19 February 2015 at 07:16, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
I don't know exactly what the procedure would be to claim .pyz for *nix,
e.g. updating /etc/mime.types, but I think the PEP should at least mention
this. I t
On 19 February 2015 at 18:11, Jim J. Jewett wrote:
>> Also, I don't think reserving anything is something I, as an
>> individual (and specifically a non-Unix user) should do. It probably
>> should be handled by the PSF, as the process seems to need a contact
>> email address...
>
> Ideally, it wou
On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
I don't know exactly what the procedure would be to claim .pyz for *nix,
e.g. updating /etc/mime.types,
...
>> Are you just looking for
>> http://www.iana
On Wed, Feb 18, 2015 at 10:16 PM, Paul Moore wrote:
> On 18 February 2015 at 20:48, Jim J. Jewett wrote:
>> Barry Warsaw wrote:
I don't know exactly what the procedure would be to claim .pyz for *nix,
e.g. updating /etc/mime.types, but I think the PEP should at least mention
this.
On Feb 18, 2015, at 09:16 PM, Paul Moore wrote:
>That covers mime types, but not file extensions, so it's not really
>what *I* thought Barry was talking about.
I was actually thinking about both. :)
The Wikipedia page has several external links to collections of file
extensions, but I don't know
On 18 February 2015 at 20:48, Jim J. Jewett wrote:
> Barry Warsaw wrote:
>>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>>> e.g. updating /etc/mime.types, but I think the PEP should at least mention
>>> this. I think we want to get as official support for .pyz files
Barry Warsaw wrote:
>> I don't know exactly what the procedure would be to claim .pyz for *nix,
>> e.g. updating /etc/mime.types, but I think the PEP should at least mention
>> this. I think we want to get as official support for .pyz files on *nix as
>> possible.
Paul Moore wrote:
> I'll add a
On 17.02.15 23:25, Barry Warsaw wrote:
I'm not sure sys.getfilesystemencoding() is the right encoding, rather than
sys.getdefaultencoding(), if you're talking about the encoding of the shebang
line rather than the encoding of the resulting pyz filename.
On POSIX sys.getfilesystemencoding() is t
On 2/17/2015 1:40 PM, Barry Warsaw wrote:
I agree, for deployment to environments where you can guarantee that the basic
Python infrastructure is available. It may not be though, and perhaps we can
relegate that to py2exe, cx_freeze, and friends, although I would say that
having such support bui
On Sun, Feb 15, 2015 at 1:45 PM, Serhiy Storchaka wrote:
> On 15.02.15 18:21, Thomas Wouters wrote:
>>
>> which requires that extension modules are stored uncompressed (simple)
>> and page-aligned (harder, as the zipfile.ZipFile class doesn't directly
>> support page-aligning anything
>
>
> It is
On Feb 17, 2015, at 09:45 PM, Paul Moore wrote:
>If Python zip applications got the ability to include binary extensions, they
>would *definitely* not be portable (we don't want to go down the route of
>wheel-like compatibility tags for an application file format).
Agreed!
>Currently, I'm trying
On Feb 17, 2015, at 09:52 PM, Paul Moore wrote:
>I see no problem with either having zipapp develop into a much
>fuller-featured solution, or having an externally developed tool
>brought into the stdlib and replacing zipapp. I just don't think
>there's anything mature enough for that role out ther
On 17 February 2015 at 21:40, Barry Warsaw wrote:
> OTOH, I think it *would* be useful to have this built into Python. We almost
> have too many choices, and may people I've talked to lately (including
> experienced Pythonistas) have trouble choosing the right tool. But that can
> come later; le
On 17 February 2015 at 21:13, Barry Warsaw wrote:
> Don't discount sys.executable to quickly. :)
I used pyzzer when it defaulted to sys.executable, and the experience
was painful. That's on Windows, and Unix may be different, but let's
just say I don't want to go there :-)
Paul
_
On 17 February 2015 at 21:10, Barry Warsaw wrote:
> The actual "import an extension module" support in zipimport does need to be
> cross-platform, but it can work differently depending on the platform. For
> example, if extended-dlopen is available on your Linux machine, zipimport
> could just us
On Feb 17, 2015, at 01:25 PM, Ethan Furman wrote:
>On 02/17/2015 01:13 PM, Barry Warsaw wrote:
>
>> There are lots of interesting use cases we could still support. I could
>> build a single-file application and deploy it into my OS's system archives.
>> I could deploy that thing into my platform'
On Feb 17, 2015, at 08:44 PM, Paul Moore wrote:
>I'd like to see a good single-file bundled application format for
>Python (on Windows, there's py2exe, which is fantastic, but often I
>simply don't *want* to bundle Python and the stdlib with my code).
I agree, for deployment to environments where
On 2/17/2015 10:52 AM, Barry Warsaw wrote:
Probably the best thing to do (on *nix at least) is, if the path is absolute,
use the given string verbatim. If the path is relative, search for the given
executable on $PATH and use the first one found. If nothing is found, use
what's given explicitly
On Feb 17, 2015, at 08:52 PM, Paul Moore wrote:
>I'm pretty sure that's the way the general feeling is going.
Though the more I think about it, the more I like sys.executable. :)
>> However, -p must be able to accept any number of strings, including
>> "/usr/bin/env python3" if the user wants th
On 02/17/2015 01:13 PM, Barry Warsaw wrote:
> There are lots of interesting use cases we could still support. I could build
> a single-file application and deploy it into my OS's system archives. I could
> deploy that thing into my platform's app store. I could hand it over to a
> colleague run
On 17 February 2015 at 18:44, Barry Warsaw wrote:
> I don't know exactly what the procedure would be to claim .pyz for *nix,
> e.g. updating /etc/mime.types, but I think the PEP should at least mention
> this. I think we want to get as official support for .pyz files on *nix as
> possible.
I'll
On Feb 17, 2015, at 08:53 PM, Paul Moore wrote:
>On 17 February 2015 at 18:56, Barry Warsaw wrote:
>>>The initial draft of this PEP proposed using ``/usr/bin/env python``
>>>as the default interpreter.
>>
>> The other reasonable alternative for a default shebang is sys.executable.
>
>That's insta
On Feb 17, 2015, at 08:58 PM, Paul Moore wrote:
>But I would say that anything that is added to zipimport should be
>cross-platform. Having support for C extensions in zipimport on Unix
>only will just add another way in which Python applications can
>inadvertantly be non-portable... (It should be
On 17 February 2015 at 19:00, Barry Warsaw wrote:
>>It might be nice to consider those use-cases in pyzapp as well, especially
>>once the glibc feature is released. It requires some fairly big changes to
>>zipimport (I ended up rewriting the whole thing) but we can easily
>>opensource the code, if
On 17 February 2015 at 18:56, Barry Warsaw wrote:
>>The initial draft of this PEP proposed using ``/usr/bin/env python``
>>as the default interpreter.
>
> The other reasonable alternative for a default shebang is sys.executable.
That's instantly non-portable. On my PC, it'd give
C:\Apps\Python34\
On 17 February 2015 at 18:52, Barry Warsaw wrote:
>>So, the options I see:
>>
>>1. Stick with /usr/bin/env python
>>2. No shebang unless -p is specified
>>3. Unix users come up with a solution which is the same as the above
>>for Windows users, but which suits them better.
>
> #2 seems to me to be
On 17 February 2015 at 18:44, Barry Warsaw wrote:
> The broader question of pex, pyzaa, etc. is an important one for Python,
> IMHO. Having a standard single-executable distribution story will help Python
> continue to compete on platforms that work beyond the distribution models
> we've come to
On Feb 16, 2015, at 11:21 PM, Paul Moore wrote:
>Default Interpreter
>---
>
>The initial draft of this PEP proposed using ``/usr/bin/env python``
>as the default interpreter.
The other reasonable alternative for a default shebang is sys.executable.
Cheers,
-Barry
On Feb 15, 2015, at 05:21 PM, Thomas Wouters wrote:
>FWIW, we have a similar tool to 'pyzaa' at Google, although a lot older (it
>has a pure-python implementation of zipimport, because it had to work with
>Python 2.2 back in the day) that *does* support extension modules and other
>shared librarie
On Feb 16, 2015, at 04:16 PM, Paul Moore wrote:
>So, the options I see:
>
>1. Stick with /usr/bin/env python
>2. No shebang unless -p is specified
>3. Unix users come up with a solution which is the same as the above
>for Windows users, but which suits them better.
#2 seems to me to be the most r
On Feb 15, 2015, at 05:15 PM, Petr Viktorin wrote:
>So I'd suggest `/usr/bin/env python3` for the default.
I really don't want `/usr/bin/env anything`.
In general, using /usr/bin/env is a fine tool for developers, but a terrible
tool for deployment. It's just too easy for end users to break an
I'm just now catching up on this thread, so hopefully these thoughts are still
relevant.
IIRC, the PEP has been scaled back to mostly a convenience around packing an
existing directory into a .pyz file, and (on Windows) adding an association
for those as executable Python zip file. To the extent
On 15 February 2015 at 17:46, Daniel Holth wrote:
> Go ahead, make my pep.
>
> I will appreciate seeing it happen.
Here is a draft update for PEP 441. It's still a work in progress - in
particular I want to wait for consensus on the issue of the default
interpreter before finalising it. But I tho
Paul Moore wrote:
The alternative, I guess, is to have *no* default and write no shebang
unless -p is specified.
+1. That sounds like a very good idea to me.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
If I only have one version on my box, yes, I only use "python". But like I
said, for me personally, that situation doesn't last very long.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 16 February 2015 at 17:00, Mark Young wrote:
> I don't know what anyone else does, but in cases where I have both on my
> windows box, I do use python2(.x) and python3(.y) . If I only have one
> version on the box, I use the generic name of course. (I don't often have
> only one version on my b
On 16 February 2015 at 16:42, Paul Moore wrote:
> My point is that on Windows, users typically don't change the
> executable name they use[1], but rather configure the "python" (or
> "py") command to do what they want. So I think that on Windows we
> should follow that convention and execute whate
Paul Moore wrote:
> On 15 February 2015 at 18:25, Petr Viktorin wrote:
>> On POSIXy systems the "python3" symlink is created in all venvs. I
>> thought (perhaps naïvely) that Windows doesn't do shebangs natively,
>> so there's some Python-specific mechanism around them, which should
>> handle "pyt
I don't know what anyone else does, but in cases where I have both on my
windows box, I do use python2(.x) and python3(.y) . If I only have one
version on the box, I use the generic name of course. (I don't often have
only one version on my boxes though. 2.x inevitably gets drug in in for
some reas
On 16 February 2015 at 16:34, Steve Dower wrote:
>> As far as I know, this is *identical* behaviour to Unix - even to the
>> incredibly
>> annoying (to me) choice of Python 2 as a default. So I reconfigure the
>> default
>> in my personal settings to Python 3. Unix users can do this too (althoug
On 02/16/2015 08:16 AM, Paul Moore wrote:
> The alternative, I guess, is to have *no* default and write no shebang
> unless -p is specified.
This seems to make sense.
> So, the options I see:
>
> 1. Stick with /usr/bin/env python
> 2. No shebang unless -p is specified
> 3. Unix users come up wi
On 15 February 2015 at 18:25, Petr Viktorin wrote:
> On POSIXy systems the "python3" symlink is created in all venvs. I
> thought (perhaps naïvely) that Windows doesn't do shebangs natively,
> so there's some Python-specific mechanism around them, which should
> handle "python3".
Windows doesn't
On 15/02/2015 18:06, Steve Dower wrote:
"Go ahead, make my pep."
We should make a python-dev t-shirt with this on it :)
I'll buy one provided p&p isn't too high :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
__
On 15.02.15 18:21, Thomas Wouters wrote:
which requires that extension modules are stored uncompressed (simple)
and page-aligned (harder, as the zipfile.ZipFile class doesn't directly
support page-aligning anything
It is possible to add this feature to ZipFile. It can be useful because
will al
On Sun, Feb 15, 2015 at 5:43 PM, Paul Moore wrote:
> On 15 February 2015 at 16:15, Petr Viktorin wrote:
>> On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote:
>>> So the usage would be something like
>>>
>>> python -m zipapp [options] dir_to_zip
>>>
>>> Options:
>>> -p The interpreter
ul Moore<mailto:p.f.mo...@gmail.com>; Steve
Dower<mailto:steve.do...@microsoft.com>; Python
Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
Go ahead, make my pep.
I will appreciate seeing it happen.
On Feb 15, 20
Go ahead, make my pep.
I will appreciate seeing it happen.
On Feb 15, 2015 8:47 AM, "Nick Coghlan" wrote:
> On 15 February 2015 at 23:21, Paul Moore wrote:
> > On 15 February 2015 at 08:59, Nick Coghlan wrote:
> >> The other option would to cut PEP 441 way back to *just* be about
> >> standard
On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote:
> So the usage would be something like
>
> python -m zipapp [options] dir_to_zip
>
> Options:
> -p The interpreter to use on the shebang line
> (defaulting to /usr/bin/env python)
On many systems this default would mean Python 2. Even
On 15 February 2015 at 16:21, Thomas Wouters wrote:
> It might be nice to consider those use-cases in pyzapp as well, especially
> once the glibc feature is released. It requires some fairly big changes to
> zipimport (I ended up rewriting the whole thing) but we can easily
> opensource the code,
On 15 February 2015 at 16:15, Petr Viktorin wrote:
> On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote:
>> So the usage would be something like
>>
>> python -m zipapp [options] dir_to_zip
>>
>> Options:
>> -p The interpreter to use on the shebang line
>> (defaulting to /usr/bin/env py
On 15 February 2015 at 16:00, Serhiy Storchaka wrote:
>> Would it be reasonable to add methods to the
>> ZipFile class to read and write the prefix data?
>
>
> But the stdlib zipfile module supports this.
>
> with open(filename, 'wb') as f:
> f.write(shebang)
> with zipfile.PyZipFile(f, 'a
FWIW, we have a similar tool to 'pyzaa' at Google, although a lot older (it
has a pure-python implementation of zipimport, because it had to work with
Python 2.2 back in the day) that *does* support extension modules and other
shared libraries (by extracting them to disk on program startup.) We're
On 15.02.15 10:47, Paul Moore wrote:
On 15 February 2015 at 08:14, Paul Moore wrote:
Maybe it would be better to
put something on PyPI and let it develop outside the stdlib first?
The only place where a ".pyz" file can't easily be manipulated with
the stdlib zipfile module is in writing a she
On 15 February 2015 at 13:47, Nick Coghlan wrote:
> Or we just skip the wrapper and make "python -m zipapp" the
> recommended invocation style. Adding a wrapper later is fairly easy,
> but removing it would be difficult.
Fine with me - the wrappers are basically useless on Windows where
Tools/Scr
On 15 February 2015 at 23:21, Paul Moore wrote:
> On 15 February 2015 at 08:59, Nick Coghlan wrote:
>> 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 (w
On 15 February 2015 at 08:59, Nick Coghlan wrote:
> 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
On 15 February 2015 at 18:14, Paul Moore 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 s
On 15 February 2015 at 08:14, Paul Moore wrote:
> Maybe it would be better to
> put something on PyPI and let it develop outside the stdlib first?
The only place where a ".pyz" file can't easily be manipulated with
the stdlib zipfile module is in writing a shebang line to the start of
the archive
On 15 February 2015 at 05:33, Nick Coghlan wrote:
> I'd definitely prefer a simple procedural API like that over offering
> a public stateful object-oriented API, as the latter significantly
> increases testing complexity without offering a sufficiently
> compelling gain in expressiveness to justi
On 15 February 2015 at 00:44, Paul Moore wrote:
> I'm looking at putting together a patch for CPython to implement PEP
> 441. In doing so, there are a few issues that I'd like to raise with
> the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
> Nick proposed renaming this to "pyza
I'm looking at putting together a patch for CPython to implement PEP
441. In doing so, there are a few issues that I'd like to raise with
the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
Nick proposed renaming this to "pyzapp", which I like, but it's not a
big deal either way).
61 matches
Mail list logo
