Draft PEP (RE: Other situations like this (was RE: [Python-Dev] Nested scopes resolution -- you can breathe again!))

[Guido van Rossum]

>     Since a module M containing a future_statement naming feature F
>     explicitly requests that the current release act like a future release
>     with respect to F, any code interpreted dynamically from an eval, exec
>     or execfile executed by M will also use the new syntax or semantics
>     associated with F.

This means that a run-time flag must be available for inspection by
eval() and execfile(), at least.

I'm not sure that I agree with this for execfile() though -- that's
often used by mechanisms that emulate module imports, and there it
would be better if it started off with all features reset to their
default.

I'm also not sure about exec and eval() -- it all depends on the
reason why exec is being invoked.

Plus, exec and eval() also take a compiled code object, and there it's
too late to change the future.

Which leads to the question: should compile() also inherit the future
settings?

It's certainly a lot easier to implement if exec c.s. are *not*
affected by the future selection of the invoking environment.  And if
you *want* it, at least for exec, you can insert the future_statement
in front of the executed code string.

>     Interactive shells may pose special problems.  The intent is that a
>     future_statement typed at an interactive shell prompt affect all code
>     typed to that shell for the remaining life of the shell session.  It's
>     not clear how to achieve that.

The same flag that I mentioned above can be used here -- basically, we
can treat each interactive command as an "exec".  Except that this
time, the command that is the future_statement *does* export its flag
to the invoking environment.  Plus, I've made a good case against the
flag. :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)