Hi. [Michael Hudson] > Samuele Pedroni <pedroni@inf.ethz.ch> writes: > > > ... > > > > > > > > > > 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. > > Good; hopefully we can get somewhere then. > > > > > > 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. > > Ah, of course. I'd forgotten how cool Jython was in some ways. > > > > 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, > > Well, I don't want to make more work for you - I imagine Guido's doing > enough of that for two! > > > I was only trying to explain our approach and situation and a > > possible way to avoid duplicating some internal code in Python. > > Can you point me to the code in CVS that implements this sort of > thing? I don't really know Java but I can probably muddle through to > some extent. We might as well have CPython copy Jython for once... I don't know if this can help you but the relevant stuff is in: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/modules /codeop.java http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/core/Co mpilerFlags.java http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/core/Py .java see compile_flags http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/compile r/Module.java see compile and PyCode http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/compile r/CodeCompiler.java http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/org/python/compile r/Future.java However implementing this approach in CPython is a bit more demanding because we can import any java class from jython code, in CPython you cannot import a C struct directly (for the obvious reasons) you need an Extension Type :(. regards, Samuele Pedroni.
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