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 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 _______________________________________________ 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/archive%40mail-archive.com
