Brett Cannon added the comment:
Thanks for the patch, Paul! I touched up the formatting to be more PEP 8
compliant and fixed the tests as they initially failed for me (TESTFN didn't
exist prior to you trying to make a directory, so it just failed; switched to
tempfile.TemporaryDirectory
Roundup Robot added the comment:
New changeset d1e9f337fea1 by Brett Cannon in branch 'default':
Issue #23491: Implement PEP 441: Improving Python Zip Application Support
https://hg.python.org/cpython/rev/d1e9f337fea1
--
nosy: +python-dev
___
Python
Paul Moore added the comment:
Thanks Brett! Apologies about the TESTFN issue - I changed it (from
TemporaryDirectory, in fact) based on one of the review comments - it looks
like I didn't test the change properly. My mistake, thanks for catching it.
--
Paul Moore added the comment:
Steve Dower - could you please review the updated patch here. The WiX changes
specifically are intended to register the .pyz extension with the launcher, but
I can see no code that does this for a per-user install. I've copied the same
code for the .py extension
Paul Moore added the comment:
There's a problem with the latest patch, it's lost the MSI updates somehow.
I'll add them back in this evening, please don't commit before a v6 patch is
available,
--
___
Python tracker rep...@bugs.python.org
Steve Dower added the comment:
The whole installer is run with a different global flag depending on the type
of install. So it's automatic, though sometimes you can't do both per-user and
all-user changes at the same time (not that you should anyway).
--
Paul Moore added the comment:
OK, so if the installer changes look good to you, then this PR is once again
ready to go. Sorry to anyone watching for the glitch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
Berker Peksag added the comment:
I left a couple of minor comments on Rietveld.
--
nosy: +berker.peksag
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Paul Moore added the comment:
New patch incorporating Berker's comments
--
Added file: http://bugs.python.org/file38389/pep-441.v5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
Paul Moore added the comment:
There have been no further comments for a while now. Could this be committed by
someone?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Serhiy Storchaka added the comment:
There is not well known old way how to make executable Python files on Windows.
Add line @python -x %0 %* at the start of your Python script and rename the
script to *.bat. The -x option makes Python to skip first line that is not
Python, and @ forbids
Paul Moore added the comment:
I'm -1 on this. The whole point of having a .pyz extension is so that you don't
need to use an extension that's for files containing text to hold binary data.
If you want to do this, use zipapp and specify no interpreter line, then add
the @python line yourself.
Paul Moore added the comment:
Updated patch including (I hope!) all review comments so far.
--
Added file: http://bugs.python.org/file38258/pep-441.v4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
Changes by Paul Moore p.f.mo...@gmail.com:
Removed file: http://bugs.python.org/file38249/pep-441.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Paul Moore added the comment:
OK, thanks. I don't propose to go there with the initial implementation. If
it's a problem in practice, someone can raise a bug and we'll fix it then.
(I've never seen actual Python code in the wild that does all of that...)
--
Paul Moore added the comment:
OK, here is an updated patch based on the python-dev discussions
--
Added file: http://bugs.python.org/file38249/pep-441.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
Paul Moore added the comment:
Sorry - typo. Try again...
--
Added file: http://bugs.python.org/file38250/pep-441.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Jim Jewett added the comment:
I think that instead of application/zip, you want application/zipped-python (or
whatever the precise term was). This was one reason to register the MIME type.
That said, application/zip is probably not harmful; the worst it should do it
hand the archive to a
Paul Moore added the comment:
If I understand Steve's comments, the mime type is used by Windows, so
application/zip lets Windows know that this filetype is fundamentally a zip
file (and so it'll offer to open it with your zip program if you right click,
stuff like that).
pxzw - the w on the
Steve Dower added the comment:
The .px* extensions are for testing builds without messing up your actual file
associations. I ported them forward from the old installer, but most people
will never see them.
--
___
Python tracker
Steve Dower added the comment:
There's also a PerceivedType property which we could set to make sure that
archivers correctly light up. I think that'll get you the built-in Extract
command. Most tools appear on every file and will try and read it to see what
commands make sense, which will
Daniel Holth added the comment:
On Thu, Feb 26, 2015, at 09:41 AM, Paul Moore wrote:
Paul Moore added the comment:
Following on from that, the code to make an archive executable is
currently
os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC)
Should I use ... |
Paul Moore added the comment:
I don't follow (and I don't really want to do things this low level without a
compelling reason...)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Paul Moore added the comment:
Following on from that, the code to make an archive executable is currently
os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC)
Should I use ... | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH? If so, do I
need to protect that with an if not Windows
Daniel Holth added the comment:
Create and open executable file respecting the Unix user's umask:
os.fdopen(os.open(filename, os.O_CREAT|os.O_RDWR), rw)
On Tue, Feb 24, 2015, at 02:34 PM, Paul Moore wrote:
Paul Moore added the comment:
Thanks, I'll fix for the next iteration of the
Serhiy Storchaka added the comment:
Did you noticed my comments to previous patch Paul?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Emails from Rietveld often can be found in the spam folder.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Paul Moore added the comment:
Serhiy - I just got a notification from the review tool - I'd not used it
before and didn't know to check it. But I've read them now and corrected a
number of places based on your comments and added a few replies to the review.
Thanks for the review.
--
Serhiy Storchaka added the comment:
As for zipimport, it doesn't support namespace packages when no 'directory'
entry exists (issue14905). The zipfile module CLI now adds entries for
directories (issue22219).
--
___
Python tracker
Serhiy Storchaka added the comment:
Paul, don't click on Reply below the comment on the main page, it never works.
Instead click the link above the comment, then click on the comment to unfold
it, click on the Reply below the comment, enter your reply, press Send, and
after replying all
Paul Moore added the comment:
Serihy, thanks for the explanation. I was aware that my replies weren't getting
archived, good to know how to avoid that in future.
I've worked out what you mean over the directory entries now. It was easy
enough to fix - I just removed the is_file check before
Paul Moore added the comment:
Thanks, I'll fix for the next iteration of the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
___
Daniel Holth added the comment:
Spelling
raise PackError(Cannot spacify entry point if the source has __main__.py)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
that.
--
assignee: steve.dower
components: Library (Lib)
files: pep441.patch
keywords: patch
messages: 236276
nosy: pmoore, steve.dower
priority: normal
severity: normal
status: open
title: PEP 441 - Improving Python Zip Application Support
type: enhancement
versions: Python 3.5
Added file
Steve Dower added the comment:
I haven't looked closely at the rest, btw. Will try and find time today or
tomorrow.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23491
___
___
Steve Dower added the comment:
The installer changes look fine, though there shouldn't be PATH related strings
in exe/, so there's probably a separate issue there. Wix doesn't really have
any editors that aren't just XML editors.
We probably want to update the ContentType value from
Paul Moore added the comment:
Thanks for checking, Steve. I don't get an installer because of the checksum
error quoted, although I did get the component msi files.
As far as content type is concerned, I wasn't sure what effect it had so I just
copied what was there. I guess application/zip
Steve Dower added the comment:
Either application/zip or application/x-zip-compressed, I'm not sure
exactly what the difference is, but the default .zip association has the latter.
The CRC error may be your machine or it may be because we're currently running
on unstable WiX releases (hey,
Paul Moore added the comment:
Thanks. Updated patch with the new mime-type.
Looks like there's disk errors on that file with the CRC check. Lovely :-)
--
Added file: http://bugs.python.org/file38192/pep441.patch
___
Python tracker
From over yonder, on python-dev...
-- Forwarded message --
From: Steve Dower steve.do...@microsoft.com
Subject: Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
Go ahead, make my pep.
We should make a python-dev t-shirt with this on it :)
+1 from me
On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
I have written Haskell that runs faster than C, and Forth that runs
faster than C,
Faster than *what* C, though?
With Haskell, there's seldom a significant performance hit for using
-fvia-C, so you would probably have been able to get
On Sat, Jun 26, 2010 at 7:11 AM, Nobody nob...@nowhere.com wrote:
On Fri, 25 Jun 2010 20:08:27 -0400, geremy condra wrote:
I have written Haskell that runs faster than C, and Forth that runs
faster than C,
Faster than *what* C, though?
Well, than the C it was replacing, which is admittedly
On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can help
improving the performance of python on 64 bit?
As I understand it,
On Fri, Jun 25, 2010 at 7:01 AM, Tim Wintle tim.win...@teamrubber.com wrote:
On Thu, 2010-06-24 at 21:52 -0500, Peng Yu wrote:
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can
On Thu, Jun 24, 2010 at 7:52 PM, Peng Yu pengyu...@gmail.com wrote:
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can help
improving the performance of python on 64 bit?
This
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely broad
range of activities.
What?
Kindest regards.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrence breamore...@yahoo.co.ukwrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely
broad
range of activities.
What?
What, what?
--S
--
On 25/06/2010 22:25, Stephen Hansen wrote:
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrencebreamore...@yahoo.co.ukwrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast enough for an extremely
broad
range of activities.
What?
What, what?
--S
On Fri, Jun 25, 2010 at 3:18 PM, Mark Lawrence breamore...@yahoo.co.ukwrote:
On 25/06/2010 22:25, Stephen Hansen wrote:
On Fri, Jun 25, 2010 at 1:51 PM, Mark Lawrencebreamore...@yahoo.co.uk
wrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast
On Fri, Jun 25, 2010 at 6:18 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 25/06/2010 22:25, Stephen Hansen wrote:
On Fri, Jun 25, 2010 at 1:51 PM, Mark
Lawrencebreamore...@yahoo.co.ukwrote:
On 25/06/2010 16:34, Stephen Hansen wrote:
Python's slow, sure. But its in practice fast
http://psyco.sourceforge.net/
The above package can improve python program on 32 bit library. But I
need to run on 64 bit library. Is there any other module that can help
improving the performance of python on 64 bit?
--
Regards,
Peng
--
http://mail.python.org/mailman/listinfo/python-list
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
Aahz wrote:
In article [EMAIL PROTECTED],
Steve Holden [EMAIL PROTECTED] wrote:
.
Bear in mind that the PSF made its very first grants last year. The
reason none of those grants was awarded to a documentation project was
Dima Dorfman wrote:
I happen to not mind the ''.join syntax, but if I did, I would use
str.join('', seq)
which is just like a join builtin except that it's not as easy to make
it work on pre-string-method Pythons.
just like join, except that it isn't:
string.join(seq, sep)
u'axbxc'
Aahz wrote:
In article [EMAIL PROTECTED],
Fredrik Lundh [EMAIL PROTECTED] wrote:
func(*arg) instead of apply() is a step back -- it hides the fact
that functions are objects, and it confuses the heck out of both
C/C++ programmers and Python programmers that understand the def
func(*arg) form,
Aahz wrote:
(I've said it before, and I'll say it again: native unicode and
generators are the only essential additions I've seen since 1.5.2, with
properties and sub-classable C types sharing a distant third place.
the rest of the stuff has had zero impact on my ability to write solid
code in no
In article [EMAIL PROTECTED],
Fredrik Lundh [EMAIL PROTECTED] wrote:
func(*arg) instead of apply() is a step back -- it hides the fact
that functions are objects, and it confuses the heck out of both
C/C++ programmers and Python programmers that understand the def
func(*arg) form, because it
On 2004-12-26, Fredrik Lundh [EMAIL PROTECTED] wrote:
string methods are nice, but nothing groundbreaking, and their niceness is
almost entirely offset by the horrid .join(seq) construct that keeps popping
up when people take the the string module is deprecated yada yada too
seriously. and
[EMAIL PROTECTED] (Aahz) writes:
While I'm in complete agreement about the .join() construct on the
basis of looks, I have come to appreciate the fact that I *never* mess up
the order of arguments any more.
Yeah. When I needed joinable arrays of strings in Eiffel, I added them
to the
In article [EMAIL PROTECTED],
Fredrik Lundh [EMAIL PROTECTED] wrote:
(I've said it before, and I'll say it again: native unicode and
generators are the only essential additions I've seen since 1.5.2, with
properties and sub-classable C types sharing a distant third place.
the rest of the stuff
Keith My personal gripe is this. I think the core language, as of 2.3
Keith or 2.4 is very good, has more features than most people will ever
Keith use, and they (Guido, et al.) can stop tinkering with it now and
Keith concentrate more on the standard libraries.
What keeps you
Skip Montanaro wrote:
Keith My personal gripe is this. I think the core language, as of 2.3
Keith or 2.4 is very good, has more features than most people will ever
Keith use, and they (Guido, et al.) can stop tinkering with it now and
Keith concentrate more on the standard
63 matches
Mail list logo
