proposal: bring nonlocal to py2.x

[Neal Becker]

py3 includes a fairly compelling feature: nonlocal keywork
But backward compatibility is lost. It would be very helpful
if this was available on py2.x.

[Chris Angelico]

Python 2.x is no longer being developed. It won't be gaining features
like this. Use the nonlocal feature as a reason for migrating to
Python 3 :)

ChrisA

[Giampaolo Rodola']

On Mon, Jan 13, 2014 at 3:47 PM, Neal Becker <ndbe...@gmail.com> wrote:

py3 includes a fairly compelling feature: nonlocal keywork
But backward compatibility is lost.  It would be very helpful
if this was available on py2.x.

--
https://mail.python.org/mailman/listinfo/python-list

It's not gonna happens as per PEP-404:

http://www.python.org/dev/peps/pep-0404/

--

Giampaolo - http://grodola.blogspot.com

[Mark Lawrence]

On 13/01/2014 15:12, Giampaolo Rodola' wrote:
>
> On Mon, Jan 13, 2014 at 3:47 PM, Neal Becker <ndbe...@gmail.com
> <mailto:ndbe...@gmail.com>> wrote:
>
> py3 includes a fairly compelling feature: nonlocal keywork
> But backward compatibility is lost. It would be very helpful
> if this was available on py2.x.
>

> It's not gonna happens as per PEP-404:
> http://www.python.org/dev/peps/pep-0404/
>

But it could theoretically happen if Neal wants it so badly that he
raises an issue on the bug tracker against Python 2.7, finds all the
relevant source code in Python 3, back ports it, modifies all the
relevant docs and unit tests, then finds some warm hearted person to
commit the changes. Five minute job. Simples :)

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[Chris Angelico]

On Tue, Jan 14, 2014 at 2:24 AM, Mark Lawrence <bream...@yahoo.co.uk> wrote:
> But it could theoretically happen if Neal wants it so badly that he raises
> an issue on the bug tracker against Python 2.7, finds all the relevant
> source code in Python 3, back ports it, modifies all the relevant docs and
> unit tests, then finds some warm hearted person to commit the changes. Five
> minute job. Simples :)

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

ChrisA

[Mark Lawrence]

Then target the 2.8 fork that will take place if there's no agreement
over PEP 460. Still a five minute job, still simples :)

[Terry Reedy]

On 1/13/2014 9:47 AM, Neal Becker wrote:
> py3 includes a fairly compelling feature: nonlocal keywork

[keyword]

> But backward compatibility is lost.

I am not sure what your particular point is. Every new feature, in any
release, if used, makes code not compatible with earlier releases that
do not have the feature. Every new feature is compelling to someone, and
to use it, one must use a version that has it.

> It would be very helpful if this was available on py2.x.

For every new feature, there is someone who thinks it would be helpful
if it were availale in an earlier version. Backports of library features
are sometimes available on PyPI, but this cannot be done for syntax
features like 'nonlocal'.

'2.x' refers to a sequence of feature-frozen versions. It literally
means '2.0 to 2.7', but may refer to '2.2 to 2.7' (because 2.2 gained
new classes and iterators) or even a more restricted sequence. Core
developers consider 3.2, or maybe a later version, to be the successor
of 2.7.

--
Terry Jan Reedy

[Robin Becker]

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), but that didn't count for the developers.
--
Robin Becker

[Chris Angelico]

Hmm. I'd say that one's arguable; that's clearly a misspelled name. It
comes down to the release manager's decision on points like that. I
would say that adding a new keyword and a whole pile of new semantics
is a bit bigger than renaming one constant :) But yes, this could
break code in a point release, and that's a potential issue.

ChrisA

[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