Samuele Pedroni writes:

[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.

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.

...

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? 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 Cheers, M. -- Like most people, I don't always agree with the BDFL (especially when he wants to change things I've just written about in very large books), ... -- Mark Lutz, http://python.oreilly.com/news/python_0501.html