[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Jeremy Hylton (jhylton) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: def f(): class g: exec "hi" x def f(x): class g: exec "hi" x def f(): class g: from a import * x def f(x): class g: from a import * x -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Neil Schemenauer (nascheme) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: def f(): class g: exec "hi" x def f(x): class g: exec "hi" x def f(): class g: from a import * x def f(x): class g: from a import * x -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: def f(): class g: exec "hi" x def f(x): class g: exec "hi" x def f(): class g: from a import * x def f(x): class g: from a import * x -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1335054 ] Python 2.4.2 doesn't build with "--without-threads"
Bugs item #1335054, was opened at 2005-10-22 21:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1335054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1335054&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167751 ] Argument genexp corner case
Bugs item #1167751, was opened at 2005-03-21 09:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: John Ehresman (jpe)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Argument genexp corner case
Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError. It
seems that the grammar parses it, but the compiler does
not do the right thing.
>>> def foo(a): pass
>>> foo(a = i for i in range(10))
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'i' is not defined
foo(a = (i for i in range(10)) works.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-22 17:44
Message:
Logged In: YES
user_id=33168
Ok. Backported.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-10-21 00:55
Message:
Logged In: YES
user_id=29957
I can't see a problem with backporting this to 2.4
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-20 23:27
Message:
Logged In: YES
user_id=33168
Checked in as:
* Python/graminit.c 2.41
* Lib/test/test_genexps.py 1.10
* Grammar/Grammar 1.55
* Misc/NEWS 1.1392 and 1.1391
Leaving it up to Anthony whether this should be backported.
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-10-11 06:43
Message:
Logged In: YES
user_id=1038590
The problem is definitely on the parser end though:
Py> compiler.parse("foo(x=i for i in range(10))")
Module(None, Stmt([Discard(CallFunc(Name('foo'),
[Keyword('x', Name('i'))], None, None))]))
It's getting to what looks like a valid keyword argument in
"x=i" and throwing the rest of it away, when it should be
flagging a syntax error (the parser's limited lookahead
should be enough to spot the erroneous 'for' keyword and
bail out).
The problem's actually worse than the OP noted: consider
what will happen if there is a variable "i" visible from the
location of the function call (e.g. from a list
comprehension or for loop in a nested scope). Good luck
tracking that one down. . .
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 21:10
Message:
Logged In: YES
user_id=33168
I definitely agree this is a big problem.
Here's what the code above generates:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_GLOBAL 1 (i)
9 CALL_FUNCTION 256
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
If I put parens around the genexp, I get:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 ( at 0x2a960baae8, file "", line 2>)
9 MAKE_FUNCTION0
12 LOAD_GLOBAL 1 (range)
15 LOAD_CONST 3 (10)
18 CALL_FUNCTION1
21 GET_ITER
22 CALL_FUNCTION1
25 CALL_FUNCTION 256
28 POP_TOP
29 LOAD_CONST 0 (None)
32 RETURN_VALUE
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 05:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 23:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 02:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 07:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: def f(): class g: exec "hi" x def f(x): class g: exec "hi" x def f(): class g: from a import * x def f(x): class g: from a import * x -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 07:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 07:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 07:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 06:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. -- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:13 Message: Logged I
