Nick Coghlan <ncogh...@gmail.com> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6749> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
