proposal: bring nonlocal to py2.x

[Terry Reedy]

On 1/15/2014 7:07 AM, Robin Becker wrote:
> On 13/01/2014 15:28, Chris Angelico wrote:
> ..........
>>
>> It's even worse than that, because adding 'nonlocal' is not a bugfix.
>> So to be committed to the repo, it has to be approved for either 2.7
>> branch (which is in bugfix-only maintenance mode) or 2.8 branch (which
>> does not exist). Good luck. :)
> .......
> fixing badly named variables is not a bug fix either, but that has
> happened in python 2.7. A micro change release changed
>
> compiler.consts.SC_GLOBAL_EXPLICT
> to
> compiler.consts.SC_GLOBAL_EXPLICIT
>
> this is a change of api for the consts module (if you regard exported
> variables as part of its api),

A bug is generally a discrepancy between the doc the defines a version 
of the language and the code that implements that version. Yes, code 
fixes break code that depends on the bug, which is why tests should be 
run with bug-fix releases, and why some bug fixes are treated as 
enhancements and not back-ported. They also fix current and future code 
written to the specification.

Since the compiler.consts submodule is not documented, I believe it was 
regarded as an internal module for use only by the pycodegen and symbols 
modules. The misspelling was introduced in the patch for
   http://bugs.python.org/issue999042
which also introduced SC_GLOBAL_IMPLICIT, correctly spelled. EXPLICT was 
fixed in all three modules by Antoine Pitrou in
   http://bugs.python.org/issue15212

In any case, I estimate the impact of backporting a major new feature 
like a new keyword to be at least 100000 times that of this spelling fix.

 > but that didn't count for the developers.

If you are suggesting that developers casually violate out policy of 
only bug fixes in microreleases, that is unfair and false. It is mostly 
users who push at us to backport their favorite new feature. Antoine 
strongly supports and enforces the policy, as do I.

-- 
Terry Jan Reedy