The zipfile support in 2.6 that allows you pass a zipfile(with __main__.py 
inside) as the "script", does not support encrypted zipfiles.  I view this 
as being a feature that could be useful to some.

Can you provide a patch?

Some (supportive) discussion on python-dev at
http://mail.python.org/pipermail/python-dev/2009-August/091324.html .

I don't think I will be able to provide a patch.  If I am correct this 
would live in Modules/zipimport.c and I do not have enough experience in 
C/C++ to add in the feature.  If in the end zipimport ends up using 
Lib/zipfile.py then I can work on adding the feature.

The decryption provided by the zipfile module is for the worthless
32-bit crc based "encryption" of zipfiles.  I think promoting the use of
that is a bad idea.

zipfile can be used by people to get their data out of such files.  We
should not encourage them to put it and/or their code into such a stupid
format.

-1 on supporting this.

Anyways as to implementation details, yes you'd need a way to accept a
key on the command line (or prompt for it using getpass?) and pass it to
the import mechanism at import time.  For zip files with only the
contained file data "encrypted" (the only thing the zipfile module
supports) a zip file could be checked for __init__.py and .py files
without decrypting first so that a password is only prompted for when
such a module is imported.

Again I don't see value in that.

You would also run in to the usual problems with any form of DRM: the
password *will* exist in memory in order for zipimport to be able to use
it, so anyone that really wants the password will be able to get hold of it.

It also isn't as simple as just providing a single password - there can
be multiple zip files on sys.path, so how is Python meant to know which
password goes with which zipfile?

Another -1 here.

My thinking behind this was not to be the ultimate security against 
someone getting the source, but more of a very high wall to keep out the 
majority of people.

It seems like the best way to determine what file should be decrypted 
and when a password should be prompted is to look at the header of the 
zip file where it defines the encryption information as the zip file is 
loaded.  Taking that approach would allow someone, if they wanted, to 
put multiple encrypted zip files in the path and be prompted for each 
one.  That is not my planned usage of it, but someone else may have a 
use for that.

Could someone point me in the right direction on where this 
functionality would live if implemented?  In the event there is enough 
votes to prevent it from being added I would like to try to work on it 
so I can patch my own installations of Python.

The people who do not know how to get over that wall would be equally
stumped if presented with tokenized .pyc or .pyo files.  No fake
encryption needed.

A few pointers in case anyone decides to follow this up further:

Zipfile execution is just a special case of normal zipimport: the
zipfile's name is placed at the head of sys.path and a (very) rough
equivalent of "import __main__" is then invoked.

So for zipfile execution to support password protected zipfiles, general
zipimport would need to support them as well.

However, this runs into the problem that invocation of the zipimport
module is largely implicit - the import engine invokes sys.path_hooks
entries (which includes ZipImporter automatically) for a given sys.path
entry and finds that, sure enough, ZipImporter recognises it and creates
an appropriate object to handle it.

So the trick lies in getting the password to the importer that needs to
know it in order to open the zipfile.

For the general case, you could create a new path hook that had a list
of filename pattern<->password pairs that could be placed in
sys.path_hooks ahead of the normal zipimport hook. If it saw a pattern
it recognised, it could use the appropriate password to open the zipfile
and return a corresponding importer object (you could do this largely
independently of the standard library itself - PEP 302 is expressly
designed to let third party developers run with this kind of idea).

That wouldn't help much with zipfile execution though, as you still
wouldn't have a mechanism for providing the password on the command line.