[Python-checkins] CVS: python/nondist/peps pep-0264.txt,1.1,1.2
Michael Hudson
mwh@users.sourceforge.net
Fri, 10 Aug 2001 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.