Nested scopes resolution -- you can breathe again!

[Tim Peters]

[Guido]
>    import __nested_scopes__
>    from __future__ import nested_scopes

[William Tanksley]
> I like the second version.  That's quite cool.

I'd have a hard time guessing that from the rest of this msg <wink>.

> ...
> And perhaps _old_ code should bear the brunt of the change, with one of
> the features being old_unnested_scoping. This way we don't have to keep a
> default that's deprecated forever.

No.  The point of the scheme is to let motivated people use release N+1
features in release N without anyone else needing to change any of their
code.  To the extent possible, release N will instead produce warnings about
code that *will* break in release N+1.  Nobody is required to endure N+1
semantics before N+1; but people who want to experiment with N+1 features in
N can do so by explicitly asking for them.

> So we'd never see the line "from __features__ import nested_scoping";
> that would become an anachonism, and would quickly get irritating.

Good!  That means people will be motivated to get rid of it when it becomes
an anachronism (in N+1).  This puts the burden where it should be (i.e., on
the pioneers, not on the laggards <0.9 wink>).  BTW, for reasons to be
explained in an upcoming PEP, it will be very easy to find unneeded
__future__ imports as the millennia roll by.

> Instead, we'd see "from __features__ import old_unnested_scoping" at
> the head of modules which won't compile without warning.

In release N+1, release N semantics are *gone*.  There's no going back, else
the Python implementation would become an unboundedly complicated mess as
the years go by, and so would Python programs.  __future__ is for
incompatible changes, not for optional behaviors.  If, at release N+1, you
refuse to move to release N+1 semantics, fine:  stay with release N forever.
That's your choice.