Mailman 3 September 2009 - Python-Dev

Re: [Python-Dev] Support for Encrypted Zip as python scripts
by Brett Cannon 01 Sep '09

01 Sep '09

There is a standard for encrypting entire zip files. And I was looking at the zip docs the other day and zipfile can already decrypt but not encrypt (assuming my memory is accurate; doing this from my phone on vacation). On Aug 23, 2009 2:10 PM, "Guido van Rossum" <guido(a)python.org> wrote: On Sun, Aug 23, 2009 at 9:09 AM, Shashank Singh< shashank.sunny.singh(a)gmail.com> wrote: > There is an... MvL already asked for a patch so I suppose that means he thinks it's useful. Personally I've never encountered an encrypted zipfile, so I just have questions: is there a standard encryption algorithm? What is encrypted? The entire file or individual members? How are you supposed to give the password? Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

7 19

how important is setting co_filename for a module being imported to what __file__ is set to?
by Brett Cannon 01 Sep '09

01 Sep '09

I am going through and running the entire test suite using importlib to ferret out incompatibilities. I have found a bunch, although all rather minor (raising a different exception typically; not even sure they are worth backporting as anyone reliant on the old exceptions might get a nasty surprise in the next micro release), and now I am down to my last failing test suite: test_import. Ignoring the execution bit problem (http://bugs.python.org/issue6526 but I have no clue why this is happening), I am bumping up against TestPycRewriting.test_incorrect_code_name. Turns out that import resets co_filename on a code object to __file__ before exec'ing it to create a module's namespace in order to ignore the file name passed into compile() for the filename argument. Now I can't change co_filename from Python as it's a read-only attribute and thus can't match this functionality in importlib w/o creating some custom code to allow me to specify the co_filename somewhere (marshal.loads() or some new function). My question is how important is this functionality? Do I really need to go through and add an argument to marshal.loads or some new function just to set co_filename to something that someone explicitly set in a .pyc file? Or I can let this go and have this be the one place where builtins.__import__ and importlib.__import__ differ and just not worry about it? -Brett

10 30

3to2 0.1 alpha 1 released
by Joe Amenta 01 Sep '09

01 Sep '09

Hello all, I have released the first alpha version of 3to2 after finishing it for my Google Summer of Code 2009(tm) project. You can get the tarball for this release at http://bitbucket.org/amentajo/lib3to2/downloads/3to2_0.1-alpha1.tar.gz. This requires python 2.7, because it requires a newer version of 2to3 than what comes with 2.6. Release notes are in the RELEASE file. Development happens at http://bitbucket.org/amentajo/lib3to2/, and the source code for this release lives at http://bitbucket.org/amentajo/3to2-01-alpha-1. Report bugs at http://bitbucket.org/amentajo/lib3to2/issues/, please. Additional notes and comments can (for now) be found at http://www.startcodon.com/wordpress/?cat=4. --Joe

9 19