Add Michael Hudson's "Future statements in simulated shells".

pep-0000.txt

@@ -59,6 +59,7 @@ Index by Category
  S   258  pep-0258.txt  DPS Generic Implementation Details     Goodger
  S   262  pep-0262.txt  Database of Installed Python Packages  Kuchling
  S   263  pep-0263.txt  Defining Python Source Code Encodings  Lemburg
+ S   264  pep-0264.txt  Future statements in simulated shells  Hudson
 
  Py-in-the-sky PEPs (not considered for Python 2.2)
 
@@ -204,6 +205,7 @@ Numerical Index
  S   261  pep-0261.txt  Support for "wide" Unicode characters  Prescod
  S   262  pep-0262.txt  Database of Installed Python Packages  Kuchling
  S   263  pep-0263.txt  Defining Python Source Code Encodings  Lemburg
+ S   264  pep-0264.txt  Future statements in simulated shells  Hudson
 
 
 Key
@@ -227,6 +229,7 @@ Owners
     Dubois, Paul F.          paul@pfdubois.com
     Evans, Clark C.          cce@clarkevans.com
     Goodger, David           dgoodger@bigfoot.com
+    Hudson, Michael          mwh@python.net
     Hylton, Jeremy           jeremy@zope.com
     Kuchling, Andrew         akuchlin@mems-exchange.org
     Lemburg, Marc-Andre      mal@lemburg.com

pep-0264.txt

@@ -0,0 +1,120 @@
+PEP: 264
+Title:  Future statements in simulated shells
+Version: 2
+Author: Michael Hudson <mwh@python.net>
+Status: Draft
+Type: Standards Track
+Requires: 236
+Created: 30-Jul-2001
+Python-Version: 2.2
+Post-History: 30-Jul-2001
+
+Abstract
+
+    As noted in PEP 263, there is no clear way for "simulated
+    interactive shells" to simulate the behaviour of __future__
+    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
+    adding machinery to the standard library modules "codeop" and
+    "code" to make the construction of such shells easy.
+
+
+Specification
+
+    I propose adding a fourth, optional, "flags" argument to the
+    builtin "compile" function.  If this argument is omitted,
+    there will be no change in behaviour from that of Python 2.1.
+
+    If it is present it is expected to be an integer, representing
+    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).
+
+    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.
+
+    I also propose adding a pair of classes to the standard library
+    module codeop.
+
+    One - probably called Compile - will sport a __call__ method which
+    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.
+
+    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.
+
+    Objects of the other class added to codeop - probably called
+    CommandCompiler or somesuch - will do the job of the existing
+    codeop.compile_command function, but in a __future__-aware way.
+
+    Finally, I propose to modify the class InteractiveInterpreter in
+    the standard library module code to use a CommandCompiler to
+    emulate still more closely the behaviour of the default Python
+    shell.
+
+
+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
+    code.InteractiveInterpreter may change in behaviour, but only for
+    the better in that the "real" Python shell will be being better
+    impersonated.
+
+
+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.
+
+
+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...).
+
+
+Implementation
+
+    I've uploaded a preliminary implementation as:
+
+        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().
+
+
+Copyright
+
+    This document has been placed in the public domain.
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End: