PEP 304, and alternative
and-google at doxdesk.com
Tue Jul 22 14:08:24 CEST 2003
haven't seen much discussion on PEP 304 recently, what's its current
As I'm currently writing something that also allows configuration of where
bytecode files go, I finally got around to reading the PEP, and I'm really
not convinced I like the approach it takes. It's so broad-brush;
PYTHONBYTECODEBASE can only really be set per-user, and is likely to cause
the same problems PYTHONPATH did (before site-packages and .pth files made
all that easier).
The problems with user rights also look really horrid. Say bytecodebase is
/tmp/python/. All users must have write access to /tmp/python/home, so they
can store PYCs for PYs in their home directory; however if user A hasn't yet
run a PY from his home directory, user B can create /tmp/python/home/A and
put a booby-trapped PYC in, that could be run when user A executes a script
of the same name from /home/A. The only way I can see of getting around
problems like this in 304 is to create a complete skeleton of the existing
filesystem, owned by the same users as in the main filesystem, and keep it
updated. Which is impractical.
I'd instead like to do it by having a writable mapping in sys somewhere
which can hold a number of directory remappings. This could then be written
to on a site-level basis by sitecustomize.py and/or a user or module-level
basis by user code. eg.
and so on. Filenames of .py files could be compared by string.startswith to
see if they match each rule. If they match more than one, the rule with the
longest key is used. If a match is made, its key is replaced by the value,
and 'c' or 'o' added to the filename. An attempt is made to makedirs the
parent directory if it doesn't exist.
IMO such a mapping, if it occurs, should replace rather than augment the
original directory as in 304. The need to look in the same directory
regardless of bytecodebase seems to come from the need to keep the process
of finding standard library modules unchanged; a selective remapping like
this would avoid the problem by not touching the standard modules (unless
you really want it to).
Also it avoids the problem of what to do on multi-root filesystems like that
of Windows, as only string matching is required.
(O)bjections, (T)houghts, (A)buse?
mailto:and at doxdesk.com
More information about the Python-list