classification
Title: Globalize lonely augmented assignment
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, mark.dickinson, serprex
Priority: normal Keywords: patch

Created on 2010-06-11 20:26 by serprex, last changed 2010-06-12 16:53 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
symtable.diff serprex, 2010-06-11 20:26
diff.2 serprex, 2010-06-12 15:53
Messages (8)
msg107581 - (view) Author: Demur Rumed (serprex) Date: 2010-06-11 20:26
A=[1,2,3]
def f(x):
    A+=x,

This throws an error. The solution: state "global a". I find it odd that augmented assignment should be viewed the same as assignment in descerning local variables. This patch repairs such to maintain a as a variable of the global namespace

Some might find the following an issue

def f(x):
    if x:
        A+=4,
    else:
        A=[3]
    print("f",x,A)
def g(x):
    if not x:
        A=[3]
    else:
        A+=4,
    print("g",x,A)

In f, A is a global variable. In g, A is a local variable. Thus g(1) throws UnboundLocalError while f(1) appends 4 to A
msg107582 - (view) Author: Demur Rumed (serprex) Date: 2010-06-11 20:33
A note on the patch, ste->ste_tmpname... lines, along with changes to Lambda_kind, were not added by me. The additional newlines prior to symtable_visit_stmt's declaration are accidental, apologies. I'll avoid patching a snapshot and then pull the old version from hg after realizing I need the old version to run diff on next time
msg107584 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 20:59
This seems evil to me, when you consider the effect of this patch on immutable types:

>>> A = 3
>>> def f():
...     A += 5
... 
>>> f()
>>> A
8

I find the possibility that a function can implicitly (i.e., without any 'global' declarations) mutate my global module constants... disturbing.

Anyway, such a fundamental change would need proper discussion;  the right place for that is the python-ideas mailing list rather than the tracker:

http://mail.python.org/mailman/listinfo/python-ideas

Note also that there's a moratorium on core language changes in effect at the moment, so the earliest this could change is Python 3.3.

I'm going to close this issue for now;  if the idea gets a good reception on python-ideas it can be reopened.
msg107586 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2010-06-11 21:48
It's not that much more evil than this:

A = []

def f(x):
  A.append(x)

print(A)  # []
f(4)
print(A)  # [4]

I've always thought this is a borderline case.
msg107594 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 22:08
True.  I guess there's a mismatch either way around:  currently,
"A += [4]" and "A.append(4)" behave differently for (e.g.,) a list A.  With the proposed change, "n += 3" and "n = n + 3" behave differently for a integer n.  I'm not sure why I find the latter idea more disturbing than the former.
msg107603 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2010-06-11 23:07
Because the latter (n += 1) is more fundamental, since it uses integers (arguably the most fundamental type).

This is why we've never done it before.
msg107665 - (view) Author: Demur Rumed (serprex) Date: 2010-06-12 15:53
I've modified the patch to be less aggressive, as suggested by Nick at http://mail.python.org/pipermail/python-ideas/2010-June/007428.html

As an aside, runtests.sh should have executable permissions
msg107671 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-12 16:53
> As an aside, runtests.sh should have executable permissions.

Doesn't it already?  On my system (without having ever messed with any permissions as far as I can recall), I have:

newton:py3k dickinsm$ ls -l runtests.sh 
-rwxr-xr-x  1 dickinsm  staff  2168 28 Aug  2009 runtests.sh
newton:py3k dickinsm$ svn pl runtests.sh
Properties on 'runtests.sh':
  svn:executable
  svn:eol-style

And I get the same with a fresh hg checkout from http://code.python.org/hg/branches/py3k
History
Date User Action Args
2010-06-12 16:53:25mark.dickinsonsetmessages: + msg107671
2010-06-12 15:53:43serprexsetfiles: + diff.2

messages: + msg107665
2010-06-11 23:07:11gvanrossumsetmessages: + msg107603
2010-06-11 22:08:35mark.dickinsonsetmessages: + msg107594
2010-06-11 21:48:25gvanrossumsetnosy: + gvanrossum
messages: + msg107586
2010-06-11 20:59:02mark.dickinsonsetstatus: open -> closed
versions: + Python 3.3, - Python 3.1
nosy: + mark.dickinson

messages: + msg107584

resolution: rejected
2010-06-11 20:33:33serprexsettype: enhancement -> behavior
2010-06-11 20:33:04serprexsetmessages: + msg107582
2010-06-11 20:26:39serprexcreate