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
Hi Zach,
I think it is best to remove the .spec file if it is not supported by Python
developers.It is misleading to ship unsupported file within source tree.
Thanks for reply.
From: Zachary Ware
To: "python-dev@python.org"
Cc: Blaxton
Sent: Monday, February 16, 2015 11:54 PM
Subj
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
- Original Message -
> Blaxton writes:
>
> > I am using the spec file that comes with Python source code which
> > downloaded from python.org website
>
> Ah, sorry, I didn't realize that. My advice still stands; while there
> are Red Hat/Fedora/other-RPM-based distro workers here, I do
Blaxton writes:
> I am using the spec file that comes with Python source code which
> downloaded from python.org website
Ah, sorry, I didn't realize that. My advice still stands; while there
are Red Hat/Fedora/other-RPM-based distro workers here, I don't know
if any of them actually have anyth
28 matches
Mail list logo
