[Python-checkins] CVS: python/nondist/peps pep-0236.txt,1.1,1.2

[Tim Peters]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv21135/python/nondist/peps

Modified Files:
	pep-0236.txt 
Log Message:
Clarify the muddy status of constructs doing runtime compilation.


Index: pep-0236.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0236.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** pep-0236.txt	2001/02/26 20:40:13	1.1
--- pep-0236.txt	2001/02/27 01:13:34	1.2
***************
*** 6,10 ****
  Status: Active
  Type: Standards Track
! Post-History:
  
  
--- 6,11 ----
  Status: Active
  Type: Standards Track
! Created: 26-Feb-2001
! Post-History: 26-Feb-2001
  
  
***************
*** 13,18 ****
      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
      improving the language over the long term, over the short term it's
      contentious and disrupting.
--- 14,19 ----
      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
      improving the language over the long term, over the short term it's
      contentious and disrupting.
***************
*** 27,30 ****
--- 28,33 ----
  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:
***************
*** 50,53 ****
--- 53,61 ----
      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
***************
*** 60,63 ****
--- 68,72 ----
  
          feature: identifier
+         name: identifier
  
      In addition, all future_statments must appear near the top of the
***************
*** 99,116 ****
      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.
- 
      Note that there is nothing special about the statement:
  
--- 108,114 ----
      executed.
  
!     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:
  
***************
*** 118,127 ****
  
      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.
  
  
--- 116,120 ----
  
      That is not a future_statement; it's an ordinary import statement, with
!     no special semantics or syntax restrictions.
  
  
***************
*** 221,224 ****
--- 214,265 ----
      will work in all releases at or after 2.1b1, and that nested_scopes are
      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.