[Python-checkins] CVS: python/nondist/peps pep-0264.txt,NONE,1.1 pep-0000.txt,1.113,1.114
Guido van Rossum
gvanrossum@users.sourceforge.net
Wed, 08 Aug 2001 08:30:15 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv5695
Modified Files:
pep-0000.txt
Added Files:
pep-0264.txt
Log Message:
Add Michael Hudson's "Future statements in simulated shells".
--- NEW FILE: pep-0264.txt ---
PEP: 264
Title: Future statements in simulated shells
Version: 2
Author: Michael Hudson <mwh@python.net>
Status: Draft
Type: Standards Track
Requires: 236
Created: 30-Jul-2001
Python-Version: 2.2
Post-History: 30-Jul-2001
Abstract
As noted in PEP 263, there is no clear way for "simulated
interactive shells" to simulate the behaviour of __future__
statements in "real" interactive shells, i.e. have __future__
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
I propose adding a fourth, optional, "flags" argument to the
builtin "compile" function. If this argument is omitted,
there will be no change in behaviour from that of Python 2.1.
If it is present it is expected to be an integer, representing
various possible compile time options as a bitfield. The
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.
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__ 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
CommandCompiler or somesuch - 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
emulate still more closely the behaviour of the default Python
shell.
Backward Compatibility
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
impersonated.
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().
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
Index: pep-0000.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v
retrieving revision 1.113
retrieving revision 1.114
diff -C2 -d -r1.113 -r1.114
*** pep-0000.txt 2001/08/01 20:11:56 1.113
--- pep-0000.txt 2001/08/08 15:30:13 1.114
***************
*** 60,63 ****
--- 60,64 ----
S 262 pep-0262.txt Database of Installed Python Packages Kuchling
S 263 pep-0263.txt Defining Python Source Code Encodings Lemburg
+ S 264 pep-0264.txt Future statements in simulated shells Hudson
Py-in-the-sky PEPs (not considered for Python 2.2)
***************
*** 205,208 ****
--- 206,210 ----
S 262 pep-0262.txt Database of Installed Python Packages Kuchling
S 263 pep-0263.txt Defining Python Source Code Encodings Lemburg
+ S 264 pep-0264.txt Future statements in simulated shells Hudson
***************
*** 228,231 ****
--- 230,234 ----
Evans, Clark C. cce@clarkevans.com
Goodger, David dgoodger@bigfoot.com
+ Hudson, Michael mwh@python.net
Hylton, Jeremy jeremy@zope.com
Kuchling, Andrew akuchlin@mems-exchange.org