PEP 304 - Controlling generation of bytecode files

[Skip Montanaro]

    Laura> 1. I the the name PYTHONBYTECODEDIR and sys.bytecodedir (that is
    Laura>    plenty enough to type already) make more sense.

The environment variable's first incarnation had "DIR" in the name.
This can be a bit misleading though.  A couple folks on python-dev thought I
was proposing dumping all .pyc files directly into that directory.
"...BASE" sort of suggests to me that it's the head of a tree.  I shortened
the sys variable to "bytecodebase".

    Laura> 2. This Pep assumes that you want to change files globally, but
    Laura>    not on a per file basis.  What do we want to happen when 2
    Laura>    users of the same system -- a) want different dirs, b) want
    Laura>    the same dir.  In case b) can we still get collisions and a
    Laura>    corrupted file?

As I mentioned in an earlier reply, this is not intended to allow
module-by-module (or even directory-by-directory) control of .pyc file
generation.

    Laura> 3. I am unclear of the security implications of this.  Is
    Laura>    somebody out there depending on the fact that nobody can ever
    Laura>    write their own bytecode files and use them to crack the
    Laura>    system?  If so they are likely to want a way to forbid any but
    Laura>    their system secure ones.

Security is really no different than in the current system.  If you and I
can write to the same directory, then you can do something to my .pyc files
to corrupt them.  In the PEP I have these issues:

    - Security - What if root has PYTHONBYTECODEBASE set?  Yes, this can
      present a security risk, but so can many other things the root user
      does.  The root user should probably not set PYTHONBYTECODEBASE except
      during installation.  Still, perhaps this problem can be minimized.
      When running as root the interpreter should check to see if
      PYTHONBYTECODEBASE refers to a directory which is writable by anyone
      other than root.  If so, it could raise an exception or warning and
      set sys.bytecodebase to None.  Or, see the next item.

    - More security - What if PYTHONBYTECODEBASE refers to a general
      directory (say, /tmp)?  In this case, perhaps loading of a preexisting
      bytecode file should occur only if the file is owned by the current
      user or root.  (Does this matter on Windows?)

I think the second issue may address your concerns.  In any case, even if
the PEP is not accepted, the second item might be a worthwhile enhancement
to security.

    Laura> 4. One thing that I would find useful is a way to say "do not
    Laura>    make pyc's in this dir".  Then when I tar up a distribution to
    Laura>    send someplace I won't have to remember to remove them first.

I don't think that's within the scope of this PEP.  When creating a tarfile
distribution why not just give an excludes argument to (at least GNU) tar
telling it to exclude .pyc files?

Skip