New version. I think this might finally be getting there.

pep-0264.txt

@@ -1,6 +1,6 @@
 PEP: 264
 Title:  Future statements in simulated shells
-Version: 2
+Version: 3
 Author: Michael Hudson <mwh@python.net>
 Status: Draft
 Type: Standards Track
@@ -16,11 +16,21 @@ Abstract
     statements in "real" interactive shells, i.e. have __future__
     statements' effects last the life of the shell.
 
-    This short PEP proposes to make this possible by adding an
-    optional fourth argument to the builtin function "compile" and
+    The PEP also takes the oppourtunity to clean up the other
+    unresolved issue mentioned in PEP 236, the inability to stop
+    compile() inheriting the effect of future statements affecting the
+    code calling compile().
+
+    This PEP proposes to address the first problem by adding an
+    optional fourth argument to the builtin function "compile", adding
+    information to the _Feature instances defined in __future__.py and
     adding machinery to the standard library modules "codeop" and
     "code" to make the construction of such shells easy.
 
+    The second problem is dealt with by simply adding *another*
+    optional argument to compile(), which if non-zero suppresses the
+    inheriting of future statements' effects.
+
 
 Specification
 
@@ -32,13 +42,35 @@ Specification
     various possible compile time options as a bitfield.  The
     bitfields will have the same values as the PyCF_* flags #defined
     in Include/pythonrun.h (at the time of writing there are three -
-    PyCF_NESTED_SCOPES, PyCF_GENERATORS and PyCF_DIVISION).  These are
-    currently not exposed to Python, so I propose adding them to
-    codeop.py (because it's already here, basically).
+    PyCF_NESTED_SCOPES, PyCF_GENERATORS and PyCF_DIVISION).
 
-    XXX Should the supplied flags be or-ed with the flags of the
-    calling frame, or do we override them?  I'm for the former,
-    slightly.
+    compile() shall raise a ValueError exception if it does not
+    recognize any of the bits set in the supplied flags.
+
+    The flags supplied will be bitwise-"or"ed with the flags that
+    would be set anyway.
+
+    The above-mentioned flags are not currently exposed to Python.  I
+    propose adding .compiler_flag attributes to the _Feature objects
+    in __future__.py that contain the necessary bits, so one might
+    write code such as:
+
+        import __future__
+        def compile_generator(func_def):
+            return compile(func_def, "<input>", "suite",
+                           __future__.generators.compiler_flag)
+
+    A recent change means that these same bits can be used to tell if
+    a code object was compiled with a given feature; for instance
+
+        codeob.co_flags & __future__.generators.compiler_flag
+
+    will be non-zero if and only if the code object "codeob" was
+    compiled in an environment where generators were allowed.
+
+    I will also add a .__all__ attribute to the __future__ module,
+    giving a low-effort way of enumerating all the __future__ options
+    supported by the running interpreter.
 
     I also propose adding a pair of classes to the standard library
     module codeop.
@@ -47,12 +79,10 @@ Specification
     will act much like the builtin "compile" of 2.1 with the
     difference that after it has compiled a __future__ statement, it
     "remembers" it and compiles all subsequent code with the
-    __future__ options in effect.
+    __future__ option in effect.
 
-    It will do this by examining the co_flags field of any code object
-    it returns, which in turn means writing and maintaining a Python
-    version of the function PyEval_MergeCompilerFlags found in
-    Python/ceval.c.
+    It will do this by using the new features of the __future__ module
+    mentioned above.
 
     Objects of the other class added to codeop - probably called
     CommandCompiler or somesuch - will do the job of the existing
@@ -68,7 +98,7 @@ Backward Compatibility
 
     Should be very few or none; the changes to compile will make no
     difference to existing code, nor will adding new functions or
-    classes to codeop.  Exisiting code using
+    classes to codeop.  Existing code using
     code.InteractiveInterpreter may change in behaviour, but only for
     the better in that the "real" Python shell will be being better
     impersonated.
@@ -76,37 +106,23 @@ Backward Compatibility
 
 Forward Compatibility
 
-    codeop will require very mild tweaking as each new __future__
-    statement is added.  Such events will hopefully be very rare, so
-    such a burden is unlikely to cause significant pain.
+    The check for unrecognised bits in compile() will need updating as
+    and when more bits are recognised.
 
 
 Issues
 
-    Paul Prescod has reasonably complained about the choice of a
-    bitfield as the fourth argument to compile(), claiming it is
-    obscure and unpythonic.
-
-    There is also the thought of Jython compatibility; because Jython
-    has the ability to access any Java object without the PyObject
-    cruft needed in CPython, Jython already has a Python-visible
-    CompilerFlags object which has a boolean attribute
-    "compiler_flags", and will presumably have one fairly soon called
-    "generators".  This would be doable in CPython, but it would
-    require more hacking of deep magical bits of the interpreter and
-    require bumping the PYTHON_API_VERSION (OTOH, the division patch
-    just went in, so there can't be a freeze on the C API just
-    yet...).
+    I hope the above interface is not too disruptive to implement for
+    Jython.
 
 
 Implementation
 
-    I've uploaded a preliminary implementation as:
+    I've uploaded a series of (still) preliminary implementations at:
 
         http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470
 
-    I need to add docs and possibly implment a friendlier interface to
-    compile().
+    I still need to do docs (I've done docstrings) and tests.
 
 
 Copyright