121 lines
4.2 KiB
Plaintext
121 lines
4.2 KiB
Plaintext
|
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:
|