[ python-Bugs-1314107 ] Issue in unicode args in logging
Bugs item #1314107, was opened at 2005-10-05 18:11 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314107&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: Unicode Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Vinay Sajip (vsajip) Summary: Issue in unicode args in logging Initial Comment: logging has an issue in handling unicode object arguments. >>> import logging >>> >>> class Obj: ... def __init__(self,name): ... self.name = name ... def __str__(self): ... return self.name ... >>> # a non-ascii string ... >>> obj = Obj(u'\u00f6') >>> >>> # this will cause error ... >>> print '%s' % obj Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # this will promote to unicode (and the console also happen to be able to display it) ... >>> print u'%s' % obj ö >>> >>> # this works fine ... # (other than logging makes its own decision to encode in utf8) ... >>> logging.error(u'%s' % obj) ERROR:root:├╢ >>> >>> # THIS IS AN UNEXPECTED PROBLEM!!! ... >>> logging.error(u'%s', obj) Traceback (most recent call last): File "C:\Python24\lib\logging\__init__.py", line 706, in emit msg = self.format(record) File "C:\Python24\lib\logging\__init__.py", line 592, in format return fmt.format(record) File "C:\Python24\lib\logging\__init__.py", line 382, in format record.message = record.getMessage() File "C:\Python24\lib\logging\__init__.py", line 253, in getMessage msg = msg % self.args UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # workaround the str() conversion in getMessage() ... >>> logging.error(u'%s-\u00f6', obj) ERROR:root:├╢-├╢ The issue seems to be in LogRecord.getMessage(). It attempts to convert msg to byte string: msg = str(self.msg) I am not sure why ti want to do the conversion. The last example workaround this by making sure msg is not convertible to byte string. -- >Comment By: Vinay Sajip (vsajip) Date: 2005-10-07 08:43 Message: Logged In: YES user_id=308438 Aaah...now I understand! Sorry for being a little slow, and thanks for explaining in more detail. I've uploaded a fix to CVS: str(msg) is only called if msg is not either a string or a Unicode object. With the fix, the following script: #--- import logging class X: def __init__(self, name): self.name = name def __str__(self): return self.name def main(): obj = X(u'\u00f6') logging.error(u'%s' % obj) logging.error(u'%s', obj) logging.error(u'%s-\u00f6', obj) if __name__ == "__main__": main() #--- Now gives the following output on my system (default encoding is 'ascii'): ERROR:root:├ ERROR:root:├ ERROR:root:├Â-├ -- Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-10-06 23:16 Message: Logged In: YES user_id=561546 >>To ensure good Unicode support, ensure your messages are either Unicode strings or objects whose __str__() method returns a Unicode string. Then, >>msg = msg % args That's what I am doing already. Let me explain the subtle problem again. 1. print '%s' % obj - error 2. logging.error(u'%s' % obj) - ok 3. logging.error(u'%s', obj) - error 4. logging.error(u'%s-\u00f6', obj) -ok I can understand how 1 fails. But I expect 2,3 and 4 to work similarly. Especially contrast 3 with 4. 4 work when 3 doesn't because when str() is applied to u'%s-\u00f6' it fails and it fallbacks to the original unicode string, which is the correct way in my opinion. Whereas in 3, the u'%s' get demoted to byte string '%s' so it fails like 1. -- Comment By: Vinay Sajip (vsajip) Date: 2005-10-06 08:44 Message: Logged In: YES user_id=308438 Misc. changes were backported into Python 2.4.2, please check that you have this version. The problem is not with msg = str(self.msg) but rather with msg = msg % args To ensure good Unicode support, ensure your messages are either Unicode strings or objects whose __str__() method returns a Unicode string. Then, msg = msg % args should result in a Unicode object. You can pass this to a FileHandler opened with an encoding argument, or a StreamHandler whose stream has been opened using codecs.open(). Ensure your default encoding is set correctly using sitecustomize.py. The encoding additions were made in Revision 1.26 of logging/__init__.py, d
[ python-Bugs-1315961 ] inspect.getsourcelines() broken
Bugs item #1315961, was opened at 2005-10-07 18:33 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=1315961&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsourcelines() broken Initial Comment: inspect.getsourcelines() in Python 2.4.2 breaks when parsing the attached buggy.py although the indentation level are OK: >>> import inspect, buggy >>> inspect.getsourcelines(buggy.title) This gives a "IndentationError: unindent does not match any outer indentation level" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1315961&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-28 03:30 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 11:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 08:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 ___
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-28 03:30 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: 9 Submitted By: Brett Cannon (bcannon) >Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 11:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 08:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 ___
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-28 03:30 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 11:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 08:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable
[ python-Bugs-1316069 ] gzip.GzipFile.seek missing second argument
Bugs item #1316069, was opened at 2005-10-07 19:34 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=1316069&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.seek missing second argument Initial Comment: It would nice if GzipFile.seek matched file.seek and BZ2File.seek and took a second argument. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-28 02:18 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Neil Schemenauer (nascheme) Date: 2005-10-07 19:36 Message: Logged In: YES user_id=35752 As you say, this looks like it will be tedious to fix. Maybe we could change the ast node constructors to take lineno as an optional argument (e.g. using va_list). -- Comment By: Brett Cannon (bcannon) Date: 2005-07-28 05:51 Message: Logged In: YES user_id=357491 Rev. 1.1.2.110 of Python/newcompile.c has the fix for test_dis:test_dis. The more thinking I do about it the more I realize that expression nodes in the AST will need to keep a lineno attribute in order to have lnotab to be set properly. That will not be a fun patch to do. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-28 05:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-28 03:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-28 02:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246473 ] line numbers off by 1 in dis
Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. -- >Comment By: Brett Cannon (bcannon) Date: 2005-10-07 13:05 Message: Logged In: YES user_id=357491 Maybe, but what would that buy us? We can make the attribute optional on expression nodes and slowly work it all in, but it will need to be done at some point. We could make this the last major fix and deal with everything else that does not rely on this since it is a rather shallow fix in and of itself. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-07 12:36 Message: Logged In: YES user_id=35752 As you say, this looks like it will be tedious to fix. Maybe we could change the ast node constructors to take lineno as an optional argument (e.g. using va_list). -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:51 Message: Logged In: YES user_id=357491 Rev. 1.1.2.110 of Python/newcompile.c has the fix for test_dis:test_dis. The more thinking I do about it the more I realize that expression nodes in the AST will need to keep a lineno attribute in order to have lnotab to be set properly. That will not be a fun patch to do. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1316162 ] Segmentation fault with invalid "coding"
Bugs item #1316162, was opened at 2005-10-07 17:24
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=1316162&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: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Humberto Diógenes (virtualspirit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault with invalid "coding"
Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-
2. Run it:
python wrong_coding.py
3. Enjoy your segfault... :P
Versions tested:
- Python 2.4.2 (Ubuntu Breezy)
- Python 2.3.5 (Debian Sarge)
Running it directly with "python -c" gives MemoryError. Strace output:
# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(2, "MemoryError", 11MemoryError) = 11
write(2, "\n", 1
) = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER,
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1) = ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1316162 ] Segmentation fault with invalid "coding"
Bugs item #1316162, was opened at 2005-10-07 22:24
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&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: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Humberto Diógenes (virtualspirit)
>Assigned to: Walter Dörwald (doerwalter)
Summary: Segmentation fault with invalid "coding"
Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-
2. Run it:
python wrong_coding.py
3. Enjoy your segfault... :P
Versions tested:
- Python 2.4.2 (Ubuntu Breezy)
- Python 2.3.5 (Debian Sarge)
Running it directly with "python -c" gives MemoryError. Strace output:
# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(2, "MemoryError", 11MemoryError) = 11
write(2, "\n", 1
) = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER,
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1) = ?
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-08 08:24
Message:
Logged In: YES
user_id=1188172
Reproducable here with 2.4.2 and the 2.4 CVS branch. It
seems fixed in HEAD.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
