At 03:52 PM 7/12/2007 -0700, Andy C wrote:
On 7/12/07, "Martin v. Löwis" martin@v.loewis.de 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 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 easy enough.
Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes Sense<TM>.
- Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case.
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 to use -z more than once (or whatever the option ends up as).
I think it's sufficient to treat it as a documented "trick" that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases.
Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to "runpy", and IMO that's dead in the water due to shebang argument limits.
- Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__.
I personally don't see any benefit to making up an extra name, when we already have one that describes the functionality perfectly. There is absolutely nothing about -z that needs or should care about zipfile-ness, so why add an unnecessary limitation while creating yet another __special__ name to remember?
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 easy enough.
I'm not a Windows user, so don't have a good feel for the state of the extension mess on that platform these days. PYZ isn't listed on filext.com, but I don't know if that means much.
On Thursday 12 July 2007, Phillip J. Eby wrote:
Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes Sense<TM>.
Indeed. Let's not do something so specific it's a pain to use.
Andy C:
- Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case.
Yes. A use case for using directories, or for not supporting them? These cases should be as similar as possible; like Phillip suggested, we should be thinking "sys.path entry" rather than "zip file".
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 to use -z more than once (or whatever the option ends up as).
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.
The only competing proposal besides what I've suggested was the one to add an option to "runpy", and IMO that's dead in the water due to shebang argument limits.
Agreed.
Andy:
- Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__.
Identifying ZIP files is straightforward; there's nothing weird about this one.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org>
On 7/12/07, Fred L. Drake, Jr. fdrake@acm.org 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 to use -z more than once (or whatever the option ends up as).
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 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
-help says: or java [-options] -jar jarfile [args...] (to execute a jar file)
args are passed to the jarfile being run.
$ java -jar xalan2.jar -jar xalan2.jar Invalid option: -jar Invalid option: xalan2.jar
n
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 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
-help says: or java [-options] -jar jarfile [args...] (to execute a jar file)
args are passed to the jarfile being run.
Sure. However, you can specify multiple jar files on the command line, in the class path.
java -cp xerces.jar -jar xalan2.jar
This runs xalan2.jar, but adds xerces.jar to the class path. It has all the advantages of a command line option compared to setting CLASSPATH: it won't be inherited to subprocesses, and you can use it on Windows, too, whereas you cannot set environment variables in the command line on Windows.
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 files> the.main.class
The equivalent Python line would be
python -p <path> -m main_module
Regards, Martin
On 13/07/07, "Martin v. Löwis" martin@v.loewis.de 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 files> the.main.class
The equivalent Python line would be
python -p <path> -m main_module
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, .jar files are associated with javaw -jar "%1" %, which would reinforce the suggestion that Python have a .pyz extension associated with pythonw -z "%1" %. Note the -w (GUI) form of both of these...
Paul.
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 sys.path. It should also be separate from the -z (or whatever that gets called).
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org>
(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 classpath. This is done all the time, making the contents of those jars available for importing.
These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited.
- C
On 7/12/07, Neal Norwitz nnorwitz@gmail.com wrote:
On 7/12/07, Fred L. Drake, Jr. fdrake@acm.org 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 to use -z more than once (or whatever the option ends up as).
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 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
-help says: or java [-options] -jar jarfile [args...] (to execute a jar file)
args are passed to the jarfile being run.
$ java -jar xalan2.jar -jar xalan2.jar Invalid option: -jar Invalid option: xalan2.jar
n
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/shiblon%40gmail.com
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 available for importing.
These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited.
Actually, I do regularly use both classpath and -jar with java because I'm running a .jar file that does not contain "the world". OTOH, this is a development environment rather than a production environment, so theoretically I could just shove everything into the .jar file -- but I
don't because that adds more time to the compile/link/jarjarjar cycle.
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
I support the RKAB
On 7/12/07, Phillip J. Eby pje@telecommunity.com wrote:
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
On 7/12/07, "Martin v. Löwis" martin@v.loewis.de 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 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 easy enough.
Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes Sense<TM>.
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? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop?
There aren't any restrictions on what can be in __main__ (it's just another module), and while I think it would be a bad practice to import __main__, I could see people being tripped up by this in practice. People might start storing silly things like the program version there, for convenience.
At Google some people do "import sitecustomize" and get values that were computed earlier by the sitecustomize. I could see the same kind of thing happen with __main__.py.
- Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case.
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 to use -z more than once (or whatever the option ends up as).
Where would you do that? Just typing it literally on the command line? Just curious, I have never felt a need to do that. I use Python on Windows frequently.
I think it's sufficient to treat it as a documented "trick" that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases.
Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to "runpy", and IMO that's dead in the water due to shebang argument limits.
As implemented the patch is fairly simple, and shouldn't have any unintended consequences. I'm not necessarily opposed to making it more general and thinking about sys.path vs. a zip file specifically. But I don't have a clear enough picture from all the comments of what exactly to implement.
-z is not the same as "prepend an item to sys.path", because we replace "" with the -z argument. And we also munge sys.argv[0] (which is what you said should happen).
So it's not clear to me at all what multiple -z's should do, exactly. Can you write out the pseudo code? Or modify my patch.
I think it would be fine to have both a -z and -p flag, if the functionality is needed. -z accepts a zip file or a directory and does the right thing to run it as an executable. -p could accept multiple arguments and literally prepends them to sys.path. These seem like different things to me.
I'll look at adding the file association for .pyz (is there an expert on that for questions?), and in that time hopefully the list can decide on the rest of the issues. Or we can just make Guido decide, which is fine by me. : )
Andy
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 have a legitimate -z flag.
If you overload -z to mean "prepend things to sys.path", then you might also want to do python -z /dir1 -z /foo.zip -c 'import foo; print foo'. Should this execute dir1/__main__.py, foo.zip/__main__.py or print foo?
I could be missing what you intend. But I think the patch as implemented doesn't have any of these potentially unconsidered cases and unintended consequences.
Andy
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
On 7/13/07, Greg Ewing greg.ewing@canterbury.ac.nz 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?
Well, you might have multiple executable .py files in the same source tree. So then you would want to build multiple .pyz files, each of which has a different __zipmain__.
I think of __zipmain__ as part of the format of the .pyz file, not part of the source tree. In particular, it specifies what module/function to run in the zipped source tree (and I imagine it will be adapted for other uses). In this model you're separating your development tree and the thing you deploy, which is not always the case in Python.
Andy
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?
Even some moderately-experienced Python developers confuse the concepts of "package" and "directory containing Python code" -- let's not make it worse by encouraging the inclusion of an __init__ module in the top-level package namespace!
-
"Martin v. Löwis" -
Aahz -
Andy C -
Chris Monson -
Fred L. Drake, Jr. -
Greg Ewing -
Neal Norwitz -
Paul Moore -
Phillip J. Eby