[ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char.
Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&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: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. -- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Michael Hudson (mwh) >Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 14:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 13:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 13:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370322 ] Float marshaling problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 18:05 Message: Logged In: YES user_id=1188172 Yep, after "make distclean" and even a fresh checkout the problem is there. I configured with and without "--with-pydebug". Okay, Michael, you are rehabilitated: I restored floatobject.c to the state before your patch, and it behaves the same. -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 14:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 14:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... -- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort
Bugs item #1010952, was opened at 2004-08-18 04:13 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Hye-Shik Chang (perky) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py = == RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) -- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-11 02:48 Message: Logged In: YES user_id=55188 Fixed in r41637. Thank you! -- Comment By: Hye-Shik Chang (perky) Date: 2005-08-30 16:06 Message: Logged In: YES user_id=55188 I wrote a patch that draws on lemburg's suggestion. Please test it: SF #1276356. -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-10-14 05:04 Message: Logged In: YES user_id=38388 Just a suggestion: Why don't we add a new resource option to the test scripts and then have the tests download the files from the Internet as necessary ?! -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-14 04:59 Message: Logged In: YES user_id=469548 How about adding the files to nondist? -- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-14 00:12 Message: Logged In: YES user_id=29957 Could we at least get a single tarball/zip file of all of the files? At the moment, it takes a serious amount of effort to fetch all the files. -- Comment By: Martin v. Löwis (loewis) Date: 2004-08-20 16:26 Message: Logged In: YES user_id=21627 Adding the files to the CVS is unacceptable, because they would then end up in the distribution, and their size is considered unacceptable for distribution (let alone copyright issues with these files). -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-18 04:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs
Bugs item #1377858, was opened at 2005-12-10 22:20 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=1377858&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: 5 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377897 ] Bus error in ast
Bugs item #1377897, was opened at 2005-12-10 17:26 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=1377897&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: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Bus error in ast Initial Comment: Today I got a bus error trying to install the latest version of setuptools from the sandox after a fresh svn up of both and install of Python from the trunk on my Mac ()SX 10.3.9). Running under gdb it croaked at line 3033 of ast.c. Here's the backtrace: #0 ast_for_stmt (c=0xbfffda40, n=0x53d1b0) at ../Python/ast.c:3033 #1 0x00088060 in ast_for_suite (c=0xbfffda40, n=0x574e30) at ../ Python/ast.c:2561 #2 0x000890cc in ast_for_funcdef (c=0xbfffda40, n=0x3bcf50) at ../ Python/ast.c:896 #3 0x00088014 in ast_for_suite (c=0xbfffda40, n=0x574d18) at ../ Python/ast.c:2551 #4 0x0008b14c in ast_for_classdef (c=0xbfffda40, n=0x3bc9c8) at ../ Python/ast.c:2975 #5 0x00086a5c in PyAST_FromNode (n=0x3c28c0, flags=0x0, filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py") at ../Python/ast.c:297 #6 0xd98c in Py_CompileStringFlags (str=0xbfffda40 "", filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py", start=557152, flags=0xbfffdb5c) at ../Python/pythonrun.c:1275 #7 0x000a4eac in builtin_compile (self=0xbfffda40, args=0x0) at ../ Python/bltinmodule.c:457 #8 0x0007e154 in call_function (pp_stack=0xbfffdc3c, oparg=0) at ../ Python/ceval.c:3565 #9 0x0007bcb4 in PyEval_EvalFrameEx (f=0x842a10, throw=131) at ../Python/ceval.c:2181 #10 0x0007cd68 in PyEval_EvalCodeEx (co=0x842b98, globals=0x0, locals=0xb622c, args=0x842b5c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=3, closure=0x0) at ../Python/ ceval.c:2739 #11 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8661852, na=5245749, nk=213) at ../Python/ceval.c:3658 #12 0x0007e22c in call_function (pp_stack=0xbfffde8c, oparg=0) at ../Python/ceval.c:3586 #13 0x0007bcb4 in PyEval_EvalFrameEx (f=0x850410, throw=131) at ../Python/ceval.c:2181 #14 0x0007cd68 in PyEval_EvalCodeEx (co=0x8505bc, globals=0x0, locals=0xb622c, args=0x85055c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=7, closure=0x0) at ../Python/ ceval.c:2739 #15 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8717660, na=5245749, nk=213) at ../Python/ceval.c:3658 #16 0x0007e22c in call_function (pp_stack=0xbfffe0dc, oparg=0) at ../Python/ceval.c:3586 #17 0x0007bcb4 in PyEval_EvalFrameEx (f=0x837010, throw=131) at ../Python/ceval.c:2181 #18 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x401, n=8614236, na=5245749, nk=213) at ../Python/ceval.c:3647 #19 0x0007e22c in call_function (pp_stack=0xbfffe28c, oparg=0) at ../Python/ceval.c:3586 #20 0x0007bcb4 in PyEval_EvalFrameEx (f=0x859610, throw=131) at ../Python/ceval.c:2181 #21 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8755036, na=5245749, nk=213) at ../Python/ceval.c:3647 #22 0x0007e22c in call_function (pp_stack=0xbfffe43c, oparg=0) at ../Python/ceval.c:3586 #23 0x0007bcb4 in PyEval_EvalFrameEx (f=0x861e10, throw=131) at ../Python/ceval.c:2181 #24 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=8789852, na=5245749, nk=213) at ../Python/ceval.c:3647 #25 0x0007e22c in call_function (pp_stack=0xbfffe5ec, oparg=0) at ../Python/ceval.c:3586 #26 0x0007bcb4 in PyEval_EvalFrameEx (f=0x849810, throw=131) at ../Python/ceval.c:2181 #27 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8690012, na=5245749, nk=213) at ../Python/ceval.c:3647 #28 0x0007e22c in call_function (pp_stack=0xbfffe79c, oparg=0) at ../Python/ceval.c:3586 #29 0x0007bcb4 in PyEval_EvalFrameEx (f=0x860610, throw=131) at ../Python/ceval.c:2181 #30 0x0007cd68 in PyEval_EvalCodeEx (co=0x860778, globals=0x0, locals=0xb622c, args=0x86075c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #31 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8783708, na=5245749, nk=213) at ../Python/ceval.c:3658 #32 0x0007e22c in call_function (pp_stack=0xbfffe9ec, oparg=0) at ../Python/ceval.c:3586 #33 0x0007bcb4 in PyEval_EvalFrameEx (f=0x40dc40, throw=131) at ../Python/ceval.c:2181 #34 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x101, n=4251020, na=5245749, nk=213) at ../Python/ceval.c:3647 #35 0x0007e22c in call_function (pp_stack=0xbfffeb9c, oparg=0) at ../Python/ceval.c:3586 #36 0x0007bcb4 in PyEval_EvalFrameEx (f=0x42a500, throw=131) at ../Python/ceval.c:2181 #37 0x0007e3a8 in fast_func
[ 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 bcannon 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: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? -- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed --- assert 1, ([s for s in x] + [s for s in x]) pass --- -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21: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 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(): .
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 11:08 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) Date: 2005-12-11 00:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. -- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 23:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? -- Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed --- assert 1, ([s for s in x] + [s for s in x]) pass --- -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 20:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 05: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 08: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 13: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 13: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
[ python-Bugs-1378022 ] source utf8
Bugs item #1378022, was opened at 2005-12-11 06:48 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=1378022&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: None Status: Open Resolution: None Priority: 5 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
