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

[Samuele Pedroni]

After maybe too short thinking here's an idea along the line keep it simple:

1 ) from __future__ import foofeature
* I imagine is more for semantic and syntax changes so it is better if near too
the code
assuming or needing them.
So there should be no defaults, each compilation unit (module, exec string,
...) that need the feature
should explicitly contain the from import ... (at least for hard-coded execs I
see few need to require
nested scopes in them so that's not a big problem, for other future features I
don't know).
* It should be allowed only at module scope indent 0,
all post 2.1 compiler will be able to deal with __future__, so putting a try
around the import make few sense,
a compile-time error will be issued if the feature is not supported.
For pre 2.1 compiler I see few possibilities of writing backward compatible
code using the from __future__ import ,
unless one want following to work:
 try:
  from __future__ import foofeature
 # code needing new syntax or assuming new semantic
except ImportError:
 # old style code
if the change does not involve syntax this code will work with a pre 2.1
compiler,
but >2.1 compilers  should be able to recognize the idiom or use some kind of
compile-time evalutation,
both IMO will require a bunch of special rules and are not that easy to
implement.
Backward and more compiler friendly code can be written using package or module
wrappers:
 try:
  import __future__
 # check if feature is there
 from module_using_fetature import * # this will contain from __future__ import
feature
execpt ImportError:
 from module_not_using_feature import *

2) interactive mode:
 * respecting the above rules
  >>>from __future__  import featujre
  will activate the feature only in the one-line compilation unit => it has no
effect, this can be confusing but it's a coherent
  behaviour,
  the other way people will be tempted to ask why importing a feature in a file
does not influence the others...

 At the moment I see two solutions:
 - supporting the following idiom (I mean everywhere): at top-level indent 0
  if 1:
     from __future__ import foofeature
     ....

- having a cmd-line switch that says what futures are on for the compilation
units entered at top-level in an interactive
  session.

This is just a sketch and a material for further reflection.

OTOH the implicit other proposal is that if code X will endup being executed
having its global namespaces containing
a feature cookie coming from __future__ because of an explicit "from import" or
because so is the global namespace
passed to exec,etc . ; then X should be compiled with the feature on.

regards, Samuele Pedroni