Bugs item #1557232, was opened at 2006-09-12 15:28
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parser crash
Initial Comment:
The code
def x(((y))):pass
crashes the compiler (?) in 2.5c2, on Windows.
----------------------------------------------------------------------
>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-25 07:05
Message:
Logged In: YES
user_id=849994
Backported in rev. 51999.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-22 08:21
Message:
Logged In: YES
user_id=33168
Committed revision 51972. (2.6)
Still needs backport.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-18 05:55
Message:
Logged In: YES
user_id=33168
Attaching a new patch with tests. There probably should be
more tests, but this is all I can think of at this point. I
think I've covered the cases of the recursive definition
properly now.
Conceptually this is a very small patch. I've added a bunch
of asserts and broken some complex lines up though.
The first chunk deals with complex_args and elides
superfluous parens around (x). The second chunk does the
same eliding but for non-complex args. Any number of extra
parens should be elided properly now.
I will apply to head and 2.5.1 later.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-13 07:44
Message:
Logged In: YES
user_id=33168
I think patch v2 might fix both problems. I'm not sure it's
correct. We really need a lot of tests for this stuff.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-13 06:22
Message:
Logged In: YES
user_id=33168
The attached patch seems to fix the ((((x)))) problem. I
didn't run in debug mode, so I'm not positive the assert
works as I expect.
However now my test case below doesn't work, it puts in 5
UNPACK_SEQUENCES rather than 3. This looks like a different
problem in compiler_complex_args().
Not sure how much farther I'll get tonight.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-13 06:00
Message:
Logged In: YES
user_id=33168
I guess what 2.4 does is the most reasonable behavior:
>>> def f((((((x)),),),)): pass
>>> dis.dis(f)
1 0 LOAD_FAST 0 (.0)
3 UNPACK_SEQUENCE 1
6 UNPACK_SEQUENCE 1
9 UNPACK_SEQUENCE 1
12 STORE_FAST 1 (x)
15 LOAD_CONST 0 (None)
18 RETURN_VALUE
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-13 05:50
Message:
Logged In: YES
user_id=33168
The problem is in Python/ast.c around line 666. See the
comment:
/* def foo((x)): setup for checking NAME below. */
The code is not sufficient, we need a loop and need to
handle various combinations of:
def f(((((x))),)),))): pass
I don't know if the parens above match, but the general idea
is that there could be a bunch of parens and commas at
various places. I'm not sure how the above should be
interpreted.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
