Clarify the muddy status of constructs doing runtime compilation.

pep-0236.txt

@@ -5,15 +5,16 @@ Author: Tim Peters <tim@digicool.com>
 Python-Version: 2.1
 Status: Active
 Type: Standards Track
-Post-History:
+Created: 26-Feb-2001
+Post-History: 26-Feb-2001
 
 
 Motivation
 
     From time to time, Python makes an incompatible change to the
     advertised semantics of core language constructs, or changes their
-    accidental (implementation-dependent) behavior in some way.  While
-    this is never done capriciously, and is always done with the aim of
+    accidental (implementation-dependent) behavior in some way.  While this
+    is never done capriciously, and is always done with the aim of
     improving the language over the long term, over the short term it's
     contentious and disrupting.
 
@@ -26,6 +27,8 @@ Motivation
 
 Intent
 
+    [Note:  This is policy, and so should eventually move into PEP 5[1]]
+
     When an incompatible change to core language syntax or semantics is
     being made:
 
@@ -49,6 +52,11 @@ Intent
     future_statement to make modules containing it act as if the new syntax
     or semantics were already being enforced.
 
+    Note that there is no need to involve the future_statement machinery
+    in new features unless they can break existing code; fully backward-
+    compatible additions can-- and should --be introduced without a
+    corresponding future_statement.
+
 
 Syntax
 
@@ -59,6 +67,7 @@ Syntax
                           ("," feature ["as" name])*
 
         feature: identifier
+        name: identifier
 
     In addition, all future_statments must appear near the top of the
     module.  The only lines that can appear before a future_statement are:
@@ -98,31 +107,15 @@ Semantics
     be imported in the usual way at the time the future_statement is
     executed.
 
-    The *interesting* runtime semantics depend on the feature(s) "imported"
-    by the future_statement(s) appearing in the module.
-
-    Since a module M containing a future_statement naming feature F
-    explicitly requests that the current release act like a future release
-    with respect to F, any code interpreted dynamically from an eval, exec
-    or execfile executed by M will also use the new syntax or semantics
-    associated with F.
-
-    A future_statement appearing "near the top" (see Syntax above) of
-    code interpreted dynamically by an exec or execfile applies to the code
-    block executed by the exec or execfile, but has no further effect on
-    the module that executed the exec or execfile.
+    The *interesting* runtime semantics depend on the specific feature(s)
+    "imported" by the future_statement(s) appearing in the module.
 
     Note that there is nothing special about the statement:
 
         import __future__ [as name]
 
     That is not a future_statement; it's an ordinary import statement, with
-    no special syntax restrictions or special semantics.
-
-    Interactive shells may pose special problems.  The intent is that a
-    future_statement typed at an interactive shell prompt affect all code
-    typed to that shell for the remaining life of the shell session.  It's
-    not clear how to achieve that.
+    no special semantics or syntax restrictions.
 
 
 Example
@@ -222,6 +215,54 @@ Standard Module __future__.py
     intended to be enforced starting in release 2.2.
 
 
+Unresolved Problems:  Runtime Compilation
+
+    Several Python features can compile code during a module's runtime:
+
+    1. The exec statement.
+    2. The execfile() function.
+    3. The compile() function.
+    4. The eval() function.
+    5. The input() function.
+
+    Since a module M containing a future_statement naming feature F
+    explicitly requests that the current release act like a future release
+    with respect to F, any code compiled dynamically from text passed to
+    one of these from within M should probably also use the new syntax or
+    semantics associated with F.
+
+    This isn't always desired, though.  For example, doctest.testmod(M)
+    compiles examples taken from strings in M, and those examples should
+    use M's choices, not necessarily doctest module's choices.
+
+    It's unclear what to do about this.  The initial release (2.1b1) is
+    likely to ignore these issues, saying that each dynamic compilation
+    starts over from scratch (i.e., as if no future_statements had been
+    specified).
+
+    In any case, a future_statement appearing "near the top" (see Syntax
+    above) of text compiled dynamically by an exec, execfile() or compile()
+    applies to the code block generated, but has no further effect on the
+    module that executes such an exec, execfile() or compile().  This
+    can't be used to affect eval() or input(), however, because they only
+    allow expression input, and a future_statement is not an expression.
+
+
+Unresolved Problems:  Interactive Shells
+
+    An interactive shell can be seen as an extreme case of runtime
+    compilation (see above):  in effect, each statement typed at an
+    interactive shell prompt runs a new instance of exec, compile() or
+    execfile().  The initial release (2.1b1) is likely to be such that
+    future_statements typed at an interactive shell have no effect beyond
+    their runtime meaning as ordinary import statements.
+
+    It would make more sense if a future_statement typed at an interactive
+    shell applied to the rest of the shell session's life, as if the
+    future_statement had appeared at the top of a module.  Again, it's
+    unclear what to do about this.
+
+
 Questions and Answers
 
     Q:  What about a "from __past__" version, to get back *old* behavior?