diff --git a/pep-0236.txt b/pep-0236.txt index 7078c12e8..7f0a360d1 100644 --- a/pep-0236.txt +++ b/pep-0236.txt @@ -5,15 +5,16 @@ Author: Tim Peters 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?