Minor tweakage. Been sitting in my sandbox for awhile.
This commit is contained in:
parent
f673294b55
commit
e01d3a7faa
38
pep-0304.txt
38
pep-0304.txt
|
@ -34,8 +34,8 @@ interpreted as follows:
|
||||||
|
|
||||||
- If not defined, Python bytecode is generated in exactly the same way
|
- If not defined, Python bytecode is generated in exactly the same way
|
||||||
as is currently done. sys.bytecodebase is set to the root directory
|
as is currently done. sys.bytecodebase is set to the root directory
|
||||||
(either / on Unix or the root directory of the startup drive --
|
(either / on Unix and Mac OSX or the root directory of the startup
|
||||||
typically ``C:\`` -- on Windows).
|
(installation???) drive -- typically ``C:\`` -- on Windows).
|
||||||
|
|
||||||
- If defined and it refers to an existing directory to which the user
|
- If defined and it refers to an existing directory to which the user
|
||||||
has write permission, sys.bytecodebase is set to that directory and
|
has write permission, sys.bytecodebase is set to that directory and
|
||||||
|
@ -76,6 +76,9 @@ During import, this extension works as follows:
|
||||||
- If no byte-compiled file is found, an attempt to read a
|
- If no byte-compiled file is found, an attempt to read a
|
||||||
byte-compiled file from the augmented directory is made.
|
byte-compiled file from the augmented directory is made.
|
||||||
|
|
||||||
|
- If bytecode generation is required, the generated bytecode is wrtten
|
||||||
|
to the augmented directory if possible.
|
||||||
|
|
||||||
Note that this PEP is explicitly *not* about providing
|
Note that this PEP is explicitly *not* about providing
|
||||||
module-by-module or directory-by-directory control over the
|
module-by-module or directory-by-directory control over the
|
||||||
disposition of bytecode files.
|
disposition of bytecode files.
|
||||||
|
@ -146,22 +149,22 @@ environment variable is made absolute, checked for validity and added
|
||||||
to the sys module, effectively::
|
to the sys module, effectively::
|
||||||
|
|
||||||
pcb = os.path.abspath(os.environ["PYTHONBYTECODEBASE"])
|
pcb = os.path.abspath(os.environ["PYTHONBYTECODEBASE"])
|
||||||
|
probe = os.path.join(pcb, "foo")
|
||||||
try:
|
try:
|
||||||
probe = os.path.join(pcb, "foo")
|
|
||||||
open(probe, "w")
|
open(probe, "w")
|
||||||
os.unlink(probe)
|
|
||||||
sys.bytecodebase = pcb
|
|
||||||
except IOError:
|
except IOError:
|
||||||
sys.bytecodebase = None
|
sys.bytecodebase = None
|
||||||
|
else:
|
||||||
|
os.unlink(probe)
|
||||||
|
sys.bytecodebase = pcb
|
||||||
|
|
||||||
This allows the user to specify the bytecode base as a relative path,
|
This allows the user to specify the bytecode base as a relative path,
|
||||||
but not have it subject to changes to the current working directory.
|
but not have it subject to changes to the current working directory
|
||||||
(I can't imagine you'd want it to move around during program
|
during program execution. (I can't imagine you'd want it to move
|
||||||
execution.)
|
around during program execution.)
|
||||||
|
|
||||||
There is nothing special about sys.bytecodebase. The user may
|
There is nothing special about sys.bytecodebase. The user may change
|
||||||
change it at runtime if she so chooses, but normally it will not be
|
it at runtime if desired, but normally it will not be modified.
|
||||||
modified.
|
|
||||||
|
|
||||||
|
|
||||||
Rationale
|
Rationale
|
||||||
|
@ -194,7 +197,7 @@ The only other alternative proposed so far [1]_ seems to be to add a
|
||||||
altogether. This proposal subsumes that. Adding a command-line
|
altogether. This proposal subsumes that. Adding a command-line
|
||||||
option is certainly possible, but is probably not sufficient, as the
|
option is certainly possible, but is probably not sufficient, as the
|
||||||
interpreter's command line is not readily available during
|
interpreter's command line is not readily available during
|
||||||
installation.
|
installation (early during program startup???).
|
||||||
|
|
||||||
|
|
||||||
Issues
|
Issues
|
||||||
|
@ -208,12 +211,11 @@ Issues
|
||||||
- Security - What if root has PYTHONBYTECODEBASE set? Yes, this can
|
- Security - What if root has PYTHONBYTECODEBASE set? Yes, this can
|
||||||
present a security risk, but so can many other things the root user
|
present a security risk, but so can many other things the root user
|
||||||
does. The root user should probably not set PYTHONBYTECODEBASE
|
does. The root user should probably not set PYTHONBYTECODEBASE
|
||||||
except during installation. Still, perhaps this problem can be
|
except possibly during installation. Still, perhaps this problem
|
||||||
minimized. When running as root the interpreter should check to see
|
can be minimized. When running as root the interpreter should check
|
||||||
if PYTHONBYTECODEBASE refers to a directory which is writable by
|
to see if PYTHONBYTECODEBASE refers to a directory which is writable
|
||||||
anyone other than root. If so, it could raise an exception or
|
by anyone other than root. If so, it could raise an exception or
|
||||||
warning and set sys.bytecodebase to None. Or, see the next
|
warning and set sys.bytecodebase to None. Or, see the next item.
|
||||||
item.
|
|
||||||
|
|
||||||
- More security - What if PYTHONBYTECODEBASE refers to a general
|
- More security - What if PYTHONBYTECODEBASE refers to a general
|
||||||
directory (say, /tmp)? In this case, perhaps loading of a
|
directory (say, /tmp)? In this case, perhaps loading of a
|
||||||
|
|
Loading…
Reference in New Issue