Minor tweakage. Been sitting in my sandbox for awhile.

pep-0304.txt

@@ -34,8 +34,8 @@ interpreted as follows:
 
 - 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 @@ During import, this extension works as follows:
 - 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 @@ environment variable is made absolute, checked for validity and added
 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 @@ The only other alternative proposed so far [1]_ seems to be to add a
 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 @@ 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.
+  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