[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 10:12 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=1721161&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: Open Resolution: None Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 19:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&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 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 06:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. -- Comment By: ‹‹PC›› (zpcz) Date: 2007-05-17 15:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 23:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 08:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&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: None Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721241 ] code that writes the PKG-INFO file doesnt handle unicode
Bugs item #1721241, was opened at 2007-05-18 13:10 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=1721241&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: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: code that writes the PKG-INFO file doesnt handle unicode Initial Comment: [forwarded from http://bugs.debian.org/422604 ] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03007.html Analysis from Phillip J. Eby: That's not the problem, it's that the code that writes the PKG-INFO file doesn't handle Unicode. See distutils.dist.DistributionMetadata.write_pkg_info(). It needs to use a file with encoding support, if it's doing unicode However, there's currently no standard, as far as I know, for what encoding the PKG-INFO file should use. Meanwhile, the 'register' command accepts Unicode, but is broken in handling it. Essentially, the problem is that Python 2.5 broke this by adding a unicode *requirement* to the "register" command. Previously, register simply sent whatever you gave it, and the PKG-INFO writing code still does. Unfortunately, this means that there is no longer any one value that you can use for your name that will be accepted by both "register" and anything that writes a PKG-INFO file. Both register and write_pkg_info() are arguably broken here, and should be able to work with either strings or unicode, and degrade gracefully in the event of non-ASCII characters in a string. (Because even though "register" is only run by the package's author, users may run other commands that require a PKG-INFO, so a package prepared using Python <2.5 must still be usable with Python 2.5 distutils, and Python <2.5 allows 8-bit maintainer names.) Unfortunately, this isn't fixable until there's a new 2.5.x release. For previous Python versions, both register and write_pkg_info() accepted 8-bit strings and passed them on as-is, so the only workaround for this issue at the moment is to revert to Python 2.4 or less. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 10:12 Message generated for change (Comment added) made by dariounipd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&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: Open Resolution: None Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- >Comment By: darioUniPD (dariounipd) Date: 2007-05-18 14:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 11:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 08:42 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=1721309&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Bugs item #1721313, was opened at 2007-05-18 08:46 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=1721313&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb3 malloc corruption Initial Comment: export MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** Followed by many deadlock exceptions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Bugs item #1721313, was opened at 2007-05-18 08:46 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb3 malloc corruption Initial Comment: export MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** Followed by many deadlock exceptions. -- >Comment By: David Favor (dfavor) Date: 2007-05-18 08:47 Message: Logged In: YES user_id=370230 Originator: YES Duplicate of 1721309. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721368 ] emphasize iteration volatility for dict
Bugs item #1721368, was opened at 2007-05-18 10: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=1721368&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for dict Initial Comment: In footnote (3) at http://docs.python.org/lib/typesmapping.html>, delete the first two sentences and substitute: Keys and values are listed in an arbitrary order. This order is indeterminate and generally depends on factors outside the scope of the containing program. However, if items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 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=1721372&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721313 ] test_bsddb3 malloc corruption
Bugs item #1721313, was opened at 2007-05-18 13:46 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb3 malloc corruption Initial Comment: export MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** Followed by many deadlock exceptions. -- Comment By: David Favor (dfavor) Date: 2007-05-18 13:47 Message: Logged In: YES user_id=370230 Originator: YES Duplicate of 1721309. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721313&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 19:05 Message: Logged In: YES user_id=21627 Originator: NO What factors outside the containing program influence iteration order? Iteration is completely deterministic, and only depends on the items inserted, and the order in which they were inserted, neither of which is outside the scope of the containing program. It's just that the order is not easily predictable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 15:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 19:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Alan (aisaac0) Date: 2007-05-18 13:00 Message: Logged In: YES user_id=1025672 Originator: YES Location in memory. See Peter Otten's discussion at http://www.thescripts.com/forum/post2552380-16.html -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 12:05 Message: Logged In: YES user_id=21627 Originator: NO What factors outside the containing program influence iteration order? Iteration is completely deterministic, and only depends on the items inserted, and the order in which they were inserted, neither of which is outside the scope of the containing program. It's just that the order is not easily predictable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721518 ] Small case which hangs
Bugs item #1721518, was opened at 2007-05-18 20:12 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=1721518&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Julian Todd (goatchurch) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Small case which hangs Initial Comment: import re s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R" r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$" print "It's going to crash" print re.search(r, s) print "It hasn't crashed" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721518 ] Small case which hangs
Bugs item #1721518, was opened at 2007-05-18 20:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None >Priority: 4 Private: No Submitted By: Julian Todd (goatchurch) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Small case which hangs Initial Comment: import re s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R" r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$" print "It's going to crash" print re.search(r, s) print "It hasn't crashed" -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 20:55 Message: Logged In: YES user_id=849994 Originator: NO I assume this is one of the pathological cases where the RE algorithm backtracks "to death". That's not really a bug, but a limitation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 13:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 21:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 17:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 08:42 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: David Favor (dfavor) Date: 2007-05-18 16:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 16:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 12:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721518 ] Small case which hangs
Bugs item #1721518, was opened at 2007-05-18 20:12 Message generated for change (Comment added) made by goatchurch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 4 Private: No Submitted By: Julian Todd (goatchurch) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Small case which hangs Initial Comment: import re s = "Add.1, 2020 and Add.1, 2021-2023, 2025, 2028 and 2029 and Add.1) R" r = "(?:\s|,|and|Add\S*?|Parts?|\([^\)]*\)|[IV\-\d]+)*$" print "It's going to crash" print re.search(r, s) print "It hasn't crashed" -- >Comment By: Julian Todd (goatchurch) Date: 2007-05-18 22:37 Message: Logged In: YES user_id=301384 Originator: YES I can shorten it further to: s = "Add.1, 2020 Add.1, 20212023, 2025, 2028 and 2029 Add.1) R" r = "(?:\s|,|and|Add\S*?|[\d]+)*$" Sometimes it finishes after a long time when you shorten the s-string from the front. If you take the "R" from the end it goes through straight away. It's even very slow with match. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 20:55 Message: Logged In: YES user_id=849994 Originator: NO I assume this is one of the pathological cases where the RE algorithm backtracks "to death". That's not really a bug, but a limitation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721518&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721368 ] emphasize iteration volatility for dict
Bugs item #1721368, was opened at 2007-05-18 10:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&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: Documentation Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for dict Initial Comment: In footnote (3) at http://docs.python.org/lib/typesmapping.html>, delete the first two sentences and substitute: Keys and values are listed in an arbitrary order. This order is indeterminate and generally depends on factors outside the scope of the containing program. However, if items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are called with no intervening modifications to the dictionary, the lists will directly correspond. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:07 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the suggested text is simply incorrect. Given deterministic assignment of hash values and a consistent insertion order, the order of keys in a set or dictionary is fully determined. I've read the source of this suggestion on comp.lang.python and commented there. The underlying issue had nothing to do with either sets or dicts. The code in question "re-discovered" that the location of objects in memory would vary between runs if the user deleted a pyc file for a module. The OP's script used object ids as hash values, hence the set/dict ordering could vary between runs. This was at odds with his expectation that that the ordering would be deterministic. The moral is that non-deterministic hash values lead to non-deterministic set/dict ordering. The docs for sets and dicts should not be muddled with tangential discussions about implementation specific details regarding what governs where objects are placed in memory. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721368&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&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: Documentation Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:08 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the suggested text is simply incorrect. Given deterministic assignment of hash values and a consistent insertion order, the order of keys in a set or dictionary is fully determined. I've read the source of this suggestion on comp.lang.python and commented there. The underlying issue had nothing to do with either sets or dicts. The code in question "re-discovered" that the location of objects in memory would vary between runs if the user deleted a pyc file for a module. The OP's script used object ids as hash values, hence the set/dict ordering could vary between runs. This was at odds with his expectation that that the ordering would be deterministic. The moral is that non-deterministic hash values lead to non-deterministic set/dict ordering. The docs for sets and dicts should not be muddled with tangential discussions about implementation specific details regarding what governs where objects are placed in memory. -- Comment By: Alan (aisaac0) Date: 2007-05-18 13:00 Message: Logged In: YES user_id=1025672 Originator: YES Location in memory. See Peter Otten's discussion at http://www.thescripts.com/forum/post2552380-16.html -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 12:05 Message: Logged In: YES user_id=21627 Originator: NO What factors outside the containing program influence iteration order? Iteration is completely deterministic, and only depends on the items inserted, and the order in which they were inserted, neither of which is outside the scope of the containing program. It's just that the order is not easily predictable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 14:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&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 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:14 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP or on Gentoo Linux. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 04:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 01:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. -- Comment By: ‹‹PC›› (zpcz) Date: 2007-05-17 10:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 18:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1718942 ] glibc error: corrupted double linked list (CPython 2.5.1)
Bugs item #1718942, was opened at 2007-05-14 16:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1718942&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: 5 Private: No Submitted By: Yang Zhang (yangzhang) Assigned to: Nobody/Anonymous (nobody) Summary: glibc error: corrupted double linked list (CPython 2.5.1) Initial Comment: I'm sometimes (50% of the time) getting the following CPython 2.5.1 crash when my program terminates. I would include the source to my program, but it has lots of dependencies, and it would be a substantial task to find a minimal case. *** glibc detected *** python: corrupted double-linked list: 0x0a2018a0 *** === Backtrace: = /lib/libc.so.6[0xd14e9f] /lib/libc.so.6[0xd167ae] /lib/libc.so.6(__libc_free+0x78)[0xd19f6f] /usr/local/lib/libpython2.5.so.1.0(PyObject_Free+0x53)[0x211933] /usr/local/lib/libpython2.5.so.1.0(PyObject_GC_Del+0x53)[0x288fc3] /usr/local/lib/libpython2.5.so.1.0(PyFrame_Fini+0x31)[0x1f8f81] /usr/local/lib/libpython2.5.so.1.0(Py_Finalize+0x105)[0x27d825] /usr/local/lib/libpython2.5.so.1.0(Py_Exit+0x17)[0x27d927] /usr/local/lib/libpython2.5.so.1.0[0x27da4f] /usr/local/lib/libpython2.5.so.1.0(PyErr_PrintEx+0x1aa)[0x27dc6a] /usr/local/lib/libpython2.5.so.1.0(PyErr_Print+0x1e)[0x27de6e] /usr/local/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0xf1)[0x27f0d1] /usr/local/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x27f46a] /usr/local/lib/libpython2.5.so.1.0(Py_Main+0xae8)[0x288a78] python(main+0x32)[0x8048592] /lib/libc.so.6(__libc_start_main+0xdc)[0xcc84e4] python[0x80484d1] === Memory map: 0011-0012 r-xp 08:02 489896 /lib/libpthread-2.4.so 0012-00121000 r--p f000 08:02 489896 /lib/libpthread-2.4.so 00121000-00122000 rw-p 0001 08:02 489896 /lib/libpthread-2.4.so 00122000-00124000 rw-p 00122000 00:00 0 00124000-00147000 r-xp 08:02 489888 /lib/libm-2.4.so 00147000-00148000 r--p 00022000 08:02 489888 /lib/libm-2.4.so 00148000-00149000 rw-p 00023000 08:02 489888 /lib/libm-2.4.so 00149000-00159000 r-xp 08:02 2154663 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so 00159000-0015a000 rw-p 0001 08:02 2154663 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cPickle.so 0015a000-0015d000 r-xp 08:02 2154640 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so 0015d000-0015e000 rw-p 3000 08:02 2154640 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/cStringIO.so 0015e000-00161000 r-xp 08:02 2154619 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so 00161000-00163000 rw-p 2000 08:02 2154619 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/time.so 00163000-00167000 r-xp 08:02 2154653 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so 00167000-00168000 rw-p 4000 08:02 2154653 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/collections.so 00168000-001a9000 r-xp 08:02 490243 /lib/libssl.so.0.9.8a 001a9000-001ad000 rw-p 0004 08:02 490243 /lib/libssl.so.0.9.8a 001ad000-001af000 r-xp 08:02 2154635 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so 001af000-001b rw-p 2000 08:02 2154635 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/fcntl.so 001b-001b2000 r-xp 08:02 2154613 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so 001b2000-001b3000 rw-p 1000 08:02 2154613 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/grp.so 001b3000-001b4000 r-xp 08:02 2154641 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so 001b4000-001b5000 rw-p 1000 08:02 2154641 /toast/pkg/python/v2.5.1/1/root/lib/python2.5/lib-dynload/_bisect.so 001b5000-002bd000 r-xp 08:02 2139893 /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0 002bd000-002e3000 rw-p 00107000 08:02 2139893 /toast/pkg/python/v2.5.1/1/root/lib/libpython2.5.so.1.0 002e3000-002e9000 rw-p 002e3000 00:00 0 002e9000-002f8000 r-xp 08:02 489892 /lib/libresolv-2.4.so 002f8000-002f9000 r--p e000 08:02 489892 /lib/libresolv-2.4.so 002f9000-002fa000 rw-p f000 08:02 489892 /lib/libresolv-2.4.so 002fa000-002fc000 rw-p 002fa000 00:00 0 002fc000-0030e000 r-xp 08:02 1290756/usr/lib/libz.so.1.2.3 0030e000-0030f000 rw-p 00011000 08:02 1290756/usr/lib/libz.so.1.2.3 0030f000-0032f000 r-xp 08:02 565445 /usr/lib/libpq.so.4.1 0032f000-0033 rw-p 0001f000 08:02 565445 /usr/lib/libpq.so.4.1 0033-0033f000 r-xp 000
[ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Bugs item #1487481, was opened at 2006-05-12 08:32 Message generated for change (Comment added) made by atyutyunnik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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 Private: No Submitted By: G�ran Uddeborg (goeran) Assigned to: Guido van Rossum (gvanrossum) Summary: Could BIND_FIRST be removed on HP-UX? Initial Comment: I'm trying to build Python 2.4.3 on HP-UX 11. I need tkinter, so I have first built Tcl and Tk 8.4.13. During the build, the python interpreter crashes. When running the setup.py script, just after making the _tkinter.sl module, it crashes with a memory fault. I've tried to investigate this, and it seems that malloc and friends gets confused by the dynamic loading. I've filed a support request with HP about this. One observation I made is that this malloc bug seems to be connected with the use of BIND_FIRST in dynload_hpux.c. If I just remove this flag (in two places) it appears as if Python works normally. I'm hesitant if this is a good idea. BIND_FIRST is there as an explicit, non-default, flag. Somebody must have choosen to do so for some reason. What was that reason? And is it still valid? If not, maybe the flag could be removed, and this problem in HP-UX be avoided? -- Comment By: Alexander Tyutyunnik (atyutyunnik) Date: 2007-05-18 16:41 Message: Logged In: YES user_id=1558596 Originator: NO I am using on SWIG 1.3.29+ with Python 2.5 on HP-UX 11.23, Itanium 64bit. It had failed to work (unresolved symbols) until I fixed code this way: // flags = BIND_FIRST | BIND_DEFERRED; flags = BIND_DEFERRED|BIND_VERBOSE; instead of: flags = BIND_FIRST | BIND_DEFERRED; Can anyone please fix it? -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-05-18 22:45 Message: Logged In: YES user_id=6380 Peter Kropf wrote: """ BIND_FIRST causes the dynamic loader to place the newly loaded shared library symbol table at the head of the lookup order. This causes symbol lookups from that time forward to check the newly loaded symbol table before everything else. I can see this causing interesting things to happen to a program if a shared library contains symbol names that are the same as those of, let's say, the C runtime library. >From what I remember of Python and HP-UX, I'd guess that this was added for an extension module. I don't think that it would be from the standard Python libraries but rather for a user's custom extension. """ -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-05-18 15:51 Message: Logged In: YES user_id=6380 Sorry, I don't have access to email that old any more. HP-UX is quite different now than it was then. It would make more sense to ask an HP-UX expert. I'll ask Peter Kropf, who helped Elemental with the HP-UX port. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-13 09:38 Message: Logged In: YES user_id=21627 BIND_FIRST was added with this commit: r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996) | 2 lines Geänderte Pfade: M /python/trunk/Python/importdl.c Some extra flags that an HPUX user wants me to add. Guido, do you have any records on which user that was and why he wanted these flags to be added? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1712236 ] __getslice__ changes integer arguments
Bugs item #1712236, was opened at 2007-05-03 13:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712236&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: Wont Fix Priority: 5 Private: No Submitted By: Imri Goldberg (lorgandon) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ changes integer arguments Initial Comment: When using slicing for a sequence object, with a user defined __getslice__ function, the arguments to __getslice__ are changed. This does not happen when __getslice__is called directly. Attached is some code that demonstrates the problem. I checked it on various versions, including my "Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)", on my Ubuntu machine. Although __getslice__ is deprecated, there is still usage of the function, and a fix would be useful. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:51 Message: Logged In: YES user_id=80475 Originator: NO Unfortunately, this is a feature, not a bug. The relevant code is in Python/ceval.c apply_slice(). Calls to s[a:b] get pre-processed before being handed-off to s.__getslice__. This behavior has been around so long, that it is almost certain that there is a good body of existing code that relies on the behavior. -- Comment By: Imri Goldberg (lorgandon) Date: 2007-05-03 13:23 Message: Logged In: YES user_id=1715564 Originator: YES This also seems to be the cause of bug "[ 908441 ] default index for __getslice__ is not sys.maxint" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712236&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-1712419 ] Cannot use dict with unicode keys as keyword arguments
Feature Requests item #1712419, was opened at 2007-05-03 17:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use dict with unicode keys as keyword arguments
Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword
argument to a function. For example:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
... print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
File "", line 1, in
TypeError: fn() keywords must be strings
>>>
Unicode strings should be converted to str automatically using the site
specific default encoding or something similar solution.
This bug caused problems when decoding dictionaries from data formats such as
XML or JSON. Usually unicode strings are returned from such modules, such as
simplejson. Manual encoding from unicode to str causes performance loss if this
cannot be done by Python automatically.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 18:53
Message:
Logged In: YES
user_id=80475
Originator: NO
Recommend closing this as not-a-bug.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-04 05:27
Message:
Logged In: YES
user_id=38388
Originator: NO
Python (currently) does not allow non-ASCII identifiers, so it's not
surprising that Unicode parameter names don't work.
It's also a really bad idea to pass data from an AJAX XML or JSON request
directly to a function without doing at least some post-processing of the
data in order to prevent DOS attacks, code injection, etc.
dict((str(key), value) for key, value in kw.iteritems()) is all that's
needed for the above.
BTW, I don't think those few micro-seconds really matter in the face of
XML or JSON decoding, network latency, etc. ;-)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-03 23:10
Message:
Logged In: YES
user_id=849994
Originator: NO
In any case, this is a feature request.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Bugs item #1487481, was opened at 2006-05-12 11:32 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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 Private: No Submitted By: G�ran Uddeborg (goeran) >Assigned to: Nobody/Anonymous (nobody) Summary: Could BIND_FIRST be removed on HP-UX? Initial Comment: I'm trying to build Python 2.4.3 on HP-UX 11. I need tkinter, so I have first built Tcl and Tk 8.4.13. During the build, the python interpreter crashes. When running the setup.py script, just after making the _tkinter.sl module, it crashes with a memory fault. I've tried to investigate this, and it seems that malloc and friends gets confused by the dynamic loading. I've filed a support request with HP about this. One observation I made is that this malloc bug seems to be connected with the use of BIND_FIRST in dynload_hpux.c. If I just remove this flag (in two places) it appears as if Python works normally. I'm hesitant if this is a good idea. BIND_FIRST is there as an explicit, non-default, flag. Somebody must have choosen to do so for some reason. What was that reason? And is it still valid? If not, maybe the flag could be removed, and this problem in HP-UX be avoided? -- Comment By: Alexander Tyutyunnik (atyutyunnik) Date: 2007-05-18 19:41 Message: Logged In: YES user_id=1558596 Originator: NO I am using on SWIG 1.3.29+ with Python 2.5 on HP-UX 11.23, Itanium 64bit. It had failed to work (unresolved symbols) until I fixed code this way: // flags = BIND_FIRST | BIND_DEFERRED; flags = BIND_DEFERRED|BIND_VERBOSE; instead of: flags = BIND_FIRST | BIND_DEFERRED; Can anyone please fix it? -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-05-19 01:45 Message: Logged In: YES user_id=6380 Peter Kropf wrote: """ BIND_FIRST causes the dynamic loader to place the newly loaded shared library symbol table at the head of the lookup order. This causes symbol lookups from that time forward to check the newly loaded symbol table before everything else. I can see this causing interesting things to happen to a program if a shared library contains symbol names that are the same as those of, let's say, the C runtime library. >From what I remember of Python and HP-UX, I'd guess that this was added for an extension module. I don't think that it would be from the standard Python libraries but rather for a user's custom extension. """ -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-05-18 18:51 Message: Logged In: YES user_id=6380 Sorry, I don't have access to email that old any more. HP-UX is quite different now than it was then. It would make more sense to ask an HP-UX expert. I'll ask Peter Kropf, who helped Elemental with the HP-UX port. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-13 12:38 Message: Logged In: YES user_id=21627 BIND_FIRST was added with this commit: r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996) | 2 lines Geänderte Pfade: M /python/trunk/Python/importdl.c Some extra flags that an HPUX user wants me to add. Guido, do you have any records on which user that was and why he wanted these flags to be added? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&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: Documentation Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Alan (aisaac0) Date: 2007-05-18 21:28 Message: Logged In: YES user_id=1025672 Originator: YES While I do not mind my language being rejected, *something* should be added to warn users. What the previous comment fails to mention is the number of people on c.l.python, some of whom are quite sophisticated users, who failed to discover the source of indeterminacy. Users should not have to "rediscover" this because of a documentation failure. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:08 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the suggested text is simply incorrect. Given deterministic assignment of hash values and a consistent insertion order, the order of keys in a set or dictionary is fully determined. I've read the source of this suggestion on comp.lang.python and commented there. The underlying issue had nothing to do with either sets or dicts. The code in question "re-discovered" that the location of objects in memory would vary between runs if the user deleted a pyc file for a module. The OP's script used object ids as hash values, hence the set/dict ordering could vary between runs. This was at odds with his expectation that that the ordering would be deterministic. The moral is that non-deterministic hash values lead to non-deterministic set/dict ordering. The docs for sets and dicts should not be muddled with tangential discussions about implementation specific details regarding what governs where objects are placed in memory. -- Comment By: Alan (aisaac0) Date: 2007-05-18 13:00 Message: Logged In: YES user_id=1025672 Originator: YES Location in memory. See Peter Otten's discussion at http://www.thescripts.com/forum/post2552380-16.html -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 12:05 Message: Logged In: YES user_id=21627 Originator: NO What factors outside the containing program influence iteration order? Iteration is completely deterministic, and only depends on the items inserted, and the order in which they were inserted, neither of which is outside the scope of the containing program. It's just that the order is not easily predictable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) >Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 20:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 14:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 14:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 10:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 21:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 20:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 14:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 14:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 10:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&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: Documentation Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 08:38 Message: Logged In: YES user_id=21627 Originator: NO The documentation already says "Being an unordered collection, sets do not record element position or order of insertion." If users read this and fail to understand the notion of an unordered collection, I see no way of "fixing" this. -- Comment By: Alan (aisaac0) Date: 2007-05-19 04:28 Message: Logged In: YES user_id=1025672 Originator: YES While I do not mind my language being rejected, *something* should be added to warn users. What the previous comment fails to mention is the number of people on c.l.python, some of whom are quite sophisticated users, who failed to discover the source of indeterminacy. Users should not have to "rediscover" this because of a documentation failure. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 01:08 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the suggested text is simply incorrect. Given deterministic assignment of hash values and a consistent insertion order, the order of keys in a set or dictionary is fully determined. I've read the source of this suggestion on comp.lang.python and commented there. The underlying issue had nothing to do with either sets or dicts. The code in question "re-discovered" that the location of objects in memory would vary between runs if the user deleted a pyc file for a module. The OP's script used object ids as hash values, hence the set/dict ordering could vary between runs. This was at odds with his expectation that that the ordering would be deterministic. The moral is that non-deterministic hash values lead to non-deterministic set/dict ordering. The docs for sets and dicts should not be muddled with tangential discussions about implementation specific details regarding what governs where objects are placed in memory. -- Comment By: Alan (aisaac0) Date: 2007-05-18 20:00 Message: Logged In: YES user_id=1025672 Originator: YES Location in memory. See Peter Otten's discussion at http://www.thescripts.com/forum/post2552380-16.html -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 19:05 Message: Logged In: YES user_id=21627 Originator: NO What factors outside the containing program influence iteration order? Iteration is completely deterministic, and only depends on the items inserted, and the order in which they were inserted, neither of which is outside the scope of the containing program. It's just that the order is not easily predictable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
