[GvR] > > > [Michael Hudson] > > > 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. > > > FYI, in Jython (internally) we have a series of compile_flags functions > > that take a "opaque" object CompilerFlags that is passed to the function > > and compilation actually change the object in order to reflect future > > statements encoutered during compilation... > > Not elegant but avoids code duplication. > > > > Of course we can change that. > > Does codeop currently work in Jython? The solution should continue to > work in Jython then. We have our interface compatible version of codeop that works. > Does Jython support the same flag bit values as > CPython? If not, Paul Prescod's suggestion to use keyword arguments > becomes very relevant. we support a subset of the co_flags, CO_NESTED e.g. is there with the same value. But the embedding API is very different, my implementation of nested scopes does not define any Py_CF... flags, we have an internal CompilerFlags object but is more similar to PyFutureFeatures ... Samuele.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4