iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update to reflect what actually happened (should have done this 

ages ago).  I think this PEP can now be marked final.
This commit is contained in:
Michael W. Hudson 2001-10-26 08:05:48 +00:00
parent 094902237e
commit a41ef076fd
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
pep-0264.txt
View File

@ -1,6 +1,6 @@
PEP: 264
Title: Future statements in simulated shells
Version: 3
Version: 4
Author: Michael Hudson <mwh@python.net>
Status: Accepted
Type: Standards Track
@ -69,25 +69,24 @@ Specification
will be non-zero if and only if the code object "codeob" was
compiled in an environment where generators were allowed.
I will also add a .__all__ attribute to the __future__ module,
giving a low-effort way of enumerating all the __future__ options
supported by the running interpreter.
I will also add a .all_feature_flags attribute to the __future__
module, giving a low-effort way of enumerating all the __future__
options supported by the running interpreter.
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__ option in effect.
One - 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__ option in effect.
It will do this by using the new features of the __future__ module
mentioned above.
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.
Objects of the other class added to codeop - CommandCompiler -
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
@ -107,8 +106,9 @@ Backward Compatibility
Forward Compatibility
The check for unrecognised bits in compile() will need updating as
and when more bits are recognised.
The fiddling that needs to be done to Lib/__future__.py when
adding a __future_ feature will be a touch more complicated.
Everything else should just work.
Issues
@ -119,11 +119,11 @@ Issues
Implementation
I've uploaded a series of (still) preliminary implementations at:
A series of preliminary implementations are at:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470
I still need to do docs (I've done docstrings) and tests.
After light massagin by Tim Peters, they have now been checked in.
Copyright