[issue11441] compile() raises SystemError if called from except clause
Brett Cannon added the comment: This no longer seems to be a problem in Python 3.2, 3.3, or 3.4. -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: So, I see four possible solutions: 1. If we get a tuple, create the new tuple, normalize the exception, and store it. If we get a SyntaxError instance, use its args, create the new tuple, normalize, and store. (In this case a SyntaxError instance will be created twice.) 2. If we get a tuple, create the new tuple and store it without normalization. If we get a SyntaxError instance use its args to create the new tuple and store it without normalization. (I think, that later it's still possible that a new SynaxError will be created, but we don't create it here.) 3. If we get a tuple, create the new tuple, and store it without normalization. If we get a SyntaxError, take its args, create the new tuple, and call SyntaxError.__init__ with it. I think this will set all fields properly. 4. Like 3., but if we got a tuple, store the new tuple with normalization. My patch currently does 1. My patch, without the PyErr_NormalizeException() call would be 2. I think maybe 3. would be the best solution, or 4., if normalization is desired in all cases. I can write a new patch, if the experts tell me what is the best solution from the four (or some other I didn't think of). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: I'd choose solution 3, but instead of calling SyntaxError.__init__, call PyErr_NormalizeException(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: Err... sorry, I don't understand again: If we get a tuple, create a new, store it without normalization. That's okay, I understand. If we get a SyntaxError instance, then take its args field, create the new tuple. Then call PyErr_NormalizeException(), with: a) the new tuple? But this will create a new SyntaxError instance... b) the old SyntaxError instance? But this won't correct the wrong fields of the instance. (I think SyntaxError.__init__ would correct them without creating a new instance.) c) or replace the args of the SyntaxError instance with the new tuple, then call PyErr_NormalizeException() on the instance? But I think that still won't correct the other fields of the instance... Sorry for all these questions... I'd just like to help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
July Tikhonov july.t...@gmail.com added the comment: There is an XXX just before the definition of ast_error. Wouldn't it be useful? The idea is to merge ast_error() and ast_error_finish(). This requires redefinition of most functions in ast.c, adding const char *filename to their parameters. -- Added file: http://bugs.python.org/file21061/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___There is an XXX just before the definition of ast_error. Wouldn#39;t it be useful?divbr/divdivThe idea is to merge ast_error() and ast_error_finish().br clear=allThis requires redefinition of most functions in ast.c, adding quot;const char *filenamequot; to their parameters./div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: That's why I thought that calling PyErr_NormalizeException with the new tuple is the simplest thing to do, becuase I guess that'll take care of all fields automatically. You could also call PyErr_NormalizeException at the beginning, and update the fields directly in the PySyntaxErrorObject structure. No need to deal with any tuple. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Changes by July Tikhonov july.t...@gmail.com: Removed file: http://bugs.python.org/file21061/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: You could also call PyErr_NormalizeException at the beginning, and update the fields directly in the PySyntaxErrorObject structure. No need to deal with any tuple. Sorry, but I don't really understand. If I call PyErr_NormalizeException at the beginning, the SyntaxError instance will be initialized with the wrong 3-tuple: (errstr, lineno, offset). If after that I update the msg, filename, ... fields, they will be correct, but I think the args field still will be the wrong 3-tuple. So I'll have to still create the new tuple, and replace the args field, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: hmm, you are right, of course. I forgot that e.args is part of the SyntaxError members. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
New submission from July Tikhonov july.t...@gmail.com:
Normal:
compile('1 = 1', 'string', 'exec')
Traceback (most recent call last):
File stdin, line 1, in module
File string, line 1
SyntaxError: can't assign to literal
SystemError is raised instead of SyntaxError:
try: abcde
... except NameError:
... compile('1 = 1', 'string', 'exec')
...
Traceback (most recent call last):
File stdin, line 1, in module
NameError: name 'abcde' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File stdin, line 3, in module
SystemError: Objects/tupleobject.c:126: bad argument to internal function
Error can be discovered by calling dis.dis('1 = 1').
--
components: Library (Lib)
messages: 130342
nosy: july
priority: normal
severity: normal
status: open
title: compile() raises SystemError if called from except clause
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11441
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: Apparently ast_error_finish calls PyTuple_GetItem with a value that is not a tuple, but a SyntaxError instance (in Python/ast.c line 112). It seems that ast_error_finish expects that PyErr_Fetch will return the exception value as a tuple, and in some cases this seems correct (for example when not in an except clause), but not in this case. I don't know much about Python exception handling in C, but it seems to me, that it shouldn't expect always a tuple (see also http://docs.python.org/dev/py3k/c-api/exceptions.html#PyErr_NormalizeException). -- nosy: +durban versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Right. In most cases, PyErr_SetObject(PyExc_SyntaxError, tuple); will store the untouched tuple in tstate-curexc_value, *except* when Implicit exception chaining occurs, in which case the exception is normalized. ast_error_finish() should not expect a tuple in all cases, and should probably normalize the exception as well. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: Here is a patch. I wasn't sure, where to put the test, so I put it in test_ast. -- keywords: +patch Added file: http://bugs.python.org/file21054/issue11441.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Benjamin Peterson benja...@python.org added the comment: You can put the test in test_compile. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: Okay, here is a new patch with the test in the correct place (I hope). -- Added file: http://bugs.python.org/file21055/issue11441_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Why is the exception normalized at the end? I suppose it's because when value is an exception instance, it's replaced by a tuple, but the original value has to be recreated at the end. So in some cases, the SyntaxError object is created twice... If PyErr_NormalizeException() can't be avoided, I suggest to call it at the start, just after PyErr_Fetch, and use the PySyntaxErrorObject* structure directly to get the file name and line numbers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11441] compile() raises SystemError if called from except clause
Daniel Urban urban.dani...@gmail.com added the comment: Why is the exception normalized at the end? I suppose it's because when value is an exception instance, it's replaced by a tuple, but the original value has to be recreated at the end. So in some cases, the SyntaxError object is created twice... If PyErr_NormalizeException() can't be avoided, I suggest to call it at the start, just after PyErr_Fetch, and use the PySyntaxErrorObject* structure directly to get the file name and line numbers. Yeah, it is because ast_error_finish creates a new tuple to use as the exception value. (It creates a new (errstr, (filename, lineno, offset, loc)) tuple from the original (errstr, lineno, offset) tuple). And yes, in some cases the SyntaxError instance is created twice. I wasn't sure if it's okay to simply replace the args field of a PyBaseExceptionObject. I don't know, if PyErr_NormalizeException() can be avoided, you wrote, that it should probably normalize the exception as well. Would it be better, if we, when got an exception instance, create the new tuple from the info, and replace the args field of the instance with it? (But it also seems to me, that the SyntaxError objects have other fields as well, so probably we should modify them also. That's why I thought that calling PyErr_NormalizeException with the new tuple is the simplest thing to do, becuase I guess that'll take care of all fields automatically.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
