OMG, the use case is actually running a script without giving the user access to the script's source? Agreed that's a big -1.
I thought it was just for running a zip containing code so secret you don't want to leave it around on your hard drive without encryption (say, the program you use to compute your employee's bonuses, or perhaps a patented algoritm for detecting spam). That use case would make a small amount of sense, though I personally don't care enough to write the code to support it. --Guido On Sun, Aug 23, 2009 at 7:09 PM, Nick Coghlan<ncogh...@gmail.com> wrote: > Guido van Rossum wrote: >> Anyway it looks like if someone wants to try this, only the code in >> runpy.py needs to be touched. > > The necessary work would actually be in zipimport. runpy doesn't know > anything about the details of where the module code comes from, it just > asks the relevant importer for the details. For zipfile and directory > execution, they get added to the start of sys.path and then runpy is > invoked to look for the module "__main__". From that point on most of > the heavy lifting is handled by the regular import machinery (aside from > using the pkgutil emulation for the basic import behaviour that isn't > fully exposed by the imp module). > > I added a -1 to the tracker issue as well. That's due both to my opinion > on the inherent idiocy of DRM though (since shared secrets don't provide > any security when the attacker in your threat model is one of the people > you are sharing the secret with) and to the fact that associating > passwords with the relevant zipfile entries on sys.path would get messy > fairly quickly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com