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

2001年8月10日 15:45:21 -0700

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv32012
Modified Files:
	pep-0264.txt 
Log Message:
New version. I think this might finally be getting there.
Index: pep-0264.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0264.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** pep-0264.txt	2001年08月08日 15:30:13	1.1
--- pep-0264.txt	2001年08月10日 22:45:19	1.2
***************
*** 1,5 ****
 PEP: 264
 Title: Future statements in simulated shells
! Version: 2
 Author: Michael Hudson <mwh@python.net>
 Status: Draft
--- 1,5 ----
 PEP: 264
 Title: Future statements in simulated shells
! Version: 3
 Author: Michael Hudson <mwh@python.net>
 Status: Draft
***************
*** 17,25 ****
 statements' effects last the life of the shell.

! This short PEP proposes to make this possible by adding an
! optional fourth argument to the builtin function "compile" and
 adding machinery to the standard library modules "codeop" and
 "code" to make the construction of such shells easy.

 Specification
--- 17,35 ----
 statements' effects last the life of the shell.

! The PEP also takes the oppourtunity to clean up the other
! unresolved issue mentioned in PEP 236, the inability to stop
! compile() inheriting the effect of future statements affecting the
! code calling compile().
! 
! This PEP proposes to address the first problem by adding an
! optional fourth argument to the builtin function "compile", adding
! information to the _Feature instances defined in __future__.py and
 adding machinery to the standard library modules "codeop" and
 "code" to make the construction of such shells easy.

+ The second problem is dealt with by simply adding *another*
+ optional argument to compile(), which if non-zero suppresses the
+ inheriting of future statements' effects.
+ 

 Specification
***************
*** 33,44 ****
 bitfields will have the same values as the PyCF_* flags #defined
 in Include/pythonrun.h (at the time of writing there are three -
! PyCF_NESTED_SCOPES, PyCF_GENERATORS and PyCF_DIVISION). These are
! currently not exposed to Python, so I propose adding them to
! codeop.py (because it's already here, basically).

! XXX Should the supplied flags be or-ed with the flags of the
! calling frame, or do we override them? I'm for the former,
! slightly.

 I also propose adding a pair of classes to the standard library
 module codeop.
--- 43,76 ----
 bitfields will have the same values as the PyCF_* flags #defined
 in Include/pythonrun.h (at the time of writing there are three -
! PyCF_NESTED_SCOPES, PyCF_GENERATORS and PyCF_DIVISION).

! compile() shall raise a ValueError exception if it does not
! recognize any of the bits set in the supplied flags.
! 
! The flags supplied will be bitwise-"or"ed with the flags that
! would be set anyway.
! 
! The above-mentioned flags are not currently exposed to Python. I
! propose adding .compiler_flag attributes to the _Feature objects
! in __future__.py that contain the necessary bits, so one might
! write code such as:
! 
! import __future__
! def compile_generator(func_def):
! return compile(func_def, "<input>", "suite",
! __future__.generators.compiler_flag)
! 
! A recent change means that these same bits can be used to tell if
! a code object was compiled with a given feature; for instance
! 
! codeob.co_flags & __future__.generators.compiler_flag

+ 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 also propose adding a pair of classes to the standard library
 module codeop.
***************
*** 48,57 ****
 difference that after it has compiled a __future__ statement, it
 "remembers" it and compiles all subsequent code with the
! __future__ options in effect.

! It will do this by examining the co_flags field of any code object
! it returns, which in turn means writing and maintaining a Python
! version of the function PyEval_MergeCompilerFlags found in
! Python/ceval.c.

 Objects of the other class added to codeop - probably called
--- 80,87 ----
 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
***************
*** 69,73 ****
 Should be very few or none; the changes to compile will make no
 difference to existing code, nor will adding new functions or
! classes to codeop. Exisiting code using
 code.InteractiveInterpreter may change in behaviour, but only for
 the better in that the "real" Python shell will be being better
--- 99,103 ----
 Should be very few or none; the changes to compile will make no
 difference to existing code, nor will adding new functions or
! classes to codeop. Existing code using
 code.InteractiveInterpreter may change in behaviour, but only for
 the better in that the "real" Python shell will be being better
***************
*** 77,111 ****
 Forward Compatibility

! codeop will require very mild tweaking as each new __future__
! statement is added. Such events will hopefully be very rare, so
! such a burden is unlikely to cause significant pain.

 Issues

! Paul Prescod has reasonably complained about the choice of a
! bitfield as the fourth argument to compile(), claiming it is
! obscure and unpythonic.
! 
! There is also the thought of Jython compatibility; because Jython
! has the ability to access any Java object without the PyObject
! cruft needed in CPython, Jython already has a Python-visible
! CompilerFlags object which has a boolean attribute
! "compiler_flags", and will presumably have one fairly soon called
! "generators". This would be doable in CPython, but it would
! require more hacking of deep magical bits of the interpreter and
! require bumping the PYTHON_API_VERSION (OTOH, the division patch
! just went in, so there can't be a freeze on the C API just
! yet...).

 Implementation

! I've uploaded a preliminary implementation as:

 http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470

! I need to add docs and possibly implment a friendlier interface to
! compile().

--- 107,127 ----
 Forward Compatibility

! The check for unrecognised bits in compile() will need updating as
! and when more bits are recognised.

 Issues

! I hope the above interface is not too disruptive to implement for
! Jython.

 Implementation

! I've uploaded a series of (still) preliminary implementations 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.