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

[Tim Peters]

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

Modified Files:
	pep-0236.txt 
Log Message:
Update resolved, unresolved and partially resolved issues to reflect Jeremy's
2.1b2 work.


Index: pep-0236.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0236.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -r1.5 -r1.6
*** pep-0236.txt	2001/03/02 03:11:53	1.5
--- pep-0236.txt	2001/03/25 05:54:08	1.6
***************
*** 215,219 ****
  
  
! Unresolved Problems:  Runtime Compilation
  
      Several Python features can compile code during a module's runtime:
--- 215,219 ----
  
  
! Paritally Resolved Problem:  Runtime Compilation
  
      Several Python features can compile code during a module's runtime:
***************
*** 229,243 ****
      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()
--- 229,240 ----
      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.  The 2.1 release does behave this way.
  
      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 the doctest module's choices.  In the
!     2.1 release, this isn't possible, and no scheme has yet been suggested
!     for working around this.
  
      In any case, a future_statement appearing "near the top" (see Syntax
      above) of text compiled dynamically by an exec, execfile() or compile()
***************
*** 247,264 ****
      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.
  
  
--- 244,272 ----
      allow expression input, and a future_statement is not an expression.
  
+ 
+ Resolved Problem:  Native Interactive Shells
+ 
+     There are two ways to get an interactive shell:
  
!     1. By invoking Python from a command line without a script argument.
  
+     2. By invoking Python from a command line with the -i switch and with a
+        script argument.
+ 
      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().  A future_statement typed at an interactive shell applies to
!     the rest of the shell session's life, as if the future_statement had
!     appeared at the top of a module.
! 
! 
! Unresolved Problem:  Simulated Interactive Shells
! 
!     Interactive shells "built by hand" (by tools such as IDLE and the Emacs
!     Python-mode) should behave like native interactive shells (see above).
!     However, the machinery used internally by native interactive shells has
!     not been exposed, and there isn't a clear way for tools building their
!     own interactive shells to achieve the desired behavior.