[ python-Bugs-1590744 ] mail message parsing glitch
Bugs item #1590744, was opened at 2006-11-05 04:21 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=1590744&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike (mcspang) Assigned to: Nobody/Anonymous (nobody) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <[EMAIL PROTECTED]>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590036 ] __getattr__ = getattr crash
Bugs item #1590036, was opened at 2006-11-03 16:44 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&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: Closed >Resolution: Duplicate Priority: 6 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Armin Rigo (arigo) Summary: __getattr__ = getattr crash Initial Comment: class c(object):__getattr__ = getattr c().spam Now granted... it's retarded to attempt this. But out of curiousity, I decided to be the retard, and noticed the interpreter crashes instead of triggering a RuntimeError for recursion. As far as I know, getattr is instrumented with Py_EnterRecursiveCall and Py_LEaveRecursiveCall... so a bit curious as to how it's occuring. -- >Comment By: Armin Rigo (arigo) Date: 2006-11-05 09:30 Message: Logged In: YES user_id=4771 This is a particular case of bug #1202533. With Brett we arrived at a patch in #1202533 which should solve a family of similar problems. Can you check that it also solves the __getattr__=getattr attack? If so, we should check in Brett's patch. -- Comment By: Brian Harring (ferringb) Date: 2006-11-05 03:57 Message: Logged In: YES user_id=874085 can do the same trick with hasattr also (same type of fix)... -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 19:40 Message: Logged In: YES user_id=33168 The attached patch fixes this problem. However, I'm concerned there are more places like this. I hope Armin has some ideas if more things are needed to fix this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion
Bugs item #1590804, was opened at 2006-11-05 08:13 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=1590804&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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [EMAIL PROTECTED] numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590864 ] subprocess deadlock
Bugs item #1590864, was opened at 2006-11-05 11:06 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=1590864&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Tsai (michaeltsai) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess deadlock Initial Comment: When I use subprocess.py from a child thread, sometimes it deadlocks. I determined that the new process is blocked during an import: #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90028414 in pthread_cond_wait () #2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1) at Python/thread_pthread.h:452 #3 0x004ae2a6 in lock_import () at Python/import.c:266 #4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno", globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at Python/import.c:2054 #5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90, kwds=0x0) at Python/bltinmodule.c:47 #6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90, kw=0x0) at Objects/abstract.c:1860 and that the code in question is in os.py: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR I think the problem is that since exec (the C function) hasn't yet been called in the new process, it's inherited from the fork a lock that's already held. The main process will eventually release its copy of the lock, but this will not unlock it in the new process, so it deadlocks. If I change os.py so that it imports the constants outside of _execvpe, the new process no longer blocks in this way. This is on Mac OS X 10.4.8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590891 ] random.randrange don't return correct value for big number
Bugs item #1590891, was opened at 2006-11-06 01:54 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=1590891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: MATSUI Tetsushi (mft) Assigned to: Nobody/Anonymous (nobody) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1, -1, -200) 267471051174796896L Obviously, the result is not in the specified range; 1 < 267471051174796896, -1 < 267471051174796896 and (267471051174796896 - 1) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590891 ] random.randrange don't return correct value for big number
Bugs item #1590891, was opened at 2006-11-05 11:54 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: MATSUI Tetsushi (mft) >Assigned to: Raymond Hettinger (rhettinger) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1, -1, -200) 267471051174796896L Obviously, the result is not in the specified range; 1 < 267471051174796896, -1 < 267471051174796896 and (267471051174796896 - 1) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1589074 ] Unneeded constants left during optimization
Feature Requests item #1589074, was opened at 2006-11-02 00:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 15:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 10:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? -- Comment By: Daniel (kamek) Date: 2006-11-02 00:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1589074 ] Unneeded constants left during optimization
Feature Requests item #1589074, was opened at 2006-11-02 01:55 Message generated for change (Comment added) made by kamek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. -- >Comment By: Daniel (kamek) Date: 2006-11-05 17:12 Message: Logged In: YES user_id=539453 loewis: Sorry, I'm afraid I don't have enough knowledge on Python's internals to work on it. rhettinger: Well, that's bad, but I did expect that; I agree the actual benefits would be minimal, especially considering how relatively rare this optimization occurs and how those constants are often quite light on memory usage. But what about intermediate constants (which we are sure that aren't used elsewhere, like in 3 + 4 + 10)? Would it be easier to get rid of them (or maybe reuse previously defined constants when available)? All in all, sorry for being too nitpicky. I know this isn't any crucial issue :) -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 16:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 11:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? -- Comment By: Daniel (kamek) Date: 2006-11-02 01:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1589074 ] Unneeded constants left during optimization
Feature Requests item #1589074, was opened at 2006-11-02 06:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-05 23:07 Message: Logged In: YES user_id=21627 kamek: with the current peephole pass, it wouldn't be easy to eliminate intermediate constants. The peephole operates on individual instructions, introducing a new constant each time. That code would have to track what constants were originally there and which ones are new, and then would also have to take into account that the constant numbering must not change (so you can always only eliminate the last constant, unless you add an entire new pass that renumbers all opcodes that refer to constants). Closing this as "won't fix", then, as nobody seems to be willing to work on it. If this is ever attempted, I think the constant folding should happen on the AST level, rather than on the bytecode level. -- Comment By: Daniel (kamek) Date: 2006-11-05 22:12 Message: Logged In: YES user_id=539453 loewis: Sorry, I'm afraid I don't have enough knowledge on Python's internals to work on it. rhettinger: Well, that's bad, but I did expect that; I agree the actual benefits would be minimal, especially considering how relatively rare this optimization occurs and how those constants are often quite light on memory usage. But what about intermediate constants (which we are sure that aren't used elsewhere, like in 3 + 4 + 10)? Would it be easier to get rid of them (or maybe reuse previously defined constants when available)? All in all, sorry for being too nitpicky. I know this isn't any crucial issue :) -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 21:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 16:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? -- Comment By: Daniel (kamek) Date: 2006-11-02 06:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion
Bugs item #1590804, was opened at 2006-11-05 14:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [EMAIL PROTECTED] numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-05 23:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591035 ] update urlparse to RFC 3986
Bugs item #1591035, was opened at 2006-11-05 15:27 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=1591035&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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: update urlparse to RFC 3986 Initial Comment: urlparse implements RFC 1808. That is strongly out of date. The most recent is RFC 3986. Here is a text from 4Suite # Reasons to avoid using urllib.basejoin() and urlparse.urljoin(): # - Both are partial implementations of long-obsolete specs. # - Both accept relative URLs as the base, which no spec allows. # - urllib.basejoin() mishandles the '' and '..' references. # - If the base URL uses a non-hierarchical or relative path, #or if the URL scheme is unrecognized, the result is not #always as expected (partly due to issues in RFC 1808). # - If the authority component of a 'file' URI is empty, #the authority component is removed altogether. If it was #not present, an empty authority component is in the result. # - '.' and '..' segments are not always collapsed as well as they #should be (partly due to issues in RFC 1808). # - Effective Python 2.4, urllib.basejoin() *is* urlparse.urljoin(), #but urlparse.urljoin() is still based on RFC 1808. See also the back python-dev discussions on "urlparse" for examples of people wanting a better/more up-to-date urlparse/urljoin. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion
Bugs item #1590804, was opened at 2006-11-05 13:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [EMAIL PROTECTED] numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:01 Message: Logged In: YES user_id=849994 Wasn't that already fixed with #1588287? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-05 22:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion
Bugs item #1590804, was opened at 2006-11-05 14:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&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: AST >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [EMAIL PROTECTED] numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 00:11 Message: Logged In: YES user_id=21627 Indeed; I hadn't updated my tree. Closing as fixed. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 00:01 Message: Logged In: YES user_id=849994 Wasn't that already fixed with #1588287? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-05 23:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590592 ] where is zlib???
Bugs item #1590592, was opened at 2006-11-04 20:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&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: Windows Group: Python 2.5 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: AKap (aleksey_kap) Assigned to: Nobody/Anonymous (nobody) Summary: where is zlib??? Initial Comment: Python2.5 for win32 msi-installer - where are zlib.dll and zlib.pyd ??? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 00:12 Message: Logged In: YES user_id=21627 They aren't part of the distribution. Why do you think they should be? zlib is linked into python25.dll. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. -- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() a
[ python-Bugs-1591122 ] problem building python in vs8express
Bugs item #1591122, was opened at 2006-11-05 20:31 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=1591122&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591122 ] problem building python in vs8express
Bugs item #1591122, was opened at 2006-11-06 04:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is [EMAIL PROTECTED] -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1187437 ] TypeError message on bad iteration is misleading
Bugs item #1187437, was opened at 2005-04-21 14:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&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: None >Status: Closed >Resolution: Out of Date Priority: 2 Private: No Submitted By: Roy Smith (roysmith) >Assigned to: Georg Brandl (gbrandl) Summary: TypeError message on bad iteration is misleading Initial Comment: >>> for i in 5: ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I know this is kind of a trivial point, but the message "iteration of non-sequence" should really be something like "iteration of non-iterable object", since not all iterable things are sequences. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:48 Message: Logged In: YES user_id=849994 The message is " object is not iterable" in Python 2.5. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-05 10:46 Message: Logged In: YES user_id=1188172 Seems reasonable to me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379416 ] email.Header encode() unicode P2.3xP2.4
Bugs item #1379416, was opened at 2005-12-13 11:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&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
Private: No
Submitted By: Jan Novak (xnovakj)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Header encode() unicode P2.3xP2.4
Initial Comment:
Python: 2.4
Module: email.Header
Method: encode()
In some cases returns unicode (example on line 5)
1>> from email.Header import Header
2>> Header(unicode('abcá','iso-8859-2'),'utf-8').encode()
'=?utf-8?b?YWJjw6E=?='
3>> Header('abc','utf-8').encode()
'=?utf-8?q?abc?='
4>> Header(u'abc','utf-8').encode()
'abc' ???
5>> Header('abc','iso-8859-2').encode()
u'=?iso-8859-2?q?abc?=' (P2.4)
6>> Header('abc','iso-8859-2').encode()
'=?iso-8859-2?q?abc?=' (P2.3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582282 ] email.header decode within word
Bugs item #1582282, was opened at 2006-10-22 13:16
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.header decode within word
Initial Comment:
The problem is filed in mailman bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103
While Microsoft Entourage's way of encoding iso-8859-1
text is not compliant with RFC-2047, Python
email.header.decode_header should treat this 'word' as
a simple us-ascii string and should not parse into
series of string/charset list.
Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord
should be parsed as
[('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord',
None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'),
('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1372770 ] email.Header should preserve original FWS
Bugs item #1372770, was opened at 2005-12-04 10:53 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372770&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 Private: No Submitted By: Nathan Herring (nherring) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header should preserve original FWS Initial Comment: The Header class describes its operation as using the continuation_ws parameter, prepending the value to continuation lines. This has the byproduct of possibly converting pre-existing FWS in a header, as evidenced by mailman 2.1.6 which exposes the problem. If the Header class is passed pre-existing Header lines, which in the mailman case is from the original message, and, without any manipulation, ask it for the encoded version, it replaces the original folding with the continuation_ws characters. Given that RFC 2822 unfolding consists only of removing CRLFs, exchanging out the FWS characters changes the logical content of a header value. Standard folding of us-ascii text should only consist of introducing line breaks in front of original FWS in the header line. In the case where the encoding of the source string requires multiple adjacent RFC 2047 encoded-words (either due to disparate encodings or text length), then FWS can be freely inserted and is treated as an artifact of the encoding. It is ignored on reading and as such it doesn't affect the logical content of the header value. It's in this latter case that the continuation_ws parameter should be used. e.g., #!/usr/bin/python -d from email.Header import Header s = "Thread-Topic: Use of tabs when folding header lines -- increasing subject\n length as a test\n" print Header(s, 'us-ascii', None, None, '\t') This script will have replaced the space in front of the word "length" with a tab. It should retain that space and not convert it to the continuation_ws character. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372770&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-924806 ] email.Header.Header() produces wrong headers with utf8 enc.
Bugs item #924806, was opened at 2004-03-28 09:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header.Header() produces wrong headers with utf8 enc. Initial Comment: If you pass 'utf8' as encoding to the Header() (e.g. for the subject) then most mailer can not decode the subject because they expect 'utf-8' and not 'utf8'. Maybe there should be a check for this encoding in the code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1590744 ] mail message parsing glitch
Bugs item #1590744, was opened at 2006-11-05 09:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike (mcspang) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <[EMAIL PROTECTED]>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
