PEP 304, and alternative

[Skip Montanaro]

    Andrew> haven't seen much discussion on PEP 304 recently, what's its
    Andrew> current status?

Same as before.

    Andrew> It's so broad-brush; PYTHONBYTECODEBASE can only really be set
    Andrew> per-user, and is likely to cause the same problems PYTHONPATH
    Andrew> did (before site-packages and .pth files made all that easier).

Why is this a problem?  It gives the user control over where .pyc files will
be written.  My initial intent was that if users set it at all, it would be
set something like

    PYTHONBYTECODEBASE=$HOME/tmp/python

or

    PYTHONBYTECODEBASE=/tmp/skip/python

    Andrew> The problems with user rights also look really horrid. Say
    Andrew> bytecodebase is /tmp/python/. All users must have write access
    Andrew> to /tmp/python/home, so they can store PYCs for PYs in their
    Andrew> home directory; however if user A hasn't yet run a PY from his
    Andrew> home directory, user B can create /tmp/python/home/A and put a
    Andrew> booby-trapped PYC in, that could be run when user A executes a
    Andrew> script of the same name from /home/A.

This is (minimally) addressed in the Issues section:

    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.

By "general directory" I mean writable by more than just root.

    Andrew> I'd instead like to do it by having a writable mapping in sys
    Andrew> somewhere which can hold a number of directory remappings. This
    Andrew> could then be written to on a site-level basis by
    Andrew> sitecustomize.py and/or a user or module-level basis by user
    Andrew> code. eg.

    Andrew>   sys.bytecodebases= {
    Andrew>     '/home/and/pylib/': '/home/and/pybin/',
    Andrew>     '/www/htdocs/cgi-bin/': '/www/cgi-cache/'
    Andrew>   }

    Andrew> and so on.

How is this better?  How does it address the security problem you raised
above?

    Andrew> Also it avoids the problem of what to do on multi-root
    Andrew> filesystems like that of Windows, as only string matching is
    Andrew> required.

Windows' multi-root filesystem is a known problem.  I've not yet been able
to solve it, though I must admit I haven't worked on it in awhile either.

Skip