... > > > > > > 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. > > Would implementing the new interfaces I sketched out for codeop.py be > possible in Jython? That's the bit I care about, not so much the > interface to __builtin__.compile. Yes, it's of possible. > > > 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 ... > > Is this object exposed to Python code at all? Not publicily, but in Jython the separating line is a bit different, because public java classes are always accessible from jython, even most of the internals. That does not mean and every use of that is welcome and supported. > One approach would be > PyObject-izing PyFutureFlags and making *that* the fourth argument to > compile... > > class Compiler: > def __init__(self): > self.ff = ff.new() # or whatever > def __call__(self, source, filename, start_symbol): > code = compile(source, filename, start_symbol, self.ff) > self.ff.merge(code.co_flags) > return code I see, "internally" we already have a compiler_flags function that do the same of: > code = compile(source, filename, start_symbol, self.ff) > self.ff.merge(code.co_flags) where self.ff is a CompuilerFlags object. I can re-arrange things for any interface, I was only trying to explain our approach and situation and a possible way to avoid duplicating some internal code in Python. 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