This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: incorrect LOAD/STORE_GLOBAL generation
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: nascheme Nosy List: nascheme, twouters
Priority: release blocker Keywords:

Created on 2006-06-06 23:57 by twouters, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
augassign_fix.txt nascheme, 2006-06-30 17:51 minimal fix
test_ast_fix.txt nascheme, 2006-06-30 22:03
Messages (6)
msg28729 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2006-06-06 23:57
Python 2.5 compiles the following piece of code
differently than Python 2.4:

g = 1
def f():
    g += 1

In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:

g = 1
def f():
    g += 1
    g = 5

I can't find where this optimization happens nowadays,
but it feels like a short fix.
msg28730 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2006-06-19 17:44
Logged In: YES 
user_id=34209

Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:

>>> def foo(x):
...     def bar():
...         if 0:
...             print x
...     return bar

In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>

In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(<cell at 0x2b9abf6d7e30: int object at 0x6b6580>,)

(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)
msg28731 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2006-06-30 16:22
Logged In: YES 
user_id=35752

Here are some notes in case I wear out before finding a fix.
 analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should.  It does not have DEF_LOCAL
because Name.ctx for 'g' is Load.  I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by  Jeremy.  Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.
msg28732 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2006-06-30 17:51
Logged In: YES 
user_id=35752

I've got a simple fix that seems to work.  I feel this part
of the compiler could use some more serious cleanups but
probably not for 2.5.  Note that test_ast fails after
applying my patch.  I haven't had time to look into that yet
but I think it's shallow.
msg28733 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2006-06-30 22:03
Logged In: YES 
user_id=35752

Adding a patch to "fix" test_ast.py.  I have no idea what
the test is trying to verify.  It looks like it was written
by martin.v.loewis so maybe he can comment.
msg28734 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2006-07-09 16:17
Logged In: YES 
user_id=35752

Checked in as SVN rev 50493.
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43467
2006-06-06 23:57:54twouterscreate