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

[Tim Peters]

[Jeremy Hylton]
> Hmmmm...  I'm not yet sure how to deduce indent level 0 inside the
> parser.

[Thomas Wouters]
> Uhm, why are we adding that restriction anyway, if it's hard for the
> parser/compiler to detect it ?

I talked with Jeremy, and turns out it's not.

> I think I'd like to put them in try/except or if/else clauses, for
> fully portable code.

And, sorry, but I take back saying that we should allow that.  We shouldn't.
Despite that it looks like an import statement (and actually *is* one, for
that matter), the key info is extracted at compile time.  So in stuff like

if x:
    from __future__ import alabaster_weenoblobs

whether or not alabaster_weenoblobs is in effect has nothing to do with the
runtime value of x.  So it's plain Bad to allow it to look as if it did.
The only stuff that can textually precede:

    from __future__ import f

is:

+ The module docstring (if any).
+ Comments.
+ Blank lines.
+ Other instances of from __future__.

This also makes clear that one of these things applies to the entire module.

Again, the thrust of this is *not* to help in writing portable code.  It's
to help users upgrade to the next release, in two ways:  (1) by not breaking
their code before the next release; and, (2) to let them migrate their code
to next-release semantics incrementally.

Note:  "next release" means whatever MandatoryRelease is associated with the
feature of interest.

"Cross version portable code" is a more pressing problem for some, but is
outside the scope of this gimmick. *This* gimmick is something we can
actually do <0.5 wink>.