Nested scopes resolution -- you can breathe again!

[Tim Peters]

[Tim, on __future__]
>> 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.

[William Tanksley]
> Ah, so this is only intended for experimental code.

No, it's to allow people to migrate incrementally, on a module-by-module
basis, to release N+1 semantics while they're still happily running release
N under release N-1 semantics.

> Sorry, I just have a phobia of "temporary" language features.

Nothing temporary about it.  For example, nested scopes will be THE rule in
2.2.  2.1 will let you get ready for that change, via __future__, without
yet forcing the issue, should you happen to have old code that may break.

> ...
> I say skip the warning stuff unless it's really easy.

The warning stuff is essential.

> In release N, provide a simple way for people to downgrade to the
> old semantics when their code doesn't run right.

Why?  The default is not to break old code, which is overwhelmingly more
often requested.

> In release N+1, try to remove that mechanism.

Six of one, half dozen of the other to me, except that there's no "try" in
N+1, the old behavior is history then.

> ...
> The middle-of-the-road people will upgrade to a new version to get
> compelling new features, and will be discouraged to hear that one
> of the compelling new features has to be accessed in a manner which
> will become obsolete shortly.

1. This has nothing to do with new features per se.  It's for incompatible
   changes.  "incompatible" is key there.  You'll never need a __future__
   statement just to get a new feature, unless that feature *also* has
   the potential to *break* old code.  So, for example, had we done this
   earlier in Python's life, you would NOT have needed a __future__
   statement to get at list comprehensions or print>>.  Those were wholly
   backward compatible.  You WOULD have needed it long ago when "lambda"
   was introduced, because that added a new keyword and so broke any old
   code that used "lambda" as a vrbl, function, class or attribute name.

2. Not obsolete, simply unnecessary -- at N+1 they don't *need* the old
   __future__s anymore, but they're still allowed.

Note too that incompatible changes typically break few lines of code,
although that will vary by user.  For example, the nested scopes change
breaks perhaps three lines of Python in the standard distribution.  So we
normally anticipate that __future__ will get used in only a small percentage
of modules, and usually where people are playing on the edge of the
language, or even in direct violation of what the Language Reference Manual
has said all along (which appears to be the case with real-life nested scope
breakage so far).

it's-not-a-dessert-topping-it's-a-floor-wax-ly y'rs  - tim