[Python-checkins] python/nondist/peps pep-0304.txt,1.12,1.13

[montanaro@users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12312

Modified Files:
	pep-0304.txt 
Log Message:
Minor tweakage.  Been sitting in my sandbox for awhile.


Index: pep-0304.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0304.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- pep-0304.txt	29 May 2003 13:46:46 -0000	1.12
+++ pep-0304.txt	18 Jun 2005 13:04:03 -0000	1.13
@@ -34,8 +34,8 @@
 
 - If not defined, Python bytecode is generated in exactly the same way
   as is currently done.  sys.bytecodebase is set to the root directory
-  (either / on Unix or the root directory of the startup drive --
-  typically ``C:\`` -- on Windows).
+  (either / on Unix and Mac OSX or the root directory of the startup
+  (installation???) drive -- typically ``C:\`` -- on Windows).
 
 - If defined and it refers to an existing directory to which the user
   has write permission, sys.bytecodebase is set to that directory and
@@ -76,6 +76,9 @@
 - If no byte-compiled file is found, an attempt to read a
   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
 module-by-module or directory-by-directory control over the
 disposition of bytecode files.
@@ -146,22 +149,22 @@
 to the sys module, effectively::
 
     pcb = os.path.abspath(os.environ["PYTHONBYTECODEBASE"])
+    probe = os.path.join(pcb, "foo")
     try:
-        probe = os.path.join(pcb, "foo")
         open(probe, "w")
-        os.unlink(probe)
-        sys.bytecodebase = pcb
     except IOError:
         sys.bytecodebase = None
+    else:
+        os.unlink(probe)
+        sys.bytecodebase = pcb
 
 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.
-(I can't imagine you'd want it to move around during program
-execution.)
+but not have it subject to changes to the current working directory
+during program execution.  (I can't imagine you'd want it to move
+around during program execution.)
 
-There is nothing special about sys.bytecodebase.  The user may
-change it at runtime if she so chooses, but normally it will not be
-modified.
+There is nothing special about sys.bytecodebase.  The user may change
+it at runtime if desired, but normally it will not be modified.
 
 
 Rationale
@@ -194,7 +197,7 @@
 altogether.  This proposal subsumes that.  Adding a command-line
 option is certainly possible, but is probably not sufficient, as the
 interpreter's command line is not readily available during
-installation.
+installation (early during program startup???).
 
 
 Issues
@@ -208,12 +211,11 @@
 - 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.
+  except possibly 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