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

[Andy C]

On 7/12/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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>.

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