Guido van Rossum writes:

...

Not directly relavent to the PEP, but...

Guido van Rossum writes:

...

Q. What about code compiled by the codeop module?

A. Alas, this will always use the default semantics (set by the -D command line option). This is a general problem with the future statement; PEP 236[4] lists it as an unresolved problem. You could have your own clone of codeop.py that includes a future division statement, but that's not a general solution.

Did you look at my Nasty Hack(tm) to bodge around this? It's at

http://starship.python.net/crew/mwh/hacks/codeop-hack.diff

if you haven't. I'm not sure it will work with what you're planning for division, but it works for generators (and worked for nested scopes when that was relavent).

Ouch. Nasty. Hat off to you for thinking of this!

I'll choose to take this as a positive remoark :-)

...

There are a host of saner ways round this, of course - like adding an optional "flags" argument to compile, for instance.

We'll have to keep that in mind.

Here's a fairly short pre-PEP on the issue. If I haven't made any gross editorial blunders, can Barry give it a number and check the sucker in? PEP: XXXX Title: Supporting __future__ statements in simulated shells Version: $Version:$ Author: Michael Hudson Status: Draft Type: Standards Track Requires: 0236 Created: 30-Jul-2001 Python-Version: 2.2 Post-History: Abstract As noted in PEP 263, there is no clear way for "simulated interactive shells" to simulate the behaviour of __future__ statements in "real" interactive shells, i.e. have __future__ statements' effects last the life of the shell. This short PEP proposes to make this possible by adding an optional fourth argument to the builtin function "compile" and adding machinery to the standard library modules "codeop" and "code" to make the construction of such shells easy. Specification I propose adding a fourth, optional, "flags" argument to the builtin "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, representing various possible compile time options as a bitfield. The bitfields will have the same values as the PyCF_* flags #defined in Include/pythonrun.h (at the time of writing there are only two - PyCF_NESTED_SCOPES and PyCF_GENERATORS). These are currently not exposed to Python, so I propose adding them to codeop.py (because it's already here, basically). XXX Should the supplied flags be or-ed with the flags of the calling frame, or do we override them? I'm for the former, slightly. I also propose adding a pair of classes to the standard library module codeop. 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. Objects of the other class added to codeop - probably called CommandCompiler or somesuch - will do the job of the existing codeop.compile_command function, but in a __future__-aware way. Finally, I propose to modify the class InteractiveInterpreter in the standard library module code to use a CommandCompiler to emulate still more closely the behaviour of the default Python shell. Backward Compatibility Should be very few or none; the changes to compile will make no difference to existing code, nor will adding new functions or classes to codeop. Exisiting code using code.InteractiveInterpreter may change in behaviour, but only for the better in that the "real" Python shell will be being better impersonated. Forward Compatibility codeop will require very mild tweaking as each new __future__ statement is added. Such events will hopefully be very rare, so such a burden is unlikely to cause significant pain. Implementation None yet; none of the above should be at all hard. If this draft is well received, I'll upload a patch to sf "soon" and point to it here. Copyright This document has been placed in the public domain. -- ARTHUR: The ravenours bugblatter beast of Traal ... is it safe? FORD: Oh yes, it's perfectly safe ... it's just us who are in trouble. -- The Hitch-Hikers Guide to the Galaxy, Episode 6