[Python-Dev] Add a -z interpreter flag to execute a zip file

[Phillip J. Eby]

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
>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?