On 7/24/07, David Gowers [EMAIL PROTECTED] wrote:
On 7/24/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.
Instead of requiring a -z flag, why not have the interpreter peak at
the file to see if
I'd like to request comments on this patch I submitted:
https://sourceforge.net/tracker/index.php?func=detailaid=1739468group_id=5470atid=305470
There are many details given in the comments on that page.
This can be used to deploy Python programs in a very lightweight and
cross-platform way.
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.
Instead of requiring a -z
Crutcher Dunnavant
On Jul 23, 2007, at 9:55 AM, Guido van Rossum [EMAIL PROTECTED]
wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z
On 7/23/07, Crutcher Dunnavant [EMAIL PROTECTED] wrote:
Crutcher Dunnavant
On Jul 23, 2007, at 9:55 AM, Guido van Rossum [EMAIL PROTECTED]
wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's
At 09:55 AM 7/23/2007 -0700, Guido van Rossum wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
At 10:34 AM 7/23/2007 -0700, Guido van Rossum wrote:
There's an ambiguity -- a Zip file could start with a Python (or
shell, or Perl) script that bootstraps execution. This is used
regularly. Changing the semantics just because the file *ends* with
something funny sounds like asking for trouble.
On 23/07/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
Actually, it isn't, because you can't start a zipfile with a Python
script. Lord knows I've *tried*, but the Python interpreter just
won't accept arbitrary binary data as part of a script. :)
That bit me a while back, hard enough that I
Just to update everyone on the status of this, the next thing on my
list is to figure out the Windows build and set up the the file
association in the installer. Actually, I should ask if there's
anything else that I should pay attention to here, e.g. do I have to
add an icon association for
New icons get added so rarely that each time it happens, Windows has
changed enough to make the instructions invalid... I do remember
creating icon associations for .py, .pyc, .pyo and .pyw, and separate
open associations for these. IIRC the two associations are quite
independent. Probably
Andy C schrieb:
Just to update everyone on the status of this, the next thing on my
list is to figure out the Windows build and set up the the file
association in the installer. Actually, I should ask if there's
anything else that I should pay attention to here, e.g. do I have to
add an icon
At 02:58 PM 7/14/2007 +1200, Greg Ewing wrote:
Andy C wrote:
What does if __name__ == '__main__ mean in
__main__.py? : ) If someone tries does import __main__ from another
module in the program, won't that result in an infinite loop?
Is there a reason not to use __init__.py for this?
Jim Jewett wrote:
If anything, I would like to see the -m option enhanced so that if it
gets a recognized collection file type (including a directory or
zip), it does the right thing. Whether that actually makes sense, or
defeats the purpose of the -m shortcut, I'm not sure.
-m deals with
On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote:
Andy C wrote:
... a .zip file with a __zipmain__.py module at its root?
Why not just an __init__.py, which you would normally execute if you
tried to import/run a directory?
* Magically looking at the first argument to see if it's a zip file
On Saturday 14 July 2007, Andy C wrote:
I don't mind calling it -z and using it for directories. But mainly
that's because no one has proprosed another name. : ) I think we've
agreed that -p is something totally different.
We could use -r (run), or -X (execute); not sure those are really
At 03:28 AM 7/15/2007 +1000, Nick Coghlan wrote:
Jim Jewett wrote:
If anything, I would like to see the -m option enhanced so that if it
gets a recognized collection file type (including a directory or
zip), it does the right thing. Whether that actually makes sense, or
defeats the
On 7/14/07, Andy C [EMAIL PROTECTED] wrote:
On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote:
while I think it would be a bad practice to
import __main__,
I have seen it recommended as the right place to store global
(cross-module) settings.
Where? People use __main__.py now?
No;
Andy C wrote:
So does everyone agree that there should be a new extension called
.pyz?
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
- Anders
___
Python-Dev mailing list
Python-Dev@python.org
What happens if multiple entries contain __main__.py entries? I don't like
this one so much. I don't know what Java does if you specify -jar more than
once; that might suggest something.
You can't with:
java version 1.5.0_11
Java(TM) 2 Runtime Environment, Standard Edition (build
On Friday 13 July 2007, Paul Moore wrote:
Fair point. Doesn't it argue that there are valid uses for both -p and
-z (in Python terms)? I'm not expert in Java usage, but on Windows,
Indeed it does. I'd be happy for there to be a -p that allows both Windows
and Unix users to prepend to
On Friday 13 July 2007, Anders J. Munch wrote:
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
I guess it would be pinheaded to call it .zippy. ;-)
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Fred L. Drake, Jr. wrote:
On Friday 13 July 2007, Anders J. Munch wrote:
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
I guess it would be pinheaded to call it .zippy. ;-)
I believe .zpy would be most recognizable and lest subject to confusion.
On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote:
I don't have any particular objection to using runpy for this, but I
believe that this shebang line won't actually work on certain non-BSD
OSes, such as most Linux versions, which allow you to have at most
*one* argument to a #! line, and will
On 13/07/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
So while -z strictly gives the equivalent -jar, it's actually
-cp that is used much more often in Java (I think), and that
doesn't have an equivalent in Python still. My typical usage
of java goes like this
java -cp endless list of jar
(Sorry about top-posting: I'm using my blackberry while waiting for
the bus and my gmail client doesn't do quoting :-( )
Certainly java won't let you specify -jar more than once, because that
would be telling it to *run* two files. It *will*, however, let you
specify more than one jar in the
On Fri, Jul 13, 2007, Chris Monson wrote:
Certainly java won't let you specify -jar more than once, because that
would be telling it to *run* two files. It *will*, however, let you
specify more than one jar in the classpath. This is done all the
time, making the contents of those jars
Andy C wrote:
... a .zip file with a __zipmain__.py module at its root?
Why not just an __init__.py, which you would normally execute if you
tried to import/run a directory?
* Magically looking at the first argument to see if it's a zip file
seems problematic to me. I'd rather be explicit
At 09:13 PM 7/12/2007 -0700, Andy C wrote:
I can definitely see why it just makes sense, and my first thought
was indeed to name it __main__. But then you lose the ability to make
a distinction: What does if __name__ == '__main__ mean in
__main__.py? : )
The same as anywhere else; it'll just
Andy C wrote:
What does if __name__ == '__main__ mean in
__main__.py? : ) If someone tries does import __main__ from another
module in the program, won't that result in an infinite loop?
Is there a reason not to use __init__.py for this?
--
Greg
Anders J. Munch wrote:
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
Indeed. Is there any need to restrict extensions to
3 characters these days? Last time I experimented
with this on Windows, it seemed to handle longer
extensions okay.
--
Greg
On 7/13/07, Greg Ewing [EMAIL PROTECTED] wrote:
Andy C wrote:
What does if __name__ == '__main__ mean in
__main__.py? : ) If someone tries does import __main__ from another
module in the program, won't that result in an infinite loop?
Is there a reason not to use __init__.py for this?
On 7/11/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nick Coghlan has reviewed the patch and seems to think it's a good
idea. Thomas Wouters also said he likes it, and I ran it by Guido
earlier and he seemed to think the idea is good, although I don't
think he has seen the implementation.
Right, but it's supposed to be cross platform, as mentioned in the
patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
approach is also cross-platform, no?
How do you get the -z
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Right, but it's supposed to be cross platform, as mentioned in the
patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
On 7/12/07, Thomas Wouters [EMAIL PROTECTED] wrote:
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Right, but it's supposed to be cross platform, as mentioned in the
patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a
On 08:41 am, [EMAIL PROTECTED] wrote:
On 7/12/07, Thomas Wouters [EMAIL PROTECTED] wrote:
I disagree with both statements. The bagage is much less than
zipimport
itself, which has proven to be quite useful. Nevertheless, zipimport
built
into the interpreter was by no means necessary; current
On 12/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I wonder, is it even necessary to say anything, after:
+1.
[...]
In fact, I distinctly remember thinking You know, if Python had an
equivalent to Java's '-jar' option, this would be a whole lot easier.
I'm also +1 on this, for exactly
On 12/07/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Right, but it's supposed to be cross platform, as mentioned in the
patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
should not be removed from sys.path. It is *not* meant to be
the current directory, but the directory where the main script
lives.
Right; it should be replaced with the zipfile path instead.
I would personally rather see this option defined as
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
approach is also cross-platform, no?
How do you get the -z option to work on Windows? What extension
do you
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
should not be removed from sys.path. It is *not* meant to be
the current directory, but the directory where the main script
lives.
Right; it should be replaced with the zipfile path
Phillip J. Eby wrote:
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
should not be removed from sys.path. It is *not* meant to be
the current directory, but the directory where the main script
lives.
Right; it should be replaced with the zipfile path instead.
I would personally
At 01:46 AM 7/13/2007 +1000, Nick Coghlan wrote:
The current version of runpy doesn't accept any options, but it
would be pretty easy to make the following changes:
1. Accept a -p option that prepends path entries. These path entries
would be combined into a single list from left to right on
At 08:11 AM 7/12/2007 -0700, Andy C wrote:
Is __main__ a good idea considering that is used for something
similar but implemented completely differently (the module name)?
That would be why it *is* a good idea; it's the One Obvious Way To Do It. :)
Now we just need an option abbreviation that's
The patch suggests using .pyz and adding a default association to the
installer (much like .py and .pyw have).
Ok. It would be good if the patch actually added that extension, rather
than merely suggesting that it should be added.
Regards,
Martin
___
The relevant shebang line to be prepended to a zip file would then look
something like:
#!/usr/bin/env python -m runpy -p
I might be confusing things, but I think some systems only allow a
single argument in the shebang line.
Regards,
Martin
___
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
The patch suggests using .pyz and adding a default association to the
installer (much like .py and .pyw have).
Ok. It would be good if the patch actually added that extension, rather
than merely suggesting that it should be added.
So
At 10:53 PM 7/12/2007 +0200, Martin v. Löwis wrote:
The approach is cross-platform, in that you can use the approach on
different platforms. The result of the approach, however, is not
cross-platform. You can't distribute your single zip-as-executable to
both Windows and
#!/usr/bin/env python -m runpy -p
Martin I might be confusing things, but I think some systems only allow
Martin a single argument in the shebang line.
It's always been my impression that all Unix or Linux systems have that
constraint. I've never heard of that restriction being
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
The patch suggests using .pyz and adding a default association to the
installer (much like .py and .pyw have).
Ok. It would be good if the patch actually added that extension, rather
than
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
So does everyone agree that there should be a new extension called
.pyz? And that the definition of this is a .zip file with a
__zipmain__.py module at its root? If so, I can make the change... I
haven't looked around the codebase yet but it sounds
On 7/12/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
Phillip Eby:
Testing your package before you zip it, would be one. :) My
personal main interest was in being able to add an item to sys.path
without having to set $PYTHONPATH on Windows. That's why I'd like it
to be possible
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
The patch suggests using .pyz and adding a default association to the
installer (much like .py and .pyw have).
Ok. It would be good if
Another issue I see is that -m and -c have command line parsing
semantics, and -z follows those now.
python -z foo.zip -z bar
As implemented, this would pass sys.argv[0:3] == ['foo.zip', '-z', 'bar']
If you allow multiple -z flags to be meaningful, this gets confusing.
The foo.zip program could
(resending this now that I'm subscribed, not sure it made it through
the moderation the first time)
I'd like to request comments on this patch I submitted:
https://sourceforge.net/tracker/index.php?func=detailaid=1739468group_id=5470atid=305470
There are many details given in the comments on
Nick Coghlan has reviewed the patch and seems to think it's a good
idea. Thomas Wouters also said he likes it, and I ran it by Guido
earlier and he seemed to think the idea is good, although I don't
think he has seen the implementation.
See my comment: I must be missing the point of the
57 matches
Mail list logo
