Nested scopes resolution -- you can breathe again!

[William Tanksley]

On Fri, 23 Feb 2001 16:17:40 -0500, Tim Peters wrote:
>[Guido]
>>    import __nested_scopes__
>>    from __future__ import nested_scopes

>> 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.

Ah, so this is only intended for experimental code.  Sorry, I just have a
phobia of "temporary" language features.  Obviously, I've seen too many of
them become permanent.

I say skip the warning stuff unless it's really easy.  In release N,
provide a simple way for people to downgrade to the old semantics when
their code doesn't run right.  In release N+1, try to remove that
mechanism.

>> 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).

That is a relief; I was worried that it would never be removed.  Looks
like I misread the post.  I was envisioning a world where all newbies
would be taught to start their Python scripts with five or six lines of
boilerplate to get the useful features :-).

>This puts the burden where it should be (i.e., on the pioneers, not on the
>laggards <0.9 wink>).

The *pioneers* are using CVS, never release versions.  They have enough
troubles in life.  The laggards will never be affected: they're still
using 1.5 (my company is!).  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.

>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.

That's cool.

-- 
-William "Billy" Tanksley