[Python-Dev] Add a -z interpreter flag to execute a zip file
Phillip J. Eby
pje at telecommunity.com
Fri Jul 13 01:22:51 CEST 2007
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
>On 7/12/07, "Martin v. Löwis" <martin at 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
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
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?
More information about the Python-Dev