classification
Title: add shorthand global and nonlocal statements
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, akuchling, amaury.forgeotdarc, benjamin.peterson, eric.snow, georg.brandl, gregory.p.smith, jhylton, r.david.murray, rhettinger
Priority: normal Keywords: needs review, patch

Created on 2008-10-24 22:32 by benjamin.peterson, last changed 2013-06-30 14:12 by gregory.p.smith. This issue is now closed.

Files
File name Uploaded Description Edit
global_nonlocal_shorthand.patch benjamin.peterson, 2008-10-24 23:24 review
global_nonlocal_shorthand2.patch benjamin.peterson, 2008-12-06 18:28 review
Messages (20)
msg75193 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-10-24 22:32
PEP 3104 says that the nonlocal and global statements should allow a
shorthand. ("global x; x = 3" == "global x = 3") This patch implements that.
msg77089 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-12-06 01:22
Please review.
msg77134 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-12-06 15:30
- the add_ast_fields() function seems to be added by this patch, but it 
is already in svn.

- Are 1-tuple supported?

    t = [1]
    global a, = t
msg77159 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-12-06 18:28
I think I may have been merging add_ast_fields when I wrote the patch.

Here's a new patch that handles "global x, = (5,)". To do it, I added a
new flag* to the Global and Nonlocal AST objects that indicates whether
the value needs to be unpacked or not.

* The flag is an int. The bool AST type was removed in py3k.
msg88874 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-06-04 10:08
Postponed to 3.2.
msg99705 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2010-02-22 02:58
Bumping priority so this doesn't get forgotten before 3.2; it seems important because it fixes noncompliance with a PEP.
msg99958 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-23 21:37
"High" is not high enough :)
msg99965 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2010-02-23 22:51
Is deferred blocker a higher priority?

Jeremy

On Tue, Feb 23, 2010 at 4:37 PM, Georg Brandl <report@bugs.python.org> wrote:
>
> Georg Brandl <georg@python.org> added the comment:
>
> "High" is not high enough :)
>
> ----------
> priority: high -> deferred blocker
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
>
msg99966 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-23 22:52
I interpret the "Priority" list view contents to be sorted by priority, so "deferred blocker" is the second-highest.
msg99977 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2010-02-23 23:41
On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> I think I may have been merging add_ast_fields when I wrote the patch.
>
> Here's a new patch that handles "global x, = (5,)". To do it, I added a
> new flag* to the Global and Nonlocal AST objects that indicates whether
> the value needs to be unpacked or not.

You shouldn't need to do this.  The unpack is implied if the number of
identifiers is greater than 1.

Jeremy

> * The flag is an int. The bool AST type was removed in py3k.
>
> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
msg99978 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2010-02-23 23:50
I also notice that the Grammar in the PEP is more complicated:
nonlocal_stmt ::=
    "nonlocal" identifier ("," identifier)*
               ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

The Grammar in the patch is:
+global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
+nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]

It appears that the PEP is trying to support:

nonlocal x = y = z = 1
nonlocal a, b = c, d = 1

If we're going to support the PEP as written, I think we need to
modify Global() and Nonlocal() to look exactly like Assign(), but add
an extra check to verify that all of the expressions in the targets
are Name, List, or Tuple.  You'd probably want to check this at the
time you are generating the AST, so that you're not stuck with some
extra state in the compiler traversal about whether you are generating
code for a Global() or an Assign().

This approach makes the compiler code very simple.  We use exactly the
same code for Global(), Nonlocal(), and Assign().  It does have the
downside that you need to enforce this unwritten constraint of the AST
in ast.c and in the ast module.

It also means that the AST will change in a non-backwards compatible
way.  I don't see how to do that given that we're also changing the
language spec.  (Do you want to include the spec change in your
patch?)

Jeremy

On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton <jeremy@alum.mit.edu> wrote:
> On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
> <report@bugs.python.org> wrote:
>>
>> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>>
>> I think I may have been merging add_ast_fields when I wrote the patch.
>>
>> Here's a new patch that handles "global x, = (5,)". To do it, I added a
>> new flag* to the Global and Nonlocal AST objects that indicates whether
>> the value needs to be unpacked or not.
>
> You shouldn't need to do this.  The unpack is implied if the number of
> identifiers is greater than 1.
>
> Jeremy
>
>
>
>> * The flag is an int. The bool AST type was removed in py3k.
>>
>> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>>
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <http://bugs.python.org/issue4199>
>> _______________________________________
>> _______________________________________________
>> Python-bugs-list mailing list
>> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>>
>>
>
msg100015 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-24 09:20
> I also notice that the Grammar in the PEP is more complicated:
> nonlocal_stmt ::=
>     "nonlocal" identifier ("," identifier)*
>                ["=" (target_list "=")+ expression_list]
>   | "nonlocal" identifier augop expression_list
> 
> The Grammar in the patch is:
> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
> 
> It appears that the PEP is trying to support:
> 
> nonlocal x = y = z = 1
> nonlocal a, b = c, d = 1

It also tries to support augmented assignment; however I'm not sure what the semantics of that should be.

Further, there is an ambiguity if too much freedom is allowed: what about

   global x = 1, y

Is it declaring a global "x" and assigning a tuple, or declaring a global "x" and a global "y"?

> If we're going to support the PEP as written, I think we need to
> modify Global() and Nonlocal() to look exactly like Assign(), but add
> an extra check to verify that all of the expressions in the targets
> are Name, List, or Tuple.  You'd probably want to check this at the
> time you are generating the AST, so that you're not stuck with some
> extra state in the compiler traversal about whether you are generating
> code for a Global() or an Assign().

I would not support List or Tuple as targets.  Same basic problem as 
above, and I don't see a use case.

I see two possibilities for the actual syntax:

1) global *either* supports multiple identifiers, *or* one identifier 
and an assignment.

2) global always supports multiple identifiers, each with an optional 
assignment; tuples need parentheses.

In both cases, I would keep it simple and not allow multiple targets or 
augmented assignment.
msg100043 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2010-02-24 16:24
I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved.  If so, I'm not sure that
we want to re-open the discussion.  On the other hand, it's been a
long time since the PEP was approved and we do have a moratorium on
language changes, so it doesn't hurt to slow things down.

I'd argue that the intent of the PEP is pretty clear.  You can take
any assignment statement where the LHS doesn't have subscripts, put a
nonlocal or global in front of it, and it means that all those
assignments are to global/nonlocal variables.

Jeremy

On Wed, Feb 24, 2010 at 4:20 AM, Georg Brandl <report@bugs.python.org> wrote:
>
> Georg Brandl <georg@python.org> added the comment:
>
>> I also notice that the Grammar in the PEP is more complicated:
>> nonlocal_stmt ::=
>>     "nonlocal" identifier ("," identifier)*
>>                ["=" (target_list "=")+ expression_list]
>>   | "nonlocal" identifier augop expression_list
>>
>> The Grammar in the patch is:
>> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
>> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
>>
>> It appears that the PEP is trying to support:
>>
>> nonlocal x = y = z = 1
>> nonlocal a, b = c, d = 1
>
> It also tries to support augmented assignment; however I'm not sure what the semantics of that should be.
>
> Further, there is an ambiguity if too much freedom is allowed: what about
>
>   global x = 1, y
>
> Is it declaring a global "x" and assigning a tuple, or declaring a global "x" and a global "y"?
>
>> If we're going to support the PEP as written, I think we need to
>> modify Global() and Nonlocal() to look exactly like Assign(), but add
>> an extra check to verify that all of the expressions in the targets
>> are Name, List, or Tuple.  You'd probably want to check this at the
>> time you are generating the AST, so that you're not stuck with some
>> extra state in the compiler traversal about whether you are generating
>> code for a Global() or an Assign().
>
> I would not support List or Tuple as targets.  Same basic problem as
> above, and I don't see a use case.
>
> I see two possibilities for the actual syntax:
>
> 1) global *either* supports multiple identifiers, *or* one identifier
> and an assignment.
>
> 2) global always supports multiple identifiers, each with an optional
> assignment; tuples need parentheses.
>
> In both cases, I would keep it simple and not allow multiple targets or
> augmented assignment.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
>
msg100188 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-02-27 16:33
I do think a brief discussion after the moratorium is over would be good.
msg110694 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-18 21:56
I'm not sure as to the status of this.  Could it go back to (say) 3.3, is it still a candidate for 3.2(.x), or what?
msg110698 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-07-18 22:48
2010/7/18 Mark Lawrence <report@bugs.python.org>:
>
> Mark Lawrence <breamoreboy@yahoo.co.uk> added the comment:
>
> I'm not sure as to the status of this.  Could it go back to (say) 3.3, is it still a candidate for 3.2(.x), or what?

It can't do anything until 3.3.
msg155723 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-14 06:11
We could also just decide we don't need it :)

If we do (I haven't read the PEP) does a statement with an assignment make the variable global in that scope, or does it only affect the global variable for the duration of the assignment, and otherwise the variable remains local in the scope?  (I don't know which to guess, and the ambiguity is disturbing.  I like the current clarity even if it is more typing.)
msg155865 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2012-03-15 06:35
+1 on the feature as described in the PEP.
msg192049 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2013-06-29 21:49
Bumping version to 3.4.  I'll send a note to python-dev about this issue.
msg192070 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2013-06-30 14:12
Closing and rejecting based on said discussion. http://mail.python.org/pipermail/python-dev/2013-June/127143.html
History
Date User Action Args
2013-06-30 14:12:36gregory.p.smithsetstatus: open -> closed

nosy: + gregory.p.smith
messages: + msg192070

resolution: rejected
2013-06-29 21:49:40akuchlingsetmessages: + msg192049
versions: + Python 3.4, - Python 3.3
2012-03-15 06:35:26rhettingersetnosy: + rhettinger
messages: + msg155865
2012-03-15 05:44:57eric.snowsetnosy: + eric.snow
2012-03-14 06:11:49r.david.murraysetnosy: + r.david.murray
messages: + msg155723
2010-07-24 13:19:03ronaldoussorensetversions: + Python 3.3, - Python 3.2
2010-07-18 22:48:48benjamin.petersonsetmessages: + msg110698
2010-07-18 21:56:12BreamoreBoysetnosy: + BreamoreBoy
messages: + msg110694
2010-02-27 17:29:09benjamin.petersonsetpriority: deferred blocker -> normal
2010-02-27 16:33:26georg.brandlsetmessages: + msg100188
2010-02-24 16:24:54jhyltonsetmessages: + msg100043
2010-02-24 09:20:20georg.brandlsetmessages: + msg100015
2010-02-23 23:50:08jhyltonsetmessages: + msg99978
2010-02-23 23:41:08jhyltonsetmessages: + msg99977
2010-02-23 22:52:54georg.brandlsetmessages: + msg99966
2010-02-23 22:51:37jhyltonsetmessages: + msg99965
2010-02-23 21:37:24georg.brandlsetpriority: high -> deferred blocker

messages: + msg99958
2010-02-22 02:58:57akuchlingsetpriority: normal -> high
nosy: + akuchling
messages: + msg99705

2009-11-04 22:46:02pitrousetpriority: critical -> normal
2009-06-04 10:08:18georg.brandlsetnosy: + georg.brandl

messages: + msg88874
versions: + Python 3.2, - Python 3.1
2009-03-31 16:16:43jhyltonsetnosy: + jhylton
2008-12-08 01:10:52benjamin.petersonsetpriority: high -> critical
2008-12-06 18:28:37benjamin.petersonsetfiles: + global_nonlocal_shorthand2.patch
messages: + msg77159
2008-12-06 15:30:49amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg77134
2008-12-06 01:22:54benjamin.petersonsetkeywords: + needs review
type: enhancement
messages: + msg77089
stage: patch review
2008-10-24 23:24:46benjamin.petersonsetfiles: + global_nonlocal_shorthand.patch
2008-10-24 22:47:09benjamin.petersonsetfiles: - global_nonlocal_short_assign.patch
2008-10-24 22:32:14benjamin.petersoncreate