As noted inPEP 236, there is no clear way for “simulatedinteractive shells” to simulate the behaviour of__future__statements in “real” interactive shells, i.e. have__future__statements’ effects last the life of the shell.
The PEP also takes the opportunity to clean up the otherunresolved issue mentioned inPEP 236, the inability to stopcompile() inheriting the effect of future statements affecting thecode callingcompile().
This PEP proposes to address the first problem by adding anoptional fourth argument to the builtin function “compile”, addinginformation to the_Feature instances defined in__future__.py andadding 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 addinganotheroptional argument tocompile(), which if non-zero suppresses theinheriting of future statements’ effects.
I propose adding a fourth, optional, “flags” argument to thebuiltin “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, representingvarious possible compile time options as a bitfield. Thebitfields will have the same values as theCO_* flags already usedby the C part of Python interpreter to refer to future statements.
compile() shall raise aValueError exception if it does notrecognize any of the bits set in the supplied flags.
The flags supplied will be bitwise-“or”ed with the flags thatwould be set anyway, unless the new fifth optional argument is anon-zero integer, in which case the flags supplied will be exactlythe set used.
The above-mentioned flags are not currently exposed to Python. Ipropose adding.compiler_flag attributes to the_Feature objectsin__future__.py that contain the necessary bits, so one mightwrite code such as:
import__future__defcompile_generator(func_def):returncompile(func_def,"<input>","suite",__future__.generators.compiler_flag)
A recent change means that these same bits can be used to tell ifa 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” wascompiled in an environment where generators were allowed.
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 librarymodule codeop.
One -Compile - will sport a__call__ method which will act muchlike the builtin “compile” of 2.1 with the difference that afterit has compiled a__future__ statement, it “remembers” it andcompiles all subsequent code with the__future__ option in effect.
It will do this by using the new features of the__future__ modulementioned above.
Objects of the other class added to codeop -CommandCompiler -will do the job of the existingcodeop.compile_command function,but in a__future__-aware way.
Finally, I propose to modify the classInteractiveInterpreter inthe standard library module code to use aCommandCompiler toemulate still more closely the behaviour of the default Pythonshell.
Should be very few or none; the changes to compile will make nodifference to existing code, nor will adding new functions orclasses to codeop. Existing code usingcode.InteractiveInterpreter may change in behaviour, but only forthe better in that the “real” Python shell will be being betterimpersonated.
The fiddling that needs to be done toLib/__future__.py whenadding a__future__ feature will be a touch more complicated.Everything else should just work.
I hope the above interface is not too disruptive to implement forJython.
A series of preliminary implementations are at[1].
After light massaging by Tim Peters, they have now been checked in.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0264.rst
Last modified:2025-02-01 08:59:27 GMT