From noreply at sourceforge.net Fri Sep 1 04:02:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 19:02:26 -0700 Subject: [ python-Bugs-1550263 ] Enhance and correct unittest's docs (redux) Message-ID: Bugs item #1550263, was opened at 2006-08-31 22:02 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=1550263&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance and correct unittest's docs (redux) Initial Comment: Following up on SF #1534922 ("Cleanup/error-correction for unittest's docs"), this patch adds the following corrections and clairifications to Doc/lib/libunittest.tex: 1) Add language to the section on TestLoader.loadTestsFromName() to make it explicit in what order the "module/test case class/TestSuite instance/test method within a test case class/callable object which returns a TestCase or TestSuite instance" tests are applied. 2) Add language to the section on TestLoader.getTestCaseNames() to make it explicit that the method's argument should be a subclass of TestCase. 3) Add language to the docs for TestCase.run() to clairfying the relationship between TestCase.run() and TestCase.defaultTestResult(). 4) Better specify the purpose of TestCase.defaultTestResult(). The previous docs were vague and misleading. 5) Add language to the docs for the TestCase class that better explains and illustrates the class's purpose and usage. In particular, docs on the constructor's optional ``methodName'' parameter were added; this parameter was previously undocumented. 6) Add a brief mention of TestResult to the "Classes and functions" section. 7) Add information on the default implementation of several TestResult methods. In addition, numerous smaller tweaks to grammar and phrasing were made. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470 From noreply at sourceforge.net Fri Sep 1 05:58:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 20:58:35 -0700 Subject: [ python-Bugs-1550263 ] Enhance and correct unittest's docs (redux) Message-ID: Bugs item #1550263, was opened at 2006-08-31 22:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&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: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enhance and correct unittest's docs (redux) Initial Comment: Following up on SF #1534922 ("Cleanup/error-correction for unittest's docs"), this patch adds the following corrections and clairifications to Doc/lib/libunittest.tex: 1) Add language to the section on TestLoader.loadTestsFromName() to make it explicit in what order the "module/test case class/TestSuite instance/test method within a test case class/callable object which returns a TestCase or TestSuite instance" tests are applied. 2) Add language to the section on TestLoader.getTestCaseNames() to make it explicit that the method's argument should be a subclass of TestCase. 3) Add language to the docs for TestCase.run() to clairfying the relationship between TestCase.run() and TestCase.defaultTestResult(). 4) Better specify the purpose of TestCase.defaultTestResult(). The previous docs were vague and misleading. 5) Add language to the docs for the TestCase class that better explains and illustrates the class's purpose and usage. In particular, docs on the constructor's optional ``methodName'' parameter were added; this parameter was previously undocumented. 6) Add a brief mention of TestResult to the "Classes and functions" section. 7) Add information on the default implementation of several TestResult methods. In addition, numerous smaller tweaks to grammar and phrasing were made. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-08-31 23:58 Message: Logged In: YES user_id=3066 Committed as revisions 51675 (Python 2.5) and 51676 (Python 2.6). Anthony agreed that documentation improvements were acceptable changes from 2.5 release candidate to 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470 From noreply at sourceforge.net Fri Sep 1 06:02:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 21:02:00 -0700 Subject: [ python-Bugs-1550263 ] Enhance and correct unittest's docs (redux) Message-ID: Bugs item #1550263, was opened at 2006-08-31 22:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&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: Python 2.4 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enhance and correct unittest's docs (redux) Initial Comment: Following up on SF #1534922 ("Cleanup/error-correction for unittest's docs"), this patch adds the following corrections and clairifications to Doc/lib/libunittest.tex: 1) Add language to the section on TestLoader.loadTestsFromName() to make it explicit in what order the "module/test case class/TestSuite instance/test method within a test case class/callable object which returns a TestCase or TestSuite instance" tests are applied. 2) Add language to the section on TestLoader.getTestCaseNames() to make it explicit that the method's argument should be a subclass of TestCase. 3) Add language to the docs for TestCase.run() to clairfying the relationship between TestCase.run() and TestCase.defaultTestResult(). 4) Better specify the purpose of TestCase.defaultTestResult(). The previous docs were vague and misleading. 5) Add language to the docs for the TestCase class that better explains and illustrates the class's purpose and usage. In particular, docs on the constructor's optional ``methodName'' parameter were added; this parameter was previously undocumented. 6) Add a brief mention of TestResult to the "Classes and functions" section. 7) Add information on the default implementation of several TestResult methods. In addition, numerous smaller tweaks to grammar and phrasing were made. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-09-01 00:02 Message: Logged In: YES user_id=3066 Re-opening; these should be considered for Python 2.4.4 as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-08-31 23:58 Message: Logged In: YES user_id=3066 Committed as revisions 51675 (Python 2.5) and 51676 (Python 2.6). Anthony agreed that documentation improvements were acceptable changes from 2.5 release candidate to 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470 From noreply at sourceforge.net Fri Sep 1 06:03:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 21:03:02 -0700 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Fri Sep 1 06:38:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 21:38:52 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 02:27 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-08-31 23:38 Message: Logged In: YES user_id=771074 It might be simpler to check if the warning is in the line cache after the disposition is determined from the filters. In the case of 'always' and 'error', there's no need to check the cache at all. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 15:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Fri Sep 1 12:44:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 03:44:30 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 09:27 Message generated for change (Comment added) made by marienz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-09-01 12:44 Message: Logged In: YES user_id=857292 The whole point of that cache is to not go through the list of filters if the warning is in the cache. Why would you keep the cache around if you search through the filters in every case anyway? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 06:38 Message: Logged In: YES user_id=771074 It might be simpler to check if the warning is in the line cache after the disposition is determined from the filters. In the case of 'always' and 'error', there's no need to check the cache at all. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 22:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Fri Sep 1 15:26:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 06:26:38 -0700 Subject: [ python-Bugs-1550524 ] inspect module and class startlineno Message-ID: Bugs item #1550524, was opened at 2006-09-01 17:56 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=1550524&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 Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Nobody/Anonymous (nobody) Summary: inspect module and class startlineno Initial Comment: Inspect module fails to find the correct starting line number of a class. :: import inspect def a_func(): class AClass(object): pass class AClass(object): pass print inspect.findsource(AClass)[1] # the result should have been 7, but it is 4 After reading `inspect` module I realized that for classes it does a simple RE search to find their definition location. Apart from that I think python does not seem to fully support classes with the same name in one module (nested classes that are defined in other functions or classes). That is a `ClassType` only holds its module and its name and that is hardly enough for runtime analysis of objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550524&group_id=5470 From noreply at sourceforge.net Fri Sep 1 16:12:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 07:12:43 -0700 Subject: [ python-Bugs-1550559 ] SWIG wrappers incompatible with 2.5c1 Message-ID: Bugs item #1550559, was opened at 2006-09-01 14: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=1550559&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 Submitted By: Andrew Gregory (andrew22) Assigned to: Nobody/Anonymous (nobody) Summary: SWIG wrappers incompatible with 2.5c1 Initial Comment: Can now no longer compile SWIG wrappers following upgrade to Python 2.5c1 - presumably as a result of changes in Python.h. Used MinGW compilers (3.2.3 and 3.4.2) on Windows XP. See http://groups.google.co.uk/group/comp.lang.python/brows e_thread/thread/7a44c95f6aa68ef8/3e7e1e2d2cce56ed? lnk=gst&q=gregory&rnum=3#3e7e1e2d2cce56ed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550559&group_id=5470 From noreply at sourceforge.net Fri Sep 1 19:19:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 10:19:41 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 02:27 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-09-01 12:19 Message: Logged In: YES user_id=771074 Without the cache, the only filters you could possibly implement would be 'error' and 'ignore'. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-09-01 05:44 Message: Logged In: YES user_id=857292 The whole point of that cache is to not go through the list of filters if the warning is in the cache. Why would you keep the cache around if you search through the filters in every case anyway? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-31 23:38 Message: Logged In: YES user_id=771074 It might be simpler to check if the warning is in the line cache after the disposition is determined from the filters. In the case of 'always' and 'error', there's no need to check the cache at all. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 15:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Fri Sep 1 21:20:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 12:20:51 -0700 Subject: [ python-Bugs-1550714 ] itertools.tee raises SystemError Message-ID: Bugs item #1550714, was opened at 2006-09-01 15:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 From noreply at sourceforge.net Fri Sep 1 22:57:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 13:57:47 -0700 Subject: [ python-Bugs-1550714 ] itertools.tee raises SystemError Message-ID: Bugs item #1550714, was opened at 2006-09-01 14:20 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) >Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:08:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:08:41 -0700 Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args Message-ID: Bugs item #1156179, was opened at 2005-03-03 15:42 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&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: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Rose (grincheroo) Assigned to: Nobody/Anonymous (nobody) Summary: Calls from VBScript clobber passed args Initial Comment: I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a Python function from VBScript AND pass a local var as the first parameter AND don't use the return value, then the local var I passed in is, upon the function's return, set to Null. If I store the return value (even if there isn't one) OR pass the return value to another function, this doesn't happen. I'm attaching some snippets that demonstrate and work around the bug. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 16:08 Message: Logged In: YES user_id=771074 I think this is actually a vbscript behaviour. If not, it's a bug in Pywin32's Active Scripting implementation. Either way, this shoud probably be closed as third-party. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 10:41 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 10:39 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 10:39 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:17:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:17:31 -0700 Subject: [ python-Bugs-1550761 ] itertools.tee raises SystemError Message-ID: Bugs item #1550761, was opened at 2006-09-01 17:17 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=1550761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550761&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:18:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:18:28 -0700 Subject: [ python-Bugs-1550761 ] itertools.tee raises SystemError Message-ID: Bugs item #1550761, was opened at 2006-09-01 17:17 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=835142 SF glitch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550761&group_id=5470 From noreply at sourceforge.net Sat Sep 2 00:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 15:23:19 -0700 Subject: [ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Message-ID: Bugs item #1550791, was opened at 2006-09-01 22:23 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=1550791&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. L?wis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 From noreply at sourceforge.net Sat Sep 2 04:25:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 19:25:25 -0700 Subject: [ python-Bugs-1548092 ] curses module segfaults on invalid tparm arguments Message-ID: Bugs item #1548092, was opened at 2006-08-28 10:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) >Assigned to: Neal Norwitz (nnorwitz) Summary: curses module segfaults on invalid tparm arguments Initial Comment: At least on my platform the ncurses "tparm" function returns NULL on certain invalid arguments. PyCurses_tparm does not check the return value, it just passes it to PyString_FromString. This means: python -c "import curses;curses.setupterm();print curses.tparm('', curses.COLOR_GREEN)" gives me: zsh: segmentation fault python -c (tested with python 2.4.3) I am not sure what the best fix is. An exception would make sense to me, but the (related) tigetstr function returns None to python if the wrapped c function returns NULL, and I have not used the curses module enough to know what is more common. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:25 Message: Logged In: YES user_id=33168 reproduced with 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470 From noreply at sourceforge.net Sat Sep 2 04:26:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 19:26:18 -0700 Subject: [ python-Bugs-1550714 ] itertools.tee raises SystemError Message-ID: Bugs item #1550714, was opened at 2006-09-01 12:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) >Assigned to: Neal Norwitz (nnorwitz) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:26 Message: Logged In: YES user_id=33168 this needs a check. i've got a patch that i'll check in in a bit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 From noreply at sourceforge.net Sat Sep 2 04:45:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 19:45:57 -0700 Subject: [ python-Bugs-1547931 ] Typo in Language Reference Section 3.2 Class Instances Message-ID: Bugs item #1547931, was opened at 2006-08-28 07:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1547931&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: Fixed Priority: 5 Submitted By: whesse_at_clarkson (whesse1) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in Language Reference Section 3.2 Class Instances Initial Comment: In the Python Language Reference, Section 3.2, subsection "Class Instances", HTML version, the sentence ending "... user-defined method object whose im_class attribute is C whose im_self attribute is the instance. " should add the word "and" to read "... user-defined method object whose im_class attribute is C and whose im_self attribute is the instance. " ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:45 Message: Logged In: YES user_id=33168 Thanks for the report! Committed revision 51681. 2.6 Committed revision 51682. 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1547931&group_id=5470 From noreply at sourceforge.net Sat Sep 2 04:51:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 19:51:15 -0700 Subject: [ python-Bugs-1548092 ] curses module segfaults on invalid tparm arguments Message-ID: Bugs item #1548092, was opened at 2006-08-28 10:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&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: Open >Resolution: Later Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Neal Norwitz (nnorwitz) Summary: curses module segfaults on invalid tparm arguments Initial Comment: At least on my platform the ncurses "tparm" function returns NULL on certain invalid arguments. PyCurses_tparm does not check the return value, it just passes it to PyString_FromString. This means: python -c "import curses;curses.setupterm();print curses.tparm('', curses.COLOR_GREEN)" gives me: zsh: segmentation fault python -c (tested with python 2.4.3) I am not sure what the best fix is. An exception would make sense to me, but the (related) tigetstr function returns None to python if the wrapped c function returns NULL, and I have not used the curses module enough to know what is more common. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:51 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51683. 2.6 Needs to be backported to 2.5.1 and earlier. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:25 Message: Logged In: YES user_id=33168 reproduced with 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470 From noreply at sourceforge.net Sat Sep 2 04:58:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 19:58:46 -0700 Subject: [ python-Bugs-1550714 ] itertools.tee raises SystemError Message-ID: Bugs item #1550714, was opened at 2006-09-01 12:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&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: Later Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Neal Norwitz (nnorwitz) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:58 Message: Logged In: YES user_id=33168 Thanks for the report! Committed revision 51684. 2.6 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:26 Message: Logged In: YES user_id=33168 this needs a check. i've got a patch that i'll check in in a bit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 From noreply at sourceforge.net Sat Sep 2 11:05:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 02:05:09 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 12:05 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=1550938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Sat Sep 2 11:05:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 02:05:47 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 12:05 Message generated for change (Settings changed) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Sat Sep 2 11:21:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 02:21:11 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: 8 Submitted By: ganges master (gangesmaster) >Assigned to: Neal Norwitz (nnorwitz) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 09:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Sat Sep 2 20:27:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 11:27:30 -0700 Subject: [ python-Bugs-1551113 ] random.choice(setinstance) fails Message-ID: Bugs item #1551113, was opened at 2006-09-02 13: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=1551113&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 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: random.choice(setinstance) fails Initial Comment: It seems perverse that random.choice cannot pick from a set. (Maybe it is also perverse that it cannot pick a key from a dict.) The current definition is def choice(self, seq): """Choose a random element from a non-empty sequence.""" return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty How about something along the lines of: def choice(self, seq): """Choose a random element from a non-empty sequence.""" idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551113&group_id=5470 From noreply at sourceforge.net Sat Sep 2 20:33:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 11:33:10 -0700 Subject: [ python-Bugs-1551113 ] random.choice(setinstance) fails Message-ID: Bugs item #1551113, was opened at 2006-09-02 18:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551113&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 Submitted By: Alan (aisaac0) >Assigned to: Raymond Hettinger (rhettinger) Summary: random.choice(setinstance) fails Initial Comment: It seems perverse that random.choice cannot pick from a set. (Maybe it is also perverse that it cannot pick a key from a dict.) The current definition is def choice(self, seq): """Choose a random element from a non-empty sequence.""" return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty How about something along the lines of: def choice(self, seq): """Choose a random element from a non-empty sequence.""" idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 18:33 Message: Logged In: YES user_id=849994 To Raymond: Wasn't there a discussion about random.choice() some time ago? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551113&group_id=5470 From noreply at sourceforge.net Sat Sep 2 20:49:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 11:49:46 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 02:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: 8 Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 11:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 02:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Sat Sep 2 21:37:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 12:37:46 -0700 Subject: [ python-Bugs-1551113 ] random.choice(setinstance) fails Message-ID: Bugs item #1551113, was opened at 2006-09-02 14:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551113&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 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: random.choice(setinstance) fails Initial Comment: It seems perverse that random.choice cannot pick from a set. (Maybe it is also perverse that it cannot pick a key from a dict.) The current definition is def choice(self, seq): """Choose a random element from a non-empty sequence.""" return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty How about something along the lines of: def choice(self, seq): """Choose a random element from a non-empty sequence.""" idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-02 15:37 Message: Logged In: YES user_id=31435 This is certainly a feature request rather than a bug (the code is working as documented (a set is not a sequence) and as designed). Change it to a feature request, and it will probably just sit there for years ;-) The unwritten promise is that choice(s) on a sequence of length N will take O(1) time and O(1) space. There is no known way to do this given the current implementations of dicts and sets better than O(N) time and O(1) space (and even that poor behavior is tricky to achieve -- the way suggested by the OP requires O(N) time and O(N) space). Rather than give users surprisingly atrocious performance for one type of argument, leaving it out of choice() emphasizes reality: if you want efficient random selection from a set, you /need/ to use a fancier data structure than a Python set. OTOH, if you don't care about efficiency, it's hardly a burden to write random.choice(list(myset)) instead. Then at least the atrociousness of your algorithm design is obvious to readers of the code <0.5 wink>. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 14:33 Message: Logged In: YES user_id=849994 To Raymond: Wasn't there a discussion about random.choice() some time ago? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551113&group_id=5470 From noreply at sourceforge.net Sun Sep 3 00:44:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 15:44:10 -0700 Subject: [ python-Feature Requests-1551113 ] random.choice(setinstance) fails Message-ID: Feature Requests item #1551113, was opened at 2006-09-02 13:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1551113&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: Closed >Resolution: Rejected Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: random.choice(setinstance) fails Initial Comment: It seems perverse that random.choice cannot pick from a set. (Maybe it is also perverse that it cannot pick a key from a dict.) The current definition is def choice(self, seq): """Choose a random element from a non-empty sequence.""" return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty How about something along the lines of: def choice(self, seq): """Choose a random element from a non-empty sequence.""" idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-02 17:44 Message: Logged In: YES user_id=80475 Sorry, even as a feature request, this is doomed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-02 14:37 Message: Logged In: YES user_id=31435 This is certainly a feature request rather than a bug (the code is working as documented (a set is not a sequence) and as designed). Change it to a feature request, and it will probably just sit there for years ;-) The unwritten promise is that choice(s) on a sequence of length N will take O(1) time and O(1) space. There is no known way to do this given the current implementations of dicts and sets better than O(N) time and O(1) space (and even that poor behavior is tricky to achieve -- the way suggested by the OP requires O(N) time and O(N) space). Rather than give users surprisingly atrocious performance for one type of argument, leaving it out of choice() emphasizes reality: if you want efficient random selection from a set, you /need/ to use a fancier data structure than a Python set. OTOH, if you don't care about efficiency, it's hardly a burden to write random.choice(list(myset)) instead. Then at least the atrociousness of your algorithm design is obvious to readers of the code <0.5 wink>. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 13:33 Message: Logged In: YES user_id=849994 To Raymond: Wasn't there a discussion about random.choice() some time ago? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1551113&group_id=5470 From noreply at sourceforge.net Sun Sep 3 02:38:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 17:38:05 -0700 Subject: [ python-Bugs-1551238 ] Build of 2.4.3 on fedora core 5 fails to find asm/msr.h Message-ID: Bugs item #1551238, was opened at 2006-09-02 17:38 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=1551238&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: None Status: Open Resolution: None Priority: 5 Submitted By: George R. Goffe (grgoffe) Assigned to: Nobody/Anonymous (nobody) Summary: Build of 2.4.3 on fedora core 5 fails to find asm/msr.h Initial Comment: Howdy, I just downloaded Python-2.4.3 and tried to build it with the enclosed results. I then proceeded to check out the latest from svn and that version DOES build. This is just a fyi bug report unless you think otherwise. Regards, George... gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c Python/ceval.c:50:21: error: asm/msr.h: No such file or directory Python/ceval.c: In function 'PyEval_EvalFrame': Python/ceval.c:578: warning: implicit declaration of function 'rdtscll' make: *** [Python/ceval.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551238&group_id=5470 From noreply at sourceforge.net Sun Sep 3 09:10:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 00:10:21 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: 8 Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-03 07:10 Message: Logged In: YES user_id=849994 See attached patch. I couldn't find a mention of this ValueError in the PEP or the docs, so changing it to ImportError and giving better error messages looks like the way to go. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 18:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 09:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Sun Sep 3 14:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 05:03:23 -0700 Subject: [ python-Bugs-1551427 ] tiny bug in win32_urandom Message-ID: Bugs item #1551427, was opened at 2006-09-03 14:03 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=1551427&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocco Matano (rocco_m) Assigned to: Nobody/Anonymous (nobody) Summary: tiny bug in win32_urandom Initial Comment: In the file ...\Python-2.4.3\Modules\posixmodule.c the function win32_urandom tries to get the addresses of the functions 'CryptAcquireContextA' and 'CryptGenRandom' like this: pCryptAcquireContext=(CRYPTACQUIRECONTEXTA)GetProcAddress( hAdvAPI32, "CryptAcquireContextA"); if (pCryptAcquireContext == NULL) return PyErr_Format(PyExc_NotImplementedError, "CryptAcquireContextA not found"); pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress( hAdvAPI32, "CryptGenRandom"); if (pCryptAcquireContext == NULL) /* <- test pCryptGenRandom instead */ return PyErr_Format(PyExc_NotImplementedError, "CryptGenRandom not found"); After the second call to GetProcAddress() pCryptGenRandom should be tested against NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551427&group_id=5470 From noreply at sourceforge.net Sun Sep 3 14:24:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 05:24:16 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Sun Sep 3 21:02:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 12:02:36 -0700 Subject: [ python-Bugs-1548288 ] sgmllib.sgmlparser is not thread safe Message-ID: Bugs item #1548288, was opened at 2006-08-28 19:32 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&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 Submitted By: Andres Riancho (andresriancho) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.sgmlparser is not thread safe Initial Comment: Python version: =============== dz0 at fre3ak:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Problem description: ==================== sgmlparser is not thread safe, i discovered this problem when trying to fetch and parse many html files at the same time. An example of this bug can be found attached. The sgmlparser input html is this string: ''*100 , this was written this way to simplify the code, please note that if you replace this string with a "large" html document, it will also fail. solution: ========= make the lib thread safe, or add some lines to the documentation saying that it aint thread safe. Traceback: ========== python sgml-not-threadSafe.py Started all threads Successfully parsed html Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "sgml-not-threadSafe.py", line 10, in parseHtml self._parser.feed( html ) File "/usr/lib/python2.4/sgmllib.py", line 95, in feed self.goahead(0) File "/usr/lib/python2.4/sgmllib.py", line 129, in goahead k = self.parse_starttag(i) File "/usr/lib/python2.4/sgmllib.py", line 262, in parse_starttag self.error('unexpected call to parse_starttag') File "/usr/lib/python2.4/sgmllib.py", line 102, in error raise SGMLParseError(message) SGMLParseError: unexpected call to parse_starttag Successfully parsed html Successfully parsed html Additional note =============== To recreate this bug, you should run the sample code more than one time. Thread handling aint always the same, the issue is there but sometimes it fails to appear on the first (second, third...) run. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 12:02 Message: Logged In: YES user_id=341410 The sgmllib makes no claims as to thread safety, which implies that it is generally not sharable between threads. You can work around this issue by creating a new parser instance for each thread that you want to parse. Suggested close as "Wont Fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&group_id=5470 From noreply at sourceforge.net Sun Sep 3 21:07:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 12:07:41 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 13:47 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 12:07 Message: Logged In: YES user_id=341410 Lists have an .index(obj[, start[, stop]]) method that tells you the index of the first object that matches obj, raising an exception otherwise. Generally speaking, you can get better performance for repeated searches by... dct = {} for i,(k,v) in enumerate(lst): dct.setdefault(k, []).append(i) Then to find the first index... dct.get(k, [None])[0] Suggested close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Mon Sep 4 01:14:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 16:14:23 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-09-03 16:14 Message: Logged In: YES user_id=413 weird i would not expect this to happen regardless of berkeleydb version. can you also do a 'ldd' on the _bsddb.so binary that your python build produced? presumably libdb42.so or something similar should be in the output. also, when to compile python does it print out a message saying what version of the include files and libs it thinks its compiling and linking with? it looks like you're using rhel4 or centos4; i'll try compiling 2.5rc1 on that myself when i get a chance. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 06:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-08-22 06:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Mon Sep 4 01:41:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 16:41:11 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-09-03 16:41 Message: Logged In: YES user_id=413 i was unable to reproduce this problem on either 32-bit or 64-bit CentOS 4. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-09-03 16:14 Message: Logged In: YES user_id=413 weird i would not expect this to happen regardless of berkeleydb version. can you also do a 'ldd' on the _bsddb.so binary that your python build produced? presumably libdb42.so or something similar should be in the output. also, when to compile python does it print out a message saying what version of the include files and libs it thinks its compiling and linking with? it looks like you're using rhel4 or centos4; i'll try compiling 2.5rc1 on that myself when i get a chance. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 06:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-08-22 06:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Mon Sep 4 01:55:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 16:55:04 -0700 Subject: [ python-Bugs-1551669 ] Wrong link to unicode database Message-ID: Bugs item #1551669, was opened at 2006-09-03 23:55 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=1551669&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 Submitted By: Yevgen Muntyan (emuntyan) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong link to unicode database Initial Comment: http://docs.python.org/lib/module-unicodedata.html has a link to unicode database (second paragraph). The link there is http://www.unicode.org/Public/UNIDATA/UnicodeData.html, it's broken. The correct one is probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt (there are lot of files in http://www.unicode.org/Public/UNIDATA/) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 From noreply at sourceforge.net Mon Sep 4 07:14:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Sep 2006 22:14:56 -0700 Subject: [ python-Bugs-1551669 ] Wrong link to unicode database Message-ID: Bugs item #1551669, was opened at 2006-09-04 08:55 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&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 Submitted By: Yevgen Muntyan (emuntyan) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong link to unicode database Initial Comment: http://docs.python.org/lib/module-unicodedata.html has a link to unicode database (second paragraph). The link there is http://www.unicode.org/Public/UNIDATA/UnicodeData.html, it's broken. The correct one is probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt (there are lot of files in http://www.unicode.org/Public/UNIDATA/) ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-09-04 14:14 Message: Logged In: YES user_id=671362 Given that Python 2.4 uses 3.2 database, we should link to http://www.unicode.org/Public/3.2-Update/UnicodeCharacterDatabase-3.2.0.html As for 2.5 and trunk(both using 4.1.0 database), they're linked to http://www.unicode.org/Public/4.1.0/ucd/UCD.html Any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 From noreply at sourceforge.net Mon Sep 4 11:08:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 02:08:52 -0700 Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking Message-ID: Bugs item #1520864, was opened at 2006-07-11 23:21 Message generated for change (Comment added) made by sadrejeb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: Fixed Priority: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) ---------------------------------------------------------------------- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 09:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-12 05:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-12 02:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 From noreply at sourceforge.net Mon Sep 4 12:05:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 03:05:45 -0700 Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking Message-ID: Bugs item #1520864, was opened at 2006-07-11 23:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 10:05 Message: Logged In: YES user_id=849994 You're right. Attached patch fixes this. ---------------------------------------------------------------------- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 09:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-12 05:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-12 02:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 From noreply at sourceforge.net Mon Sep 4 14:30:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 05:30:45 -0700 Subject: [ python-Bugs-1551669 ] Wrong link to unicode database Message-ID: Bugs item #1551669, was opened at 2006-09-04 01:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&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 Submitted By: Yevgen Muntyan (emuntyan) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong link to unicode database Initial Comment: http://docs.python.org/lib/module-unicodedata.html has a link to unicode database (second paragraph). The link there is http://www.unicode.org/Public/UNIDATA/UnicodeData.html, it's broken. The correct one is probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt (there are lot of files in http://www.unicode.org/Public/UNIDATA/) ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-04 14:30 Message: Logged In: YES user_id=38388 I think the documentation should link to the new standard URL: http://www.unicode.org/Public/UNIDATA/UCD.html and then point out that Python 2.4 shipped with version 3.2 and Python 2.5 will ship with 4.1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-09-04 07:14 Message: Logged In: YES user_id=671362 Given that Python 2.4 uses 3.2 database, we should link to http://www.unicode.org/Public/3.2-Update/UnicodeCharacterDatabase-3.2.0.html As for 2.5 and trunk(both using 4.1.0 database), they're linked to http://www.unicode.org/Public/4.1.0/ucd/UCD.html Any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 From noreply at sourceforge.net Mon Sep 4 23:42:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 14:42:12 -0700 Subject: [ python-Bugs-1549574 ] Pdb parser bug Message-ID: Bugs item #1549574, was opened at 2006-08-30 13:46 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Pdb parser bug Initial Comment: >>> import pdb >>> pdb.set_trace() --Return-- > (1)()->None (Pdb) p ";;" *** SyntaxError: SyntaxError('EOL while scanning single-quoted string', ('', 1, 1, '"')) *** SyntaxError: EOL while scanning single-quoted string (, line 1) Still present in trunk:51513M ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-09-04 14:42 Message: Logged In: YES user_id=971153 For the record, this behaviour is explicitly documented in pdb docs. from: http://www.python.org/doc/current/lib/debugger-commands.html """Multiple commands may be entered on a single line, separated by ";;".... No intelligence is applied to separating the commands; the input is split at the first ";;" pair, even if it is in the middle of a quoted string.""" So should this be considered a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:26:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:26:03 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 02:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: 9 Submitted By: ganges master (gangesmaster) >Assigned to: Thomas Wouters (twouters) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:26 Message: Logged In: YES user_id=33168 Thomas, could you take a look at this patch. I'm not sure it's correct. I thought you had some reasons for these ValueErrors (unless it was diff code). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-03 00:10 Message: Logged In: YES user_id=849994 See attached patch. I couldn't find a mention of this ValueError in the PEP or the docs, so changing it to ImportError and giving better error messages looks like the way to go. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 11:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 02:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:27:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:27:27 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&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: 7 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:47:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:47:14 -0700 Subject: [ python-Bugs-1552304 ] UnixCCompiler runtime_library_dir uses -R instead of -Wl, -R Message-ID: Bugs item #1552304, was opened at 2006-09-04 19:47 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=1552304&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: None Status: Open Resolution: None Priority: 5 Submitted By: TFKyle (tfkyle) Assigned to: Nobody/Anonymous (nobody) Summary: UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R Initial Comment: in some cases where gcc is named oddly (i686-pc-linux-gnu-g++/i686-pc-linux-gnu-gcc in this case, gentoo names them like this) UnixCCompiler.runtime_library_dir_option will return -R instead of -Wl,-R, there seems to be a check in there already for gcc/g++ though it only checks against the first 3 characters. perhaps a better approach would be to check "gcc" in compiler or "g++" in compiler or something similar ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:26:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:26:49 -0700 Subject: [ python-Bugs-1552304 ] UnixCCompiler runtime_library_dir uses -R instead of -Wl, -R Message-ID: Bugs item #1552304, was opened at 2006-09-04 19:47 Message generated for change (Comment added) made by tfkyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: TFKyle (tfkyle) Assigned to: Nobody/Anonymous (nobody) Summary: UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R Initial Comment: in some cases where gcc is named oddly (i686-pc-linux-gnu-g++/i686-pc-linux-gnu-gcc in this case, gentoo names them like this) UnixCCompiler.runtime_library_dir_option will return -R instead of -Wl,-R, there seems to be a check in there already for gcc/g++ though it only checks against the first 3 characters. perhaps a better approach would be to check "gcc" in compiler or "g++" in compiler or something similar ---------------------------------------------------------------------- >Comment By: TFKyle (tfkyle) Date: 2006-09-04 20:26 Message: Logged In: YES user_id=1065959 dup of http://sourceforge.net/tracker/index.php?func=detail&aid=1254718&group_id=5470&atid=305470 , sorry I should've looked harder before submitting ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:31:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:31:06 -0700 Subject: [ python-Bugs-1550714 ] itertools.tee raises SystemError Message-ID: Bugs item #1550714, was opened at 2006-09-01 12:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Neal Norwitz (nnorwitz) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:31 Message: Logged In: YES user_id=33168 Committed revision 51722. for 2.5 This also affects 2.4 if anyone wants to backport. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:58 Message: Logged In: YES user_id=33168 Thanks for the report! Committed revision 51684. 2.6 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:26 Message: Logged In: YES user_id=33168 this needs a check. i've got a patch that i'll check in in a bit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 From noreply at sourceforge.net Tue Sep 5 05:00:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 20:00:27 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&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: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Tue Sep 5 06:01:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 21:01:08 -0700 Subject: [ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking Message-ID: Bugs item #1520864, was opened at 2006-07-11 16:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: Fixed Priority: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 21:01 Message: Logged In: YES user_id=33168 Thanks for spotting this. Let us know if you find any more bugs. Well, I'm glad Georg and I came up with the same basic patch (thanks Georg!). I had worked it up prior to seeing his version here. It's also the same fix for the for loops. Committed revision 51729. (2.6) Committed revision 51730. (2.5) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 03:05 Message: Logged In: YES user_id=849994 You're right. Attached patch fixes this. ---------------------------------------------------------------------- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 02:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 22:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-11 19:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 From noreply at sourceforge.net Tue Sep 5 06:04:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 21:04:27 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-23 20:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&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: Closed >Resolution: Fixed Priority: 8 Submitted By: Jack Howarth (jwhowarth) >Assigned to: Tim Peters (tim_one) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 21:04 Message: Logged In: YES user_id=33168 Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4. ---------------------------------------------------------------------- Comment By: David Hopwood (dhopwood) Date: 2006-08-26 16:24 Message: Logged In: YES user_id=634468 The correct patch is the one that uses if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x) The one that uses (unsigned int)x will break some 64-bit platforms where int != long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 13:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 13:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 08:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 08:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 07:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 02:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-23 21:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Tue Sep 5 06:05:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 21:05:19 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-16 18:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: 9 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-08-17 21:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Tue Sep 5 07:12:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 22:12:09 -0700 Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc Message-ID: Bugs item #1521947, was opened at 2006-07-13 10:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 22:12 Message: Logged In: YES user_id=33168 Tim, how do you feel about backporting now? (Not sure if your opinion changed based on the other bug.) That and I'm cleaning out my mailbox, so I don't have to look at this any more. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-27 14:00 Message: Logged In: YES user_id=31435 Neal, as I said in the checkin comment, I expect it's no less likely that we'll get screwed by goofy platform values for LONG_MIN and LONG_MAX than that we /got/ screwed by an "over ambitious" compiler optimizing away "result == -result", so I'm not sure backporting is a good idea. I stuck in an assert that might fail if a platform is insane; if there are no reports of that assert triggering, then I'd feel better about backporting the change. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-27 03:49 Message: Logged In: YES user_id=1126061 Fixed for me on NetBSD -current AMD64, gcc 4.1.2 ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-27 01:31 Message: Logged In: YES user_id=42444 Fixed for me, too, and the code looks solid. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 21:48 Message: Logged In: YES user_id=33168 I reopened this bug as it still affects 2.4. Tim's fix should be backported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 21:35 Message: Logged In: YES user_id=33168 Tim's fix corrected the problem on amd64 gentoo linux with gcc 4.1.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-26 18:16 Message: Logged In: YES user_id=31435 Made a non-heroic effort to repair this in rev 50855, but have no platform on which it could make any difference (and apparently no Python buildbot test platform cares either) . Would be nice if someone who has such a platform could check against current Python trunk. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-17 02:20 Message: Logged In: YES user_id=42444 Yes, this is a duplicate of 1521726. The compiler people's answer is correct, and mystrtoul.c is incorrect. LONG_MIN has been in C since C90, so should be safe, but its value may not always be what you expect. However, the code breakage is worse that just that test, and there are the following 3 cases of undefined behaviour: 1) Casting and unsigned long to long above LONG_MAX. 2) That test. 3) result = -result. The fix should be to make result unsigned long, and check the range BEFORE any conversion. Nothing else is safe. It is a matter of taste whether to include a fiddle for the number that can be held only when negated - I wouldn't, and would let that number be converted to a Python long, but others might disagree. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-16 18:13 Message: Logged In: YES user_id=33168 Is this a duplicate of 1521726? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 From noreply at sourceforge.net Tue Sep 5 07:13:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 22:13:03 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: ?iga Seilnacht (zseil) >Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Tue Sep 5 07:21:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 22:21:44 -0700 Subject: [ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc Message-ID: Bugs item #1521947, was opened at 2006-07-13 13:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-05 01:21 Message: Logged In: YES user_id=31435 Well, I deliberately avoided using LONG_MIN in the patches for the other bug, so that should answer your question ;-) If someone wants to take the small risk of backporting it, fine by me -- it's not going to break on Windows, and if it doesn't break on your box either ... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 01:12 Message: Logged In: YES user_id=33168 Tim, how do you feel about backporting now? (Not sure if your opinion changed based on the other bug.) That and I'm cleaning out my mailbox, so I don't have to look at this any more. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-27 17:00 Message: Logged In: YES user_id=31435 Neal, as I said in the checkin comment, I expect it's no less likely that we'll get screwed by goofy platform values for LONG_MIN and LONG_MAX than that we /got/ screwed by an "over ambitious" compiler optimizing away "result == -result", so I'm not sure backporting is a good idea. I stuck in an assert that might fail if a platform is insane; if there are no reports of that assert triggering, then I'd feel better about backporting the change. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-27 06:49 Message: Logged In: YES user_id=1126061 Fixed for me on NetBSD -current AMD64, gcc 4.1.2 ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-27 04:31 Message: Logged In: YES user_id=42444 Fixed for me, too, and the code looks solid. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 00:48 Message: Logged In: YES user_id=33168 I reopened this bug as it still affects 2.4. Tim's fix should be backported. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 00:35 Message: Logged In: YES user_id=33168 Tim's fix corrected the problem on amd64 gentoo linux with gcc 4.1.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-26 21:16 Message: Logged In: YES user_id=31435 Made a non-heroic effort to repair this in rev 50855, but have no platform on which it could make any difference (and apparently no Python buildbot test platform cares either) . Would be nice if someone who has such a platform could check against current Python trunk. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-17 05:20 Message: Logged In: YES user_id=42444 Yes, this is a duplicate of 1521726. The compiler people's answer is correct, and mystrtoul.c is incorrect. LONG_MIN has been in C since C90, so should be safe, but its value may not always be what you expect. However, the code breakage is worse that just that test, and there are the following 3 cases of undefined behaviour: 1) Casting and unsigned long to long above LONG_MAX. 2) That test. 3) result = -result. The fix should be to make result unsigned long, and check the range BEFORE any conversion. Nothing else is safe. It is a matter of taste whether to include a fiddle for the number that can be held only when negated - I wouldn't, and would let that number be converted to a Python long, but others might disagree. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-16 21:13 Message: Logged In: YES user_id=33168 Is this a duplicate of 1521726? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 From noreply at sourceforge.net Tue Sep 5 07:22:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 22:22:04 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: ?iga Seilnacht (zseil) Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 05:22 Message: Logged In: YES user_id=849994 Attaching my patch here. Neal: PyObject_GC_TRACK is called in PyType_GenericAlloc, which is used for exceptions since the tp_alloc slot is 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Tue Sep 5 08:09:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 23:09:03 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: ?iga Seilnacht (zseil) Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 23:09 Message: Logged In: YES user_id=33168 Yeah, this makes sense. Georg, can you come up with a test for this? (It's ok if it's only triggered with -R flag.) This also needs a NEWS entry. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 22:22 Message: Logged In: YES user_id=849994 Attaching my patch here. Neal: PyObject_GC_TRACK is called in PyType_GenericAlloc, which is used for exceptions since the tp_alloc slot is 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Tue Sep 5 14:23:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 05:23:03 -0700 Subject: [ python-Bugs-1552618 ] PEP 290 <-> normal docu... Message-ID: Bugs item #1552618, was opened at 2006-09-05 14:23 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=1552618&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 290 <-> normal docu... Initial Comment: >From the PEP 290: """ For testing dictionary membership, use the 'in' keyword instead of the 'has_key()' method. """ http://www.python.org/dev/peps/pep-0290/#testing-dictionary-membership I think this should be insert in the normal Doc under: http://docs.python.org/dev/lib/typesmapping.html#l2h-294 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552618&group_id=5470 From noreply at sourceforge.net Tue Sep 5 14:45:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 05:45:30 -0700 Subject: [ python-Bugs-1552618 ] PEP 290 <-> normal docu... Message-ID: Bugs item #1552618, was opened at 2006-09-05 12:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552618&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: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 290 <-> normal docu... Initial Comment: >From the PEP 290: """ For testing dictionary membership, use the 'in' keyword instead of the 'has_key()' method. """ http://www.python.org/dev/peps/pep-0290/#testing-dictionary-membership I think this should be insert in the normal Doc under: http://docs.python.org/dev/lib/typesmapping.html#l2h-294 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 12:45 Message: Logged In: YES user_id=849994 Added a note in rev. 51740, 51741 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552618&group_id=5470 From noreply at sourceforge.net Tue Sep 5 15:16:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 06:16:25 -0700 Subject: [ python-Bugs-1525469 ] SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type Message-ID: Bugs item #1525469, was opened at 2006-07-19 14:06 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525469&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type Initial Comment: Use of sys.exc_value and sys.exc_type is not thread safe. It should just use sys.exc_info. Both exc_value and exc_type are used in two exceptiuon trapping locations. This goes back to at least 2.3, and I've checked 2.5 svn ver 50569 and it is still an issue. Russ ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-05 09:16 Message: Logged In: YES user_id=11375 Fix applied in rev.51744. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-26 13:45 Message: Logged In: YES user_id=11375 Tested patch attached. I want to get the go-ahead from the release manager before committing this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525469&group_id=5470 From noreply at sourceforge.net Tue Sep 5 15:19:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 06:19:39 -0700 Subject: [ python-Bugs-1526834 ] unbalanced parentheses from command line crash pdb Message-ID: Bugs item #1526834, was opened at 2006-07-22 00:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: A.M. Kuchling (akuchling) Summary: unbalanced parentheses from command line crash pdb Initial Comment: bagira:~/python-svn/patches> cat simple print 123 bagira:~/python-svn/patches> ../python/trunk/python -m pdb simple (Pdb) b f( #crashes your program Traceback (most recent call last): ... File "/home/ilya/python-svn/python/trunk/Lib/sre.py", line 233, in _compile raise error, v # invalid expression error: unbalanced parenthesis Uncaught exception. Entering post mortem debugging (Pdb) b f( # doing it post-mortem fully crashes pdb Traceback (most recent call last): .. raise error, v # invalid expression sre_constants.error: unbalanced parenthesis bagira:~/python-svn/patches> ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-05 09:19 Message: Logged In: YES user_id=11375 Fix applied in rev. 51745. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-08-06 15:41 Message: Logged In: YES user_id=971153 I don't think supporting "b f()" is needed... And as a catch-all argument, gdb does not support "b f()" either ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-27 08:38 Message: Logged In: YES user_id=11375 Easily fixed by adding a re.escape() call, but this means that 'b f()', if you've been doing that, will no longer work to set a breakpoint. The documentation doesn't claim that 'b f()' should work, but people may be used to typing this. I've asked the 2.5 release manager about this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470 From noreply at sourceforge.net Tue Sep 5 16:14:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 07:14:20 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 11:05 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: 9 Submitted By: ganges master (gangesmaster) >Assigned to: Neal Norwitz (nnorwitz) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-09-05 16:14 Message: Logged In: YES user_id=34209 I prefer ValueError over ImportError as the problem is in the code doing the import, not in a missing module. I don't have a strong feeling either way, though. The new messages seem better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 03:26 Message: Logged In: YES user_id=33168 Thomas, could you take a look at this patch. I'm not sure it's correct. I thought you had some reasons for these ValueErrors (unless it was diff code). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-03 09:10 Message: Logged In: YES user_id=849994 See attached patch. I couldn't find a mention of this ValueError in the PEP or the docs, so changing it to ImportError and giving better error messages looks like the way to go. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 20:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 11:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Tue Sep 5 16:42:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 07:42:57 -0700 Subject: [ python-Bugs-1552726 ] Python polls unecessarily every 0.1 when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 14: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=1552726&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 Submitted By: Richard Boulton (richardb) Assigned to: Nobody/Anonymous (nobody) Summary: Python polls unecessarily every 0.1 when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Tue Sep 5 16:43:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 07:43:46 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 14:42 Message generated for change (Settings changed) made by richardb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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 Submitted By: Richard Boulton (richardb) Assigned to: Nobody/Anonymous (nobody) >Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Tue Sep 5 17:07:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 08:07:17 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 14:02 Message generated for change (Comment added) made by cspence You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Clay Spence (cspence) Date: 2006-09-05 11:07 Message: Logged In: YES user_id=685289 This is my fault. I found some old db headers in the include directory inside my home directory. I assume they were causing problems, since deleting them seems to have fixed the problem, at least now the test passes. I apologize for wasting people's time. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-09-03 19:41 Message: Logged In: YES user_id=413 i was unable to reproduce this problem on either 32-bit or 64-bit CentOS 4. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-09-03 19:14 Message: Logged In: YES user_id=413 weird i would not expect this to happen regardless of berkeleydb version. can you also do a 'ldd' on the _bsddb.so binary that your python build produced? presumably libdb42.so or something similar should be in the output. also, when to compile python does it print out a message saying what version of the include files and libs it thinks its compiling and linking with? it looks like you're using rhel4 or centos4; i'll try compiling 2.5rc1 on that myself when i get a chance. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 09:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-08-22 09:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 19:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Tue Sep 5 19:17:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 10:17:53 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Settings changed) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Tue Sep 5 20:22:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 11:22:23 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&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: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-09-05 11:22 Message: Logged In: YES user_id=357491 This is because exceptions now define a proper __unicode__() method in the PyMethodDef array. This is what gets called and it requires an exception instance. Before it just fell through to the tp_str slot and that didn't complain. Unless some knows a better way (short of defining a tp_unicode slot), the only way to make this work would be to rip out the __unicode__() method. This would then require the function in the tp_str slot to have to detect if its arguments need to be Unicode or not (and I don't know how to do that off the top of my head; is their a PyUnicode_Check()?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Tue Sep 5 20:29:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 11:29:57 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Invalid Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-09-05 11:29 Message: Logged In: YES user_id=413 ok good, thats pretty much what i figured was happening (header files not matching the library version). closing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-09-05 08:07 Message: Logged In: YES user_id=685289 This is my fault. I found some old db headers in the include directory inside my home directory. I assume they were causing problems, since deleting them seems to have fixed the problem, at least now the test passes. I apologize for wasting people's time. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-09-03 16:41 Message: Logged In: YES user_id=413 i was unable to reproduce this problem on either 32-bit or 64-bit CentOS 4. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-09-03 16:14 Message: Logged In: YES user_id=413 weird i would not expect this to happen regardless of berkeleydb version. can you also do a 'ldd' on the _bsddb.so binary that your python build produced? presumably libdb42.so or something similar should be in the output. also, when to compile python does it print out a message saying what version of the include files and libs it thinks its compiling and linking with? it looks like you're using rhel4 or centos4; i'll try compiling 2.5rc1 on that myself when i get a chance. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 06:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-08-22 06:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Tue Sep 5 20:35:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 11:35:32 -0700 Subject: [ python-Bugs-1552892 ] ConfigParser converts option names to lower case on set() Message-ID: Bugs item #1552892, was opened at 2006-09-05 11:35 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=1552892&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.4 Status: Open Resolution: None Priority: 5 Submitted By: daniel (suslik) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser converts option names to lower case on set() Initial Comment: Python 2.4.2 Using set() in ConfigParser module converts all characters in option names to lower case. To reproduce: >>> import ConfigParser >>> cfg = ConfigParser.ConfigParser() >>> cfg.add_section('SectioN') >>> cfg.set('SectioN','OpTiOn","ValuE') >>> cfg.items('SectioN') [('option', 'ValuE')] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470 From noreply at sourceforge.net Tue Sep 5 21:37:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 12:37:30 -0700 Subject: [ python-Bugs-1552935 ] Pythonw doesn't get rebuilt if version number changes Message-ID: Bugs item #1552935, was opened at 2006-09-05 21:37 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=1552935&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: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Pythonw doesn't get rebuilt if version number changes Initial Comment: If the Python version number changes (as it did this week) Mac/pythonw should get rebuilt so it fires up the correct real Python executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&group_id=5470 From noreply at sourceforge.net Tue Sep 5 23:04:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 14:04:17 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-17 03:51 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: 9 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:04 Message: Logged In: YES user_id=1426755 I've been testing quiver's test case: - With Eclipse's QuickREx plugin: it hangs. It was configured in PCRE mode (which uses Jakarta-ORO Perl 5 regular expressions implementation), and no additional options. - With grep: grep exits with a fatal error and dumps a stack trace. grep was run also in Perl mode, with the command: grep -P -f regexp.txt test.txt I can't find an explanation for this, but I don't know much about regexps. I hope it has some utility for the resolution of this bug nevertheless. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-08-18 06:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Tue Sep 5 23:24:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 14:24:47 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-17 03:51 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: 9 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:24 Message: Logged In: YES user_id=1426755 Again FYI, here's the diff where presumably the bug was introduced: http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47080&r1=46996&r2=47080 ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:04 Message: Logged In: YES user_id=1426755 I've been testing quiver's test case: - With Eclipse's QuickREx plugin: it hangs. It was configured in PCRE mode (which uses Jakarta-ORO Perl 5 regular expressions implementation), and no additional options. - With grep: grep exits with a fatal error and dumps a stack trace. grep was run also in Perl mode, with the command: grep -P -f regexp.txt test.txt I can't find an explanation for this, but I don't know much about regexps. I hope it has some utility for the resolution of this bug nevertheless. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-08-18 06:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Tue Sep 5 23:40:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 14:40:05 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-17 03:51 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: 9 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:40 Message: Logged In: YES user_id=1426755 Sorry, correct URL is http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47154&r1=47080&r2=47154 ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:24 Message: Logged In: YES user_id=1426755 Again FYI, here's the diff where presumably the bug was introduced: http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47080&r1=46996&r2=47080 ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 23:04 Message: Logged In: YES user_id=1426755 I've been testing quiver's test case: - With Eclipse's QuickREx plugin: it hangs. It was configured in PCRE mode (which uses Jakarta-ORO Perl 5 regular expressions implementation), and no additional options. - With grep: grep exits with a fatal error and dumps a stack trace. grep was run also in Perl mode, with the command: grep -P -f regexp.txt test.txt I can't find an explanation for this, but I don't know much about regexps. I hope it has some utility for the resolution of this bug nevertheless. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-08-18 06:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Wed Sep 6 00:08:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 15:08:15 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 14:24 Message generated for change (Comment added) made by qrczak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&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: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- >Comment By: Marcin 'Qrczak' Kowalczyk (qrczak) Date: 2006-09-06 00:08 Message: Logged In: YES user_id=50234 I think the way which is consistent with the current Python implementation is adding the tp_unicode slot. (Parenthetical remark. In the binding between Python and my language Kogut I'm exposing various standard APIs between the two languages automatically. And __unicode__ happened to be the *only* method which I needed to treat specially by tp_getattro. It's the only method I've encountered so far which is called by Python on lots of "ordinary" objects, and which doesn't have a C slot (and the consequence is that my default wrapper shouldn't forward it to the __unicode__ attribute in the other language, but to the appropriate API of the other language which obtains a Unicode rendition). This was a different issue than the topic of this bug, was solvable, but it was another suggestion that the way of handling __unicode__ is inconsistent with other *similar* attributes, similar in the sense of the amount of "genericity" and "magicness", and should have a C slot. The present problem is somewhat dual: now it's me who calls __unicode__ (even if indirectly), and it's Python who provides __unicode__ implementation of its objects. End of parenthetical remark.) Anyway, I'm afraid the issue is a symptom of a deeper problem. I was some time ago wondering how does Python distinguish whether x.foo, when x happens to be a class object (or type object), is meant to be an unbound method to be called with instances of that class, or a bound method to operate on the class object itself. It seems that Python doesn't attempt to use the second interpretation at all. Despite this, various standard operations are dressed in magic methods with names surrounded by double underscores do work for class objects! And while str(x) is the same as x.__str__() for most objects, it's not true for class objects and type objects: str(x) goes through the C slot while x.__str__() doesn't work. The set of methods which have C slots would seem to be just a shortcut for performance, but actually it has a semantic significance. Namely class objects and type objects can have specialized implementations of those methods, but not of ordinary methods. Fortunately it doesn't matter much in practice because the set of methods supported by class objects is fixed, and it just happens to be the subset of the methods with C slots. Unless some other objects can play the role of classes, and then the problem might reappear; I'm completely ignorant about Python metaclasses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-09-05 20:22 Message: Logged In: YES user_id=357491 This is because exceptions now define a proper __unicode__() method in the PyMethodDef array. This is what gets called and it requires an exception instance. Before it just fell through to the tp_str slot and that didn't complain. Unless some knows a better way (short of defining a tp_unicode slot), the only way to make this work would be to rip out the __unicode__() method. This would then require the function in the tp_str slot to have to detect if its arguments need to be Unicode or not (and I don't know how to do that off the top of my head; is their a PyUnicode_Check()?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Wed Sep 6 03:44:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 18:44:50 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 04:06:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 19:06:15 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 04:34:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 19:34:35 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 09:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 19:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-05 19:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-05 18:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-15 21:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-15 21:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 05:30:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 20:30:06 -0700 Subject: [ python-Bugs-1552892 ] ConfigParser converts option names to lower case on set() Message-ID: Bugs item #1552892, was opened at 2006-09-05 13:35 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&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.4 Status: Open Resolution: None Priority: 5 Submitted By: daniel (suslik) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser converts option names to lower case on set() Initial Comment: Python 2.4.2 Using set() in ConfigParser module converts all characters in option names to lower case. To reproduce: >>> import ConfigParser >>> cfg = ConfigParser.ConfigParser() >>> cfg.add_section('SectioN') >>> cfg.set('SectioN','OpTiOn","ValuE') >>> cfg.items('SectioN') [('option', 'ValuE')] ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-09-05 22:30 Message: Logged In: YES user_id=1591633 I can reproduce this on Win XP, Python 2.4, however, it doesn't seem to be a bug. In the docs (http://docs.python.org/lib/module-ConfigParser.html), it states that "All option names used in interpolation will be passed through the optionxform() method just like any other option name reference. For example, using the default implementation of optionxform() (which converts option names to lower case), the values "foo %(bar)s" and "foo %(BAR)s" are equivalent." You might consider subclassing if this is an inconvenience for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470 From noreply at sourceforge.net Wed Sep 6 05:59:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 20:59:34 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 09:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 20:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 19:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-05 19:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-05 18:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-15 21:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-15 21:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 06:59:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 21:59:55 -0700 Subject: [ python-Bugs-1553166 ] python 2.5 install can't find tcl/tk in /usr/lib64 Message-ID: Bugs item #1553166, was opened at 2006-09-06 00:59 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=1553166&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Strozzi (dstrozzi) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 install can't find tcl/tk in /usr/lib64 Initial Comment: Hi, I'm trying to compile python 2.5 RC1 under opensuse 10.1 on a 64-bit AMD athlon. Although the README says it will auto-detect tcl/tk, and setup tkinter appropriately, it doesn't. Among other things, this means idle can't use this python version. I have tcl/tk, the libraries, devel packages, anything that seemed relevant in YaST installed. I think the problem is my tcl/tk libs live in /usr/lib64. It seems, based on the file Modules/Setup generated by ./configure, that the python installer doesn't see these libs. >From perusing the web there seems to be a fair amount of pain caused by /lib vs /lib64 dir names. In fact an older post to the forum identifies the same issue (just search for lib64 if this link is busted): http://sourceforge.net/tracker/index.php?func=detail&aid=1294959&group_id=5470&atid=105470 It would be very nice if this were somehow handled automatically, or at least give detailed instructions in the README (search the doc for lib64 returns nothing). Cheers, David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553166&group_id=5470 From noreply at sourceforge.net Wed Sep 6 07:53:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 22:53:02 -0700 Subject: [ python-Bugs-1552892 ] ConfigParser converts option names to lower case on set() Message-ID: Bugs item #1552892, was opened at 2006-09-05 18:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: daniel (suslik) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser converts option names to lower case on set() Initial Comment: Python 2.4.2 Using set() in ConfigParser module converts all characters in option names to lower case. To reproduce: >>> import ConfigParser >>> cfg = ConfigParser.ConfigParser() >>> cfg.add_section('SectioN') >>> cfg.set('SectioN','OpTiOn","ValuE') >>> cfg.items('SectioN') [('option', 'ValuE')] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 05:53 Message: Logged In: YES user_id=849994 Mark is correct. This is not a bug. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-09-06 03:30 Message: Logged In: YES user_id=1591633 I can reproduce this on Win XP, Python 2.4, however, it doesn't seem to be a bug. In the docs (http://docs.python.org/lib/module-ConfigParser.html), it states that "All option names used in interpolation will be passed through the optionxform() method just like any other option name reference. For example, using the default implementation of optionxform() (which converts option names to lower case), the values "foo %(bar)s" and "foo %(BAR)s" are equivalent." You might consider subclassing if this is an inconvenience for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470 From noreply at sourceforge.net Wed Sep 6 07:57:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 22:57:51 -0700 Subject: [ python-Bugs-1551669 ] Wrong link to unicode database Message-ID: Bugs item #1551669, was opened at 2006-09-03 23:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&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: Out of Date Priority: 5 Submitted By: Yevgen Muntyan (emuntyan) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong link to unicode database Initial Comment: http://docs.python.org/lib/module-unicodedata.html has a link to unicode database (second paragraph). The link there is http://www.unicode.org/Public/UNIDATA/UnicodeData.html, it's broken. The correct one is probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt (there are lot of files in http://www.unicode.org/Public/UNIDATA/) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 05:57 Message: Logged In: YES user_id=849994 The links are actually already updated in SVN. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-04 12:30 Message: Logged In: YES user_id=38388 I think the documentation should link to the new standard URL: http://www.unicode.org/Public/UNIDATA/UCD.html and then point out that Python 2.4 shipped with version 3.2 and Python 2.5 will ship with 4.1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-09-04 05:14 Message: Logged In: YES user_id=671362 Given that Python 2.4 uses 3.2 database, we should link to http://www.unicode.org/Public/3.2-Update/UnicodeCharacterDatabase-3.2.0.html As for 2.5 and trunk(both using 4.1.0 database), they're linked to http://www.unicode.org/Public/4.1.0/ucd/UCD.html Any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:04:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:04:23 -0700 Subject: [ python-Bugs-1551427 ] tiny bug in win32_urandom Message-ID: Bugs item #1551427, was opened at 2006-09-03 12:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551427&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rocco Matano (rocco_m) Assigned to: Nobody/Anonymous (nobody) Summary: tiny bug in win32_urandom Initial Comment: In the file ...\Python-2.4.3\Modules\posixmodule.c the function win32_urandom tries to get the addresses of the functions 'CryptAcquireContextA' and 'CryptGenRandom' like this: pCryptAcquireContext=(CRYPTACQUIRECONTEXTA)GetProcAddress( hAdvAPI32, "CryptAcquireContextA"); if (pCryptAcquireContext == NULL) return PyErr_Format(PyExc_NotImplementedError, "CryptAcquireContextA not found"); pCryptGenRandom = (CRYPTGENRANDOM)GetProcAddress( hAdvAPI32, "CryptGenRandom"); if (pCryptAcquireContext == NULL) /* <- test pCryptGenRandom instead */ return PyErr_Format(PyExc_NotImplementedError, "CryptGenRandom not found"); After the second call to GetProcAddress() pCryptGenRandom should be tested against NULL. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:04 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 51762, 51763 (2.4), 51764 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551427&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:09:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:09:55 -0700 Subject: [ python-Bugs-1550938 ] from . import bug Message-ID: Bugs item #1550938, was opened at 2006-09-02 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&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: Fixed Priority: 9 Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:09 Message: Logged In: YES user_id=849994 Agreed. Only changed the messages in rev. 51765, 51766 (2.5). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-09-05 14:14 Message: Logged In: YES user_id=34209 I prefer ValueError over ImportError as the problem is in the code doing the import, not in a missing module. I don't have a strong feeling either way, though. The new messages seem better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 01:26 Message: Logged In: YES user_id=33168 Thomas, could you take a look at this patch. I'm not sure it's correct. I thought you had some reasons for these ValueErrors (unless it was diff code). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-03 07:10 Message: Logged In: YES user_id=849994 See attached patch. I couldn't find a mention of this ValueError in the PEP or the docs, so changing it to ImportError and giving better error messages looks like the way to go. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 18:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 09:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:12:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:12:56 -0700 Subject: [ python-Bugs-1550559 ] SWIG wrappers incompatible with 2.5c1 Message-ID: Bugs item #1550559, was opened at 2006-09-01 14:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550559&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andrew Gregory (andrew22) Assigned to: Nobody/Anonymous (nobody) Summary: SWIG wrappers incompatible with 2.5c1 Initial Comment: Can now no longer compile SWIG wrappers following upgrade to Python 2.5c1 - presumably as a result of changes in Python.h. Used MinGW compilers (3.2.3 and 3.4.2) on Windows XP. See http://groups.google.co.uk/group/comp.lang.python/brows e_thread/thread/7a44c95f6aa68ef8/3e7e1e2d2cce56ed? lnk=gst&q=gregory&rnum=3#3e7e1e2d2cce56ed ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:12 Message: Logged In: YES user_id=849994 The ml_doc member of PyMethodObject structures is now declared as const char *, which is correct. SWIG will have to adapt to this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550559&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:17:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:17:04 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 20:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: Rejected Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:17 Message: Logged In: YES user_id=849994 Looking at all those efforts to remove str.find(), I think this is not going to happen. The sequence API is already rich enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 19:07 Message: Logged In: YES user_id=341410 Lists have an .index(obj[, start[, stop]]) method that tells you the index of the first object that matches obj, raising an exception otherwise. Generally speaking, you can get better performance for repeated searches by... dct = {} for i,(k,v) in enumerate(lst): dct.setdefault(k, []).append(i) Then to find the first index... dct.get(k, [None])[0] Suggested close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:18:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:18:44 -0700 Subject: [ python-Bugs-1548288 ] sgmllib.sgmlparser is not thread safe Message-ID: Bugs item #1548288, was opened at 2006-08-29 02:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andres Riancho (andresriancho) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.sgmlparser is not thread safe Initial Comment: Python version: =============== dz0 at fre3ak:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Problem description: ==================== sgmlparser is not thread safe, i discovered this problem when trying to fetch and parse many html files at the same time. An example of this bug can be found attached. The sgmlparser input html is this string: ''*100 , this was written this way to simplify the code, please note that if you replace this string with a "large" html document, it will also fail. solution: ========= make the lib thread safe, or add some lines to the documentation saying that it aint thread safe. Traceback: ========== python sgml-not-threadSafe.py Started all threads Successfully parsed html Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "sgml-not-threadSafe.py", line 10, in parseHtml self._parser.feed( html ) File "/usr/lib/python2.4/sgmllib.py", line 95, in feed self.goahead(0) File "/usr/lib/python2.4/sgmllib.py", line 129, in goahead k = self.parse_starttag(i) File "/usr/lib/python2.4/sgmllib.py", line 262, in parse_starttag self.error('unexpected call to parse_starttag') File "/usr/lib/python2.4/sgmllib.py", line 102, in error raise SGMLParseError(message) SGMLParseError: unexpected call to parse_starttag Successfully parsed html Successfully parsed html Additional note =============== To recreate this bug, you should run the sample code more than one time. Thread handling aint always the same, the issue is there but sometimes it fails to appear on the first (second, third...) run. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:18 Message: Logged In: YES user_id=849994 I agree with Josiah. Each thread will have to use its own HTMLParser instance. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 19:02 Message: Logged In: YES user_id=341410 The sgmllib makes no claims as to thread safety, which implies that it is generally not sharable between threads. You can work around this issue by creating a new parser instance for each thread that you want to parse. Suggested close as "Wont Fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:22:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:22:06 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 07:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:22 Message: Logged In: YES user_id=849994 You could go another way and check/cleanup the cache on each call to filterwarning(). ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 17:19 Message: Logged In: YES user_id=771074 Without the cache, the only filters you could possibly implement would be 'error' and 'ignore'. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-09-01 10:44 Message: Logged In: YES user_id=857292 The whole point of that cache is to not go through the list of filters if the warning is in the cache. Why would you keep the cache around if you search through the filters in every case anyway? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 04:38 Message: Logged In: YES user_id=771074 It might be simpler to check if the warning is in the line cache after the disposition is determined from the filters. In the case of 'always' and 'error', there's no need to check the cache at all. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 20:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:50:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:50:39 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&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: Fixed Priority: 7 Submitted By: ?iga Seilnacht (zseil) Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:50 Message: Logged In: YES user_id=849994 I have now committed the patch. I couldn't whip up a test, however, that would have been triggered in some way. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 06:09 Message: Logged In: YES user_id=33168 Yeah, this makes sense. Georg, can you come up with a test for this? (It's ok if it's only triggered with -R flag.) This also needs a NEWS entry. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 05:22 Message: Logged In: YES user_id=849994 Attaching my patch here. Neal: PyObject_GC_TRACK is called in PyType_GenericAlloc, which is used for exceptions since the tp_alloc slot is 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Wed Sep 6 11:10:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 02:10:09 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 22:47 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: Rejected Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- >Comment By: kovan (kovan) Date: 2006-09-06 11:10 Message: Logged In: YES user_id=1426755 It's not about performance, it's about code readability and simplicity for such a common operation. The index() method is useless here because, as I explained, it's not a search by value. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 08:17 Message: Logged In: YES user_id=849994 Looking at all those efforts to remove str.find(), I think this is not going to happen. The sequence API is already rich enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 21:07 Message: Logged In: YES user_id=341410 Lists have an .index(obj[, start[, stop]]) method that tells you the index of the first object that matches obj, raising an exception otherwise. Generally speaking, you can get better performance for repeated searches by... dct = {} for i,(k,v) in enumerate(lst): dct.setdefault(k, []).append(i) Then to find the first index... dct.get(k, [None])[0] Suggested close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Wed Sep 6 11:18:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 02:18:33 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 20:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: Rejected Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 09:18 Message: Logged In: YES user_id=849994 What should find() return if nothing is found? It can't return None since that can be a valid item, so it has to raise an exception. Therefore, try: item = items.find(lambda x: x.key == value) except WhateverError: handle is not much shorter than try: item = (x for x in items if x.key == value).next() except StopIteration: handle ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-06 09:10 Message: Logged In: YES user_id=1426755 It's not about performance, it's about code readability and simplicity for such a common operation. The index() method is useless here because, as I explained, it's not a search by value. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:17 Message: Logged In: YES user_id=849994 Looking at all those efforts to remove str.find(), I think this is not going to happen. The sequence API is already rich enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 19:07 Message: Logged In: YES user_id=341410 Lists have an .index(obj[, start[, stop]]) method that tells you the index of the first object that matches obj, raising an exception otherwise. Generally speaking, you can get better performance for repeated searches by... dct = {} for i,(k,v) in enumerate(lst): dct.setdefault(k, []).append(i) Then to find the first index... dct.get(k, [None])[0] Suggested close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Wed Sep 6 11:25:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 02:25:59 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 22:47 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: Rejected Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- >Comment By: kovan (kovan) Date: 2006-09-06 11:25 Message: Logged In: YES user_id=1426755 Oh OK, I hadn't thought about the fact that None can be a valid item in the sequence. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 11:18 Message: Logged In: YES user_id=849994 What should find() return if nothing is found? It can't return None since that can be a valid item, so it has to raise an exception. Therefore, try: item = items.find(lambda x: x.key == value) except WhateverError: handle is not much shorter than try: item = (x for x in items if x.key == value).next() except StopIteration: handle ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-06 11:10 Message: Logged In: YES user_id=1426755 It's not about performance, it's about code readability and simplicity for such a common operation. The index() method is useless here because, as I explained, it's not a search by value. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 08:17 Message: Logged In: YES user_id=849994 Looking at all those efforts to remove str.find(), I think this is not going to happen. The sequence API is already rich enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-03 21:07 Message: Logged In: YES user_id=341410 Lists have an .index(obj[, start[, stop]]) method that tells you the index of the first object that matches obj, raising an exception otherwise. Generally speaking, you can get better performance for repeated searches by... dct = {} for i,(k,v) in enumerate(lst): dct.setdefault(k, []).append(i) Then to find the first index... dct.get(k, [None])[0] Suggested close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Wed Sep 6 12:52:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 03:52:58 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 02:27 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-09-06 05:52 Message: Logged In: YES user_id=771074 That depends on how it's expected to behave when switching back to a filter that actually needs to check the cache. Should 'once' mean only one time ever, or should it print the warning again after the filters are modified ? If the cache is cleaned up, there's no way to know if the warning was issued prior to the modification. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 01:22 Message: Logged In: YES user_id=849994 You could go another way and check/cleanup the cache on each call to filterwarning(). ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 12:19 Message: Logged In: YES user_id=771074 Without the cache, the only filters you could possibly implement would be 'error' and 'ignore'. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-09-01 05:44 Message: Logged In: YES user_id=857292 The whole point of that cache is to not go through the list of filters if the warning is in the cache. Why would you keep the cache around if you search through the filters in every case anyway? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-31 23:38 Message: Logged In: YES user_id=771074 It might be simpler to check if the warning is in the line cache after the disposition is determined from the filters. In the case of 'always' and 'error', there's no need to check the cache at all. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 15:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:48:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:48:55 -0700 Subject: [ python-Feature Requests-1553375 ] Add traceback.print_full_exception() Message-ID: Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:48:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:48:54 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:52:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:52:46 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:57:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:57:16 -0700 Subject: [ python-Feature Requests-1553380 ] Print full exceptions as they occur in logging Message-ID: Feature Requests item #1553380, was opened at 2006-09-06 12:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Print full exceptions as they occur in logging Initial Comment: Sometimes exceptions occur when using logging that are caused by the user code. However, logging catches these exceptions and does not give a clue as to where the error occurred. Printing full exceptions as suggested in RFE http://www.python.org/sf/1553375 would be a big help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:57:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:57:44 -0700 Subject: [ python-Feature Requests-1553380 ] Print full exceptions as they occur in logging Message-ID: Feature Requests item #1553380, was opened at 2006-09-06 12:57 Message generated for change (Settings changed) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Vinay Sajip (vsajip) Summary: Print full exceptions as they occur in logging Initial Comment: Sometimes exceptions occur when using logging that are caused by the user code. However, logging catches these exceptions and does not give a clue as to where the error occurred. Printing full exceptions as suggested in RFE http://www.python.org/sf/1553375 would be a big help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:59:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:59:26 -0700 Subject: [ python-Feature Requests-1553375 ] Add traceback.print_full_exception() Message-ID: Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 12:59 Message: Logged In: YES user_id=987664 Hmmm, my indentation didn't work very well. Hopefully you should be able to figure it out though. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 From noreply at sourceforge.net Wed Sep 6 15:04:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 06:04:34 -0700 Subject: [ python-Feature Requests-1553375 ] Add traceback.print_full_exception() Message-ID: Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 13:04 Message: Logged In: YES user_id=987664 Here's some test code that might indicate how this is useful: def x(n=0): .....try: ..........y(n+1) .....except: ..........ei = sys.exc_info() ..........print_full_exception(ei[0], ei[1], ei[2], sys.stderr) def y(n): .....if n > 10: ..........raise IOError, "test" ..... .....x(n+1) x() ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 12:59 Message: Logged In: YES user_id=987664 Hmmm, my indentation didn't work very well. Hopefully you should be able to figure it out though. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 From noreply at sourceforge.net Wed Sep 6 18:03:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 09:03:48 -0700 Subject: [ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode Message-ID: Bugs item #1553496, was opened at 2006-09-06 11:03 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=1553496&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 Submitted By: Walker Hale (walkerh) Assigned to: Nobody/Anonymous (nobody) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 From noreply at sourceforge.net Wed Sep 6 19:32:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 10:32:14 -0700 Subject: [ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode Message-ID: Bugs item #1553496, was opened at 2006-09-06 12:03 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&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 Submitted By: Walker Hale (walkerh) >Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 From noreply at sourceforge.net Wed Sep 6 19:38:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 10:38:33 -0700 Subject: [ python-Bugs-1544295 ] Fix Lib/test/test___all__.py Message-ID: Bugs item #1544295, was opened at 2006-08-21 20:12 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&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: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Lib/test/test___all__.py Initial Comment: There's a comment saying: # In case _socket fails to build, make this test fail more gracefully # than an AttributeError somewhere deep in CGIHTTPServer. The proposed fix is attached. Applies to revision 51453. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-06 13:38 Message: Logged In: YES user_id=11375 Please explain more clearly what the problem is. Does the existing code not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 From noreply at sourceforge.net Wed Sep 6 20:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 11:11:14 -0700 Subject: [ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo Message-ID: Bugs item #1553577, was opened at 2006-09-06 13:11 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=1553577&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: When using the pytz package (http://pytz.sf.net/) to create timezone info objects datetime.datetime.now() behaves differently than the regular datetime.datetime() contstructor. Here's an example: >>> import pytz >>> info = pytz.timezone("US/Central") >>> info >>> import datetime >>> now = datetime.datetime.now(tz=info) >>> now datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=info) >>> t2 datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info True It appears that datetime.datetime.now() makes an off-by-one-hour copy of the timezone info it was passed. I've reproduced this on 2.4.3 and 2.5c1 as of August 17. (It's also a little annoying that the timezone arg for datetime.datetime.now() is "tz" while the timezone arg for datetime.datetime() is "tzinfo". Is there a good reason for them to be different?) Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 From noreply at sourceforge.net Wed Sep 6 22:49:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 13:49:47 -0700 Subject: [ python-Bugs-1496561 ] Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11 Message-ID: Bugs item #1496561, was opened at 2006-05-28 22:35 Message generated for change (Comment added) made by andyfloe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496561&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.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Andreas (andyfloe) Assigned to: Nobody/Anonymous (nobody) Summary: Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11 Initial Comment: If Python 2.4.3 is build on Solaris 9 or 10 with Sun Studio 11 [cc: Sun C 5.8 2005/10/13], some of the tests of roundup fail with a core dump of Python. If build with gcc [gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] all runs as expected. I have compiled Python and bsd 4.3 on Solaris with Sun Studio as follows: ##-- rebuild Berkeley DB version 4.3.29 URL='http://www.sleepycat.com' BUILDDIR=/builddir SRCDIR=/mnt/a VERSION=4.3.29 PKG=db STAR="${PKG}"-"${VERSION}".tar.gz cd "$BUILDDIR" gunzip -d -c "${SRCDIR}"/"${STAR}" | tar xvf - cd "${PKG}-${VERSION}" PREFIX=/opt/db4 CC=cc; export CC CXX=CC; export CXX PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/sbin:/usr/bin; export PATH unset LD_LIBRARY_PATH TIMESTAMP=`date +%Y%m%d%H%M%S` cd build_unix ../dist/configure --prefix="${PREFIX}" \ --enable-compat185 --disable-dump185 \ --enable-shared --enable-static --enable-cxx 2>&1 | \ tee /var/tmp/"${PKG}-${VERSION}"_configure_${TIMESTAMP} make 2>&1 | tee /var/tmp/"${PKG}-${VERSION}"_make_${TIMESTAMP} ##- install ## done as user 'root' #- source the above environment variables cd "$BUILDDIR"/"${PKG}"-"${VERSION}"/build_unix make install 2>&1 | \ tee /var/tmp/"${PKG}-${VERSION}"_make_install_`date '+%Y%m%d%H%M%S'` cd .. LIBS=' /opt/db4/lib/libdb-4.3.so /opt/db4/lib/libdb-4.3.la /opt/db4/lib/libdb_cxx-4.3.so /opt/db4/lib/libdb_cxx-4.3.la /opt/db4/lib/libdb-4.3.a /opt/db4/lib/libdb.a /opt/db4/lib/libdb_cxx-4.3.a /opt/db4/lib/libdb_cxx.a /opt/db4/lib/libdb_cxx.so ' ls -l $LIBS chown root:root $LIBS chmod 755 $LIBS cd /usr/include ## the setup.py script in the Python source only looks for specific ## locations for the header file for the bsddb ln -s /opt/db4/include /usr/include/db4 # chmod 755 /usr/lib/libdb*.so ##- installing Python 2.4.3 BUILDDIR=/builddir SRCDIR=/mnt/a VERSION=2.4.3 STAR=Python-2.4.3.tar.bz2 PKG=`echo $STAR | sed -e 's@\.tar\.gz@@' -e 's@\.tgz@@' -e 's@\.tar\.bz2@@' ` CC=cc; export CC CXX=CC; export CXX PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/bin/:/opt/db4/bin:/sbin/bin; export PATH LDFLAGS='-R/opt/db4/lib -L/opt/db4/lib'; export LDFLAGS CPPFLAGS='-I/opt/db4/include'; export CPPFLAGS cd $BUILDDIR bunzip2 -c $SRCDIR/$STAR | /usr/sfw/bin/gtar -xvf - cd "$PKG" patch -p0 < /mnt/a/python_curses_1471938.patch ./configure --prefix=/usr --without-gcc \ | tee /var/tmp/"${PKG}"-"$VERSION"_configure_`date '+%Y%m%d%H%M%S'` make | tee /var/tmp/"${PKG}"-"$VERSION"_make_`date '+%Y%m%d%H%M%S'` make test | tee /var/tmp/"${PKG}"-"$VERSION"_make_test_`date '+%Y%m%d%H%M%S'` # done as user 'root' cd $BUILDDIR/"$PKG" make install | tee /var/tmp/"${PKG}"-"$VERSION"_make_install_`date '+%Y%m%d%H%M%S'` All Python 2.4.3 test run OK, see 256 tests OK. CAUTION: stdout isn't compared in verbose mode: a test that passes in verbose mode may fail without it. 1 test failed: test_nis 34 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_tcl test_timeout test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound 2 skips unexpected on sunos5: test_tcl test_locale If running the tests of the software package roundup 1.1.2 if reveive a core dump from the Python interpreter. -bash-3.00$ python ./run_tests.py Running unit tests at level 1 Running unit tests from /export/home/builddir/roundup-1.1.2/. Including anydbm tests Skipping metakit tests Skipping mysql tests Skipping postgresql tests Including sqlite tests Skipping tsearch2 tests testDontRetireAdminOrAnonymous (test.test_actions.RetireActionTestCase) ... ok testNoPermission (test.test_actions.RetireActionTestCase) ... ok testRetireAction (test.test_actions.RetireActionTestCase) ... ok testNoPermission (test.test_actions.StandardSearchActionTestCase) ... ok testQueryName (test.test_actions.StandardSearchActionTestCase) ... ok testEmptyKey (test.test_actions.FakeFilterVarsTestCase) ... ok testEmptyMultilink (test.test_actions.FakeFilterVarsTestCase) ... ok testNonEmptyMultilink (test.test_actions.FakeFilterVarsTestCase) ... ok testStandardKey (test.test_actions.FakeFilterVarsTestCase) ... ok testStringKey (test.test_actions.FakeFilterVarsTestCase) ... ok testTokenizedStringKey (test.test_actions.FakeFilterVarsTestCase) ... ok testShowAction (test.test_actions.ShowActionTestCase) ... ok testShowActionNoType (test.test_actions.ShowActionTestCase) ... ok testCollision (test.test_actions.CollisionDetectionTestCase) ... ok testLastNodeActivity (test.test_actions.CollisionDetectionTestCase) ... ok testLastUserActivity (test.test_actions.CollisionDetectionTestCase) ... ok testCorrectLogin (test.test_actions.LoginTestCase) ... ok testInvalidPassword (test.test_actions.LoginTestCase) ... ok testInvalidUsername (test.test_actions.LoginTestCase) ... ok testNoUsername (test.test_actions.LoginTestCase) ... ok testNoWebAccess (test.test_actions.LoginTestCase) ... ok testActorProperty (test.test_anydbm.anydbmDBTest) ... Segmentation Fault (core dumped) The Solaris 10 installation has been updated recently with smpatch. Richard Jones suggested, that this could be a Python build problem. Below you find the anydbm information. -bash-3.00$ uname -a SunOS sunny 5.10 Generic_118855-02 i86pc i386 i86pc -bash-3.00$ python Python 2.4.3 (#1, May 21 2006, 02:39:16) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import anydbm >>> anydbm._defaultmod All roundup tests fail with a core dump which are excluded by the following statement. -bash-3.00$ ./run_tests.py -vv test '!(testActorProperty|testAddProperty|testAddRemoveProperty|testCacheCreateSet|testCreatorProperty|testDateChange|testDateUnset|testDestroyJournalling|testEmptySet|testExceptions|testFileClassContentChange|testFileClassIndexingNoNoNo|testFileClassReindexing|testFilteringDateSort|testFilteringID|testFilteringIntervalSort|testFilteringLink|testFilteringMany|testFilteringMultilink|testFilteringNumber|testFilteringRange|testFilteringRetired|testFilteringString|testForcedReindexing|testIDGeneration|testIDSetting|testImportExport|testIndexerSearching|testIntervalChange|testIntervalUnset|testJournals|testLinkChange|testLinkUnset|testMultilinkChange|testPack|testReindexingChange|testReindexingClear|testRemoveProperty|testRetire|testSerialisation|testStringChange|testStringFind|testStringUnset|testTransactions|testEmptyStringSet|testSetString|test_basics|test_change|test_clear|testAlternateAddress|testCommandDelimiters|testContentDisposition|testEmailQuoting|testEmptyMessage|testEnc01|testFollowup|testInvalidClassLoose|testInvalidCommandPassthrough|testMultipartEnc01|testNewIssue|testNewUserAuthor|testNosyRemove|testResentFrom|testSimpleFollowup|testFindLink|testFindMultiMultilink|testFindMultilink|testFindMultipleLink|testFindRetired)' Running unit tests at level 1 Running unit tests from /export/home/builddir/roundup-1.1.2/. Including anydbm tests Skipping metakit tests Skipping mysql tests Skipping postgresql tests Including sqlite tests Skipping tsearch2 tests ... ---------------------------------------------------------------------- Ran 202 tests in 76.999s OK ---------------------------------------------------------------------- >Comment By: Andreas (andyfloe) Date: 2006-09-06 22:49 Message: Logged In: YES user_id=1292384 It is definitely a problem which occurs if the Xapian module is loaded into Python and both Python and Xapian is compiled with Sun Studio 11 (Sun C 5.8). Unfortunately there is no solution yet, see bug report on the Xapian tracker http://www.xapian.org/cgi-bin/bugzilla/show_bug.cgi?id=88 for details if you are interested in details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496561&group_id=5470 From noreply at sourceforge.net Thu Sep 7 02:50:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 17:50:02 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 00:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Thu Sep 7 05:26:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 20:26:04 -0700 Subject: [ python-Bugs-1553819 ] Class instance apparently not destructed when expected Message-ID: Bugs item #1553819, was opened at 2006-09-06 23:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 From noreply at sourceforge.net Thu Sep 7 09:08:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 00:08:28 -0700 Subject: [ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo Message-ID: Bugs item #1553577, was opened at 2006-09-06 11:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&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 Submitted By: Skip Montanaro (montanaro) >Assigned to: Tim Peters (tim_one) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: When using the pytz package (http://pytz.sf.net/) to create timezone info objects datetime.datetime.now() behaves differently than the regular datetime.datetime() contstructor. Here's an example: >>> import pytz >>> info = pytz.timezone("US/Central") >>> info >>> import datetime >>> now = datetime.datetime.now(tz=info) >>> now datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=info) >>> t2 datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info True It appears that datetime.datetime.now() makes an off-by-one-hour copy of the timezone info it was passed. I've reproduced this on 2.4.3 and 2.5c1 as of August 17. (It's also a little annoying that the timezone arg for datetime.datetime.now() is "tz" while the timezone arg for datetime.datetime() is "tzinfo". Is there a good reason for them to be different?) Skip ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:08 Message: Logged In: YES user_id=33168 Since Tim wrote this code AFAIK, there *had* to be a good reason. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 From noreply at sourceforge.net Thu Sep 7 09:19:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 00:19:57 -0700 Subject: [ python-Bugs-1553819 ] Class instance apparently not destructed when expected Message-ID: Bugs item #1553819, was opened at 2006-09-06 20:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 From noreply at sourceforge.net Thu Sep 7 15:24:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 06:24:32 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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 Submitted By: Richard Boulton (richardb) Assigned to: Nobody/Anonymous (nobody) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Thu Sep 7 15:37:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 06:37:20 -0700 Subject: [ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8 Message-ID: Bugs item #1324799, was opened at 2005-10-12 08:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: A.M. Kuchling (akuchling) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:37 Message: Logged In: YES user_id=11375 Committed in rev.50845, so this fix will be in Python 2.5. Closing this bug. If someone wants to submit a patch to use X/Open curses, please do. (I don't have a Solaris machine, so I can't assemble a patch myself.) ---------------------------------------------------------------------- Comment By: Tim Mooney (enchanter) Date: 2006-05-14 22:06 Message: Logged In: YES user_id=36222 First, your patch does fix the problem. Next, Solaris 8+ *does* have mvwgetnwstr, the problem is that it's in the X/Open version of the curses library, not the (old, stinky, backwards-compatible) default version of libcurses. Solaris 10's man pages do a much better job of explaining the differences, on 10 one can look at man -s 3xcurses libcurses vs. man libcurses If you want to compile and link against the X/Open version of the curses library, you need to have -I/usr/xpg4/include in CPPFLAGS and CFLAGS, and either -L/usr/xpg4/lib or -L/usr/xpg4/lib/64 (depending on whether you're compiling for ILP32 or LP64). /usr/xpg4/lib and /usr/xpg4/lib/64 are also not in the default loader search path, so you either need to modify the loader search path (man crle) or your also need a -R/usr/xpg4/lib or -R/usr/xpg4/lib/64 in LDFLAGS too. Because of the way the _cursesmodule is currently written, though, it assumes that if __sun is defined as a preprocessor symbol, STRICT_SYSV_CURSES should be defined, which actually causes problems if you try build with with newer X/Open curses. It should be possible to support building against either curses implementation on Solaris, but for now your patch at least makes _cursesmodule compile with the default version. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 09:45 Message: Logged In: YES user_id=11375 One use of mvwgetnwstr in the module is replaced by a manual emulation of the function, if STRICT_SYSV_CURSES is true, but another use isn't replaced; I suspect this is the problem. I've attached a patch that ensures that mvwgetnstr() is only used when STRICT_SYSV_CURSES is undefined. Please let me know if this fixes the compilation problem. ---------------------------------------------------------------------- Comment By: Nelson Arzola (narzola) Date: 2005-10-29 04:01 Message: Logged In: YES user_id=39023 I would like to add that this problem also exists under Solaris 2.10. For some reason, mvwgetnstr is not defined under Solaris 10. When I use nm to get the symbols out of /usr/lib/libcurses.so.1, I do not find it. When I replace the two references in /dsk/data0/build/Python-2.4.2/Modules/_cursesmodule.c from mvwgetnstr to mvwgetnwstr, I was able to compile the module and pass the appropriate tests. Since I don't use curses, I really don't have a good way to test this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 From noreply at sourceforge.net Thu Sep 7 15:41:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 06:41:02 -0700 Subject: [ python-Bugs-1542407 ] httplib reads one byte per system call Message-ID: Bugs item #1542407, was opened at 2006-08-18 00:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Zoyd Wheeler (zoyd2k) Assigned to: Nobody/Anonymous (nobody) Summary: httplib reads one byte per system call Initial Comment: The HTTPResponse class in httplib.py contains the following line in its __init__ method: self.fp = sock.makefile('rb', 0) The zero in that second (bufsize) argument overrides the default behavior of the socket filedescriptor in its readline() method, which is to read in a buffer's worth of data from the socket at a time and only hit the socket again if the buffer runs dry. When bufsize is set to zero, the filedescriptor sets its internal buffer size to one. As a result, readline() makes a system call for every byte of data consumed. Since httplib uses readline to obtain the http header, that's an awful lot of system calls. We noticed this when trying to build a fairly aggressive application on top of xmlrpclib (which relies on httplib); we saw tons of system call activity. There is no comment near this line of code to indicate whether this behavior is intended or not. If it is not intended, the patch is to simply remove the second argument and rely on the default (or allow the caller to specify a buffer size). In case reading a byte at a time is actually intended, we have a simple work-around for those who care to use it. In the python code that uses httplib, add the following: import httplib ... class HTTPResponse(httplib.HTTPResponse): def __init__(self, sock, **kw): httplib.HTTPResponse.__init__(self, sock, **kw) self.fp = sock.makefile('rb') httplib.HTTPConnection.response_class = HTTPResponse ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:41 Message: Logged In: YES user_id=11375 Also, I have a vague memory that httplib is used with pipelined HTTP requests. Buffering on the makefile() then causes problems because the stdio buffer can slurp up too much data, including portions of the next pipelined request. I think making buffering workable would require serious restructuring of the httplib code. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-27 13:44 Message: Logged In: YES user_id=341410 Because the socket is in blocking mode, performing self.fp.read(x) with an x > 1 will generally block until it has read x bytes or the other end disconnects. As such, I believe it is intended behavior. For your own application, you could perhaps write a response class that uses non-blocking sockets to handle readline, switching back to blocking sockets after header reading is over. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:02:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:02:27 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) >Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:06:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:06:51 -0700 Subject: [ python-Bugs-1554133 ] PyOS_InputHook() and related API funcs. not documented Message-ID: Bugs item #1554133, was opened at 2006-09-07 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=1554133&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: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook() and related API funcs. not documented Initial Comment: AFAICT, PyOS_InputHook() isn't described anywhere in the docs. Even the .h files don't contain comments explaining it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1554133&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:06:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:06:59 -0700 Subject: [ python-Bugs-1553819 ] Class instance apparently not destructed when expected Message-ID: Bugs item #1553819, was opened at 2006-09-07 04:26 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-09-07 15:06 Message: Logged In: YES user_id=6656 It's a reference cycle featuring an object with a __del__ --> it ends up in gc.garbage. More coffee for Neal? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 08:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:12:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:12:27 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 15:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Closed Resolution: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-09-07 15:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 15:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:17:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:17:34 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 10:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Thu Sep 7 16:38:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 07:38:24 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:38 Message: Logged In: YES user_id=11375 On looking at the readline code, I think this patch makes no difference to signals. The code in readline.c for the callbacks looks like this: has_input = 0; while (!has_input) { ... has_input = select.select(rl_input); } if (has_input > 0) {read character} elif (errno == EINTR) {check signals} So I think that, if a signal is delivered to a thread and select() in the main thread doesn't return EINTR, the old code is just as problematic as the code with this patch. The (while !has_input) loop doesn't check for signals at all as an exit condition. I'm not sure what to do at this point. I think the new code is no worse than the old code with regard to signals. Maybe this loop is buggy w.r.t. to signals, but I don't know how to test that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 10:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Thu Sep 7 19:11:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 10:11:53 -0700 Subject: [ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo Message-ID: Bugs item #1553577, was opened at 2006-09-06 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&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 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: When using the pytz package (http://pytz.sf.net/) to create timezone info objects datetime.datetime.now() behaves differently than the regular datetime.datetime() contstructor. Here's an example: >>> import pytz >>> info = pytz.timezone("US/Central") >>> info >>> import datetime >>> now = datetime.datetime.now(tz=info) >>> now datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=info) >>> t2 datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info True It appears that datetime.datetime.now() makes an off-by-one-hour copy of the timezone info it was passed. I've reproduced this on 2.4.3 and 2.5c1 as of August 17. (It's also a little annoying that the timezone arg for datetime.datetime.now() is "tz" while the timezone arg for datetime.datetime() is "tzinfo". Is there a good reason for them to be different?) Skip ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-07 13:11 Message: Logged In: YES user_id=31435 `tzinfo` is the name of a datetime data attribute, and the same name (i.e., "tzinfo") is generally used for arguments that mindlessly attach a subclass of the `tzinfo` class to an object as the value of its `tzinfo` data attribute. The datetime constructor is an example of that. `tz` is generally used when the time zone info is /actively applied/, as now() does. In contrast, the datetime constructor never makes any attempt at conversion; if a tzinfo argument is passed, it's merely tacked on to the datetime object. Beyond that, I have no idea why the pytz class passed to now() isn't showing up as the resulting datetime object's tzinfo member. For example, that's not what happens if you try this in the Python sandbox "datetime" directory: >>> from US import Eastern >>> from datetime import datetime >>> now = datetime.now(Eastern) >>> now datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> t2 = datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=Eastern) >>> t2 datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> now.tzinfo == Eastern True >>> t2.tzinfo == Eastern True >>> t2.tzinfo is now.tzinfo is Eastern True I expect the pytz developers could shed light on that. datetime.now(tz) with `tz` not None first mindlessly constructs a datetime object (let's call it `self`) based on current (UTC) time with tz attached as the value of its `tzinfo` data attribute, and then returns the result of invoking tz.fromutc(self) So if pytz overrides the default `fromutc()` implementation in its tzinfo subclasses, you'll get back whatever they decided to return from it. No code in Python "makes an off-by-one-hour copy" here. In short, I believe your primary question here is about how pytz works, and I can't answer that. IIRC, pytz does fancy stuff trying to avoid the 1-hour ambiguities at DST transition times, and I wouldn't be surprised if, toward that end, they have multiple internal tzinfo subclasses for each "conceptual" time zone. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 03:08 Message: Logged In: YES user_id=33168 Since Tim wrote this code AFAIK, there *had* to be a good reason. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 From noreply at sourceforge.net Fri Sep 8 05:05:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 20:05:41 -0700 Subject: [ python-Bugs-1553819 ] Class instance apparently not destructed when expected Message-ID: Bugs item #1553819, was opened at 2006-09-06 23:26 Message generated for change (Comment added) made by peterdonis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] ---------------------------------------------------------------------- >Comment By: Peter Donis (peterdonis) Date: 2006-09-07 23:05 Message: Logged In: YES user_id=1592444 mwh's comment is correct. See attached script deltest2.py, showing the contents of gc.garbage and how the reference cycle can be cleared (script output shown below). Note that I eliminated the base class and the masking of its class field; that was a red herring. My only other question is whether it might be worthwhile to add a sentence or two to the description of bound method objects in the documentation to make it clearer that you're creating a reference to the class instance. --- script output --- $ python deltest2.py ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc'] Initializing test object. ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc', 't'] ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc'] [] gc: uncollectable gc: uncollectable gc: uncollectable 3 [<__main__.Test object at 0xb7c3f34c>, {'testfield': >}, >] [] 0 ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'g', 'gc'] Freeing test object. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 10:06 Message: Logged In: YES user_id=6656 It's a reference cycle featuring an object with a __del__ --> it ends up in gc.garbage. More coffee for Neal? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 03:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 From noreply at sourceforge.net Fri Sep 8 05:09:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 20:09:51 -0700 Subject: [ python-Bugs-1553819 ] Class instance apparently not destructed when expected Message-ID: Bugs item #1553819, was opened at 2006-09-06 20:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 20:09 Message: Logged In: YES user_id=33168 Michael: coffee, no, sleep, yes. :-) ---------------------------------------------------------------------- Comment By: Peter Donis (peterdonis) Date: 2006-09-07 20:05 Message: Logged In: YES user_id=1592444 mwh's comment is correct. See attached script deltest2.py, showing the contents of gc.garbage and how the reference cycle can be cleared (script output shown below). Note that I eliminated the base class and the masking of its class field; that was a red herring. My only other question is whether it might be worthwhile to add a sentence or two to the description of bound method objects in the documentation to make it clearer that you're creating a reference to the class instance. --- script output --- $ python deltest2.py ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc'] Initializing test object. ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc', 't'] ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'gc'] [] gc: uncollectable gc: uncollectable gc: uncollectable 3 [<__main__.Test object at 0xb7c3f34c>, {'testfield': >}, >] [] 0 ['Test', '__builtins__', '__doc__', '__file__', '__name__', 'g', 'gc'] Freeing test object. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 07:06 Message: Logged In: YES user_id=6656 It's a reference cycle featuring an object with a __del__ --> it ends up in gc.garbage. More coffee for Neal? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:19 Message: Logged In: YES user_id=33168 The attached variant puts this into a function and shows ref leaks. It requires a debug build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 From noreply at sourceforge.net Fri Sep 8 06:36:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 21:36:25 -0700 Subject: [ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo Message-ID: Bugs item #1553577, was opened at 2006-09-07 04:11 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: When using the pytz package (http://pytz.sf.net/) to create timezone info objects datetime.datetime.now() behaves differently than the regular datetime.datetime() contstructor. Here's an example: >>> import pytz >>> info = pytz.timezone("US/Central") >>> info >>> import datetime >>> now = datetime.datetime.now(tz=info) >>> now datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=info) >>> t2 datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info True It appears that datetime.datetime.now() makes an off-by-one-hour copy of the timezone info it was passed. I've reproduced this on 2.4.3 and 2.5c1 as of August 17. (It's also a little annoying that the timezone arg for datetime.datetime.now() is "tz" while the timezone arg for datetime.datetime() is "tzinfo". Is there a good reason for them to be different?) Skip ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2006-09-08 14:36 Message: Logged In: YES user_id=46639 This is a pytz issue, and a result of me abusing Tim's code in ways he never intended. Tim is quite correct in that there are actually several tzinfo instances under the covers. In order to to unambiguous localtime calculations, an extra bit of information needs to be known (the is_dst flag in most datetime libraries). pytz uses the tzinfo instance to store this bit of information. The side affects of doing this are the behavior you noticed, and confusion as constructing datetime instances needs to be done as per pytz's README rather than the documented method in the Python Library Reference. >>> import pytz >>> info = pytz.timezone('US/Central') >>> info >>> from datetime import datetime >>> now = info.localize(datetime.now(), is_dst=True) >>> now datetime.datetime(2006, 9, 8, 11, 19, 29, 587943, tzinfo=) >>> t2 = info.localize(datetime(2006, 9, 8, 11, 19, 29, 587943)) >>> t2 datetime.datetime(2006, 9, 8, 11, 19, 29, 587943, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info False >>> now.tzinfo == t2.tzinfo True Last time I tried, it seemed impossible to support both pytz's goals and the datetime construction API specified in the Python Library Reference without extending the Python datetime module (and I have yet to specify what would be required). If I was to add an __eq__ method to the tzinfo classes, I'm not actually sure what the correct behavior should be. Should US/Eastern Daylight Savings Time really equate to US/Eastern Standard Time? Should US/Eastern Daylight Savings Time in 2002 really equate to US/Eastern Daylight Savings Time in 2007? The umbrella timezone might be the same, but the UTC offsets or switchover dates are different. The pytz bugtracker is at https://launchpad.net/products/pytz/+bugs ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-08 03:11 Message: Logged In: YES user_id=31435 `tzinfo` is the name of a datetime data attribute, and the same name (i.e., "tzinfo") is generally used for arguments that mindlessly attach a subclass of the `tzinfo` class to an object as the value of its `tzinfo` data attribute. The datetime constructor is an example of that. `tz` is generally used when the time zone info is /actively applied/, as now() does. In contrast, the datetime constructor never makes any attempt at conversion; if a tzinfo argument is passed, it's merely tacked on to the datetime object. Beyond that, I have no idea why the pytz class passed to now() isn't showing up as the resulting datetime object's tzinfo member. For example, that's not what happens if you try this in the Python sandbox "datetime" directory: >>> from US import Eastern >>> from datetime import datetime >>> now = datetime.now(Eastern) >>> now datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> t2 = datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=Eastern) >>> t2 datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> now.tzinfo == Eastern True >>> t2.tzinfo == Eastern True >>> t2.tzinfo is now.tzinfo is Eastern True I expect the pytz developers could shed light on that. datetime.now(tz) with `tz` not None first mindlessly constructs a datetime object (let's call it `self`) based on current (UTC) time with tz attached as the value of its `tzinfo` data attribute, and then returns the result of invoking tz.fromutc(self) So if pytz overrides the default `fromutc()` implementation in its tzinfo subclasses, you'll get back whatever they decided to return from it. No code in Python "makes an off-by-one-hour copy" here. In short, I believe your primary question here is about how pytz works, and I can't answer that. IIRC, pytz does fancy stuff trying to avoid the 1-hour ambiguities at DST transition times, and I wouldn't be surprised if, toward that end, they have multiple internal tzinfo subclasses for each "conceptual" time zone. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 17:08 Message: Logged In: YES user_id=33168 Since Tim wrote this code AFAIK, there *had* to be a good reason. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 From noreply at sourceforge.net Fri Sep 8 11:34:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 02:34:50 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 14:42 Message generated for change (Comment added) made by richardb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: Richard Boulton (richardb) Date: 2006-09-08 09:34 Message: Logged In: YES user_id=9565 HAVE_READLINE_CALLBACK is defined by configure.in whenever the readline library on the platform supports the rl_callback_handler_install() function. I'm using Ubuntu Dapper, and have libreadline 4 and 5 installed (more precisely, 4.3-18 and 5.1-7build1), but only the -dev package for 5.1-7build1. "info readline" describes rl_callback_handler_install(), and configure.in finds it, so I'm surprised it wasn't found on akuchling's machine. I agree that the code looks buggy on platforms in which signals don't necessarily get delivered to the main thread, but looks no more buggy with the patch than without. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:38 Message: Logged In: YES user_id=11375 On looking at the readline code, I think this patch makes no difference to signals. The code in readline.c for the callbacks looks like this: has_input = 0; while (!has_input) { ... has_input = select.select(rl_input); } if (has_input > 0) {read character} elif (errno == EINTR) {check signals} So I think that, if a signal is delivered to a thread and select() in the main thread doesn't return EINTR, the old code is just as problematic as the code with this patch. The (while !has_input) loop doesn't check for signals at all as an exit condition. I'm not sure what to do at this point. I think the new code is no worse than the old code with regard to signals. Maybe this loop is buggy w.r.t. to signals, but I don't know how to test that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 14:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 13:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Fri Sep 8 15:12:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 06:12:26 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 10:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-08 09:12 Message: Logged In: YES user_id=11375 That's exactly my setup. I don't think there is a -dev package for readline 4. I do note that READLINE_CALLBACKS is defined in /usr/include/readline/rlconf.h, but Python's readline.c doesn't include this file, and none of the readline headers include it. So I don't know why you're finding the function! ---------------------------------------------------------------------- Comment By: Richard Boulton (richardb) Date: 2006-09-08 05:34 Message: Logged In: YES user_id=9565 HAVE_READLINE_CALLBACK is defined by configure.in whenever the readline library on the platform supports the rl_callback_handler_install() function. I'm using Ubuntu Dapper, and have libreadline 4 and 5 installed (more precisely, 4.3-18 and 5.1-7build1), but only the -dev package for 5.1-7build1. "info readline" describes rl_callback_handler_install(), and configure.in finds it, so I'm surprised it wasn't found on akuchling's machine. I agree that the code looks buggy on platforms in which signals don't necessarily get delivered to the main thread, but looks no more buggy with the patch than without. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:38 Message: Logged In: YES user_id=11375 On looking at the readline code, I think this patch makes no difference to signals. The code in readline.c for the callbacks looks like this: has_input = 0; while (!has_input) { ... has_input = select.select(rl_input); } if (has_input > 0) {read character} elif (errno == EINTR) {check signals} So I think that, if a signal is delivered to a thread and select() in the main thread doesn't return EINTR, the old code is just as problematic as the code with this patch. The (while !has_input) loop doesn't check for signals at all as an exit condition. I'm not sure what to do at this point. I think the new code is no worse than the old code with regard to signals. Maybe this loop is buggy w.r.t. to signals, but I don't know how to test that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 10:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 10:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 09:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Fri Sep 8 16:30:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 07:30:15 -0700 Subject: [ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive Message-ID: Bugs item #1552726, was opened at 2006-09-05 14:42 Message generated for change (Comment added) made by richardb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&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: Fixed Priority: 5 Submitted By: Richard Boulton (richardb) Assigned to: A.M. Kuchling (akuchling) Summary: Python polls unnecessarily every 0.1 second when interactive Initial Comment: When python is running an interactive session, and is idle, it calls "select" with a timeout of 0.1 seconds repeatedly. This is intended to allow PyOS_InputHook() to be called every 0.1 seconds, but happens even if PyOS_InputHook() isn't being used (ie, is NULL). To reproduce: - start a python session - attach to it using strace -p PID - observe that python repeatedly This isn't a significant problem, since it only affects idle interactive python sessions and uses only a tiny bit of CPU, but people are whinging about it (though some appear to be doing so tongue-in-cheek) and it would be nice to fix it. The attached patch (against Python-2.5c1) modifies the readline.c module so that the polling doesn't happen unless PyOS_InputHook is not NULL. ---------------------------------------------------------------------- >Comment By: Richard Boulton (richardb) Date: 2006-09-08 14:30 Message: Logged In: YES user_id=9565 I'm finding the function because it's defined in the compiled library - the header files aren't examined by configure when testing for this function. (this is because configure.in uses AC_CHECK_LIB to check for rl_callback_handler_install, which just tries to link the named function against the library). Presumably, rlconf.h is the configuration used when the readline library was compiled, so if READLINE_CALLBACKS is defined in it, I would expect the relevant functions to be present in the compiled library. In any case, this isn't desperately important, since you've managed to hack around the test anyway. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-08 13:12 Message: Logged In: YES user_id=11375 That's exactly my setup. I don't think there is a -dev package for readline 4. I do note that READLINE_CALLBACKS is defined in /usr/include/readline/rlconf.h, but Python's readline.c doesn't include this file, and none of the readline headers include it. So I don't know why you're finding the function! ---------------------------------------------------------------------- Comment By: Richard Boulton (richardb) Date: 2006-09-08 09:34 Message: Logged In: YES user_id=9565 HAVE_READLINE_CALLBACK is defined by configure.in whenever the readline library on the platform supports the rl_callback_handler_install() function. I'm using Ubuntu Dapper, and have libreadline 4 and 5 installed (more precisely, 4.3-18 and 5.1-7build1), but only the -dev package for 5.1-7build1. "info readline" describes rl_callback_handler_install(), and configure.in finds it, so I'm surprised it wasn't found on akuchling's machine. I agree that the code looks buggy on platforms in which signals don't necessarily get delivered to the main thread, but looks no more buggy with the patch than without. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:38 Message: Logged In: YES user_id=11375 On looking at the readline code, I think this patch makes no difference to signals. The code in readline.c for the callbacks looks like this: has_input = 0; while (!has_input) { ... has_input = select.select(rl_input); } if (has_input > 0) {read character} elif (errno == EINTR) {check signals} So I think that, if a signal is delivered to a thread and select() in the main thread doesn't return EINTR, the old code is just as problematic as the code with this patch. The (while !has_input) loop doesn't check for signals at all as an exit condition. I'm not sure what to do at this point. I think the new code is no worse than the old code with regard to signals. Maybe this loop is buggy w.r.t. to signals, but I don't know how to test that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:17 Message: Logged In: YES user_id=11375 HAVE_READLINE_CALLBACK was not defined with readline 5.1 on Ubuntu Dapper, until I did the configure/CFLAG trick. I didn't think of a possible interaction with signals, and will re-open the bug while trying to work up a test case. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-09-07 14:12 Message: Logged In: YES user_id=6656 I'd be cautious about applying this to 2.5: we could end up with the same problem currently entertaining python-dev, i.e. a signal gets delivered to a non- main thread but the main thread is sitting in a select with no timeout so any python signal handler doesn't run until the user hits a key. HAVE_READLINE_CALLBACK is defined when readline is 2.1 *or newer* I think... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 14:02 Message: Logged In: YES user_id=11375 Recent versions of readline can still support callbacks if READLINE_CALLBACK is defined, so I could test the patch by running 'CFLAGS=-DREADLINE_CALLBACK' and re-running configure. Applied as rev. 51815 to the trunk, so the fix will be in Python 2.6. The 2.5 release manager needs to decide if it should be applied to the 2.5 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-07 13:24 Message: Logged In: YES user_id=11375 Original report: http://perkypants.org/blog/2006/09/02/rfte-python This is tied to the version of readline being used; the select code is only used if HAVE_RL_CALLBACK is defined, and a comment in Python's configure.in claims it's only defined with readline 2.1. Current versions of readline are 4.3 and 5.1; are people still using such an ancient version of readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470 From noreply at sourceforge.net Sat Sep 9 04:08:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 19:08:32 -0700 Subject: [ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo Message-ID: Bugs item #1553577, was opened at 2006-09-06 11:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: When using the pytz package (http://pytz.sf.net/) to create timezone info objects datetime.datetime.now() behaves differently than the regular datetime.datetime() contstructor. Here's an example: >>> import pytz >>> info = pytz.timezone("US/Central") >>> info >>> import datetime >>> now = datetime.datetime.now(tz=info) >>> now datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=info) >>> t2 datetime.datetime(2006, 9, 6, 12, 44, 18, 983849, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info True It appears that datetime.datetime.now() makes an off-by-one-hour copy of the timezone info it was passed. I've reproduced this on 2.4.3 and 2.5c1 as of August 17. (It's also a little annoying that the timezone arg for datetime.datetime.now() is "tz" while the timezone arg for datetime.datetime() is "tzinfo". Is there a good reason for them to be different?) Skip ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-08 19:08 Message: Logged In: YES user_id=33168 Based on Stuart's comment, I'm closing this. Skip, if there's any part of this that you think is a bug, re-open this with a comment about the precise issue or open a new bug report. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2006-09-07 21:36 Message: Logged In: YES user_id=46639 This is a pytz issue, and a result of me abusing Tim's code in ways he never intended. Tim is quite correct in that there are actually several tzinfo instances under the covers. In order to to unambiguous localtime calculations, an extra bit of information needs to be known (the is_dst flag in most datetime libraries). pytz uses the tzinfo instance to store this bit of information. The side affects of doing this are the behavior you noticed, and confusion as constructing datetime instances needs to be done as per pytz's README rather than the documented method in the Python Library Reference. >>> import pytz >>> info = pytz.timezone('US/Central') >>> info >>> from datetime import datetime >>> now = info.localize(datetime.now(), is_dst=True) >>> now datetime.datetime(2006, 9, 8, 11, 19, 29, 587943, tzinfo=) >>> t2 = info.localize(datetime(2006, 9, 8, 11, 19, 29, 587943)) >>> t2 datetime.datetime(2006, 9, 8, 11, 19, 29, 587943, tzinfo=) >>> now.tzinfo == info False >>> t2.tzinfo == info False >>> now.tzinfo == t2.tzinfo True Last time I tried, it seemed impossible to support both pytz's goals and the datetime construction API specified in the Python Library Reference without extending the Python datetime module (and I have yet to specify what would be required). If I was to add an __eq__ method to the tzinfo classes, I'm not actually sure what the correct behavior should be. Should US/Eastern Daylight Savings Time really equate to US/Eastern Standard Time? Should US/Eastern Daylight Savings Time in 2002 really equate to US/Eastern Daylight Savings Time in 2007? The umbrella timezone might be the same, but the UTC offsets or switchover dates are different. The pytz bugtracker is at https://launchpad.net/products/pytz/+bugs ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-07 10:11 Message: Logged In: YES user_id=31435 `tzinfo` is the name of a datetime data attribute, and the same name (i.e., "tzinfo") is generally used for arguments that mindlessly attach a subclass of the `tzinfo` class to an object as the value of its `tzinfo` data attribute. The datetime constructor is an example of that. `tz` is generally used when the time zone info is /actively applied/, as now() does. In contrast, the datetime constructor never makes any attempt at conversion; if a tzinfo argument is passed, it's merely tacked on to the datetime object. Beyond that, I have no idea why the pytz class passed to now() isn't showing up as the resulting datetime object's tzinfo member. For example, that's not what happens if you try this in the Python sandbox "datetime" directory: >>> from US import Eastern >>> from datetime import datetime >>> now = datetime.now(Eastern) >>> now datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> t2 = datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=Eastern) >>> t2 datetime.datetime(2006, 9, 7, 12, 49, 48, 430000, tzinfo=) >>> now.tzinfo == Eastern True >>> t2.tzinfo == Eastern True >>> t2.tzinfo is now.tzinfo is Eastern True I expect the pytz developers could shed light on that. datetime.now(tz) with `tz` not None first mindlessly constructs a datetime object (let's call it `self`) based on current (UTC) time with tz attached as the value of its `tzinfo` data attribute, and then returns the result of invoking tz.fromutc(self) So if pytz overrides the default `fromutc()` implementation in its tzinfo subclasses, you'll get back whatever they decided to return from it. No code in Python "makes an off-by-one-hour copy" here. In short, I believe your primary question here is about how pytz works, and I can't answer that. IIRC, pytz does fancy stuff trying to avoid the 1-hour ambiguities at DST transition times, and I wouldn't be surprised if, toward that end, they have multiple internal tzinfo subclasses for each "conceptual" time zone. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:08 Message: Logged In: YES user_id=33168 Since Tim wrote this code AFAIK, there *had* to be a good reason. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 From noreply at sourceforge.net Sat Sep 9 09:20:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 00:20:12 -0700 Subject: [ python-Bugs-1551432 ] __unicode__ breaks for exception class objects Message-ID: Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&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: Fixed Priority: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) >Assigned to: Brett Cannon (bcannon) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-09-09 00:20 Message: Logged In: YES user_id=357491 rev. 51837 and rev. 51838 have the fix in the trunk and 2.5, respectively. ---------------------------------------------------------------------- Comment By: Marcin 'Qrczak' Kowalczyk (qrczak) Date: 2006-09-05 15:08 Message: Logged In: YES user_id=50234 I think the way which is consistent with the current Python implementation is adding the tp_unicode slot. (Parenthetical remark. In the binding between Python and my language Kogut I'm exposing various standard APIs between the two languages automatically. And __unicode__ happened to be the *only* method which I needed to treat specially by tp_getattro. It's the only method I've encountered so far which is called by Python on lots of "ordinary" objects, and which doesn't have a C slot (and the consequence is that my default wrapper shouldn't forward it to the __unicode__ attribute in the other language, but to the appropriate API of the other language which obtains a Unicode rendition). This was a different issue than the topic of this bug, was solvable, but it was another suggestion that the way of handling __unicode__ is inconsistent with other *similar* attributes, similar in the sense of the amount of "genericity" and "magicness", and should have a C slot. The present problem is somewhat dual: now it's me who calls __unicode__ (even if indirectly), and it's Python who provides __unicode__ implementation of its objects. End of parenthetical remark.) Anyway, I'm afraid the issue is a symptom of a deeper problem. I was some time ago wondering how does Python distinguish whether x.foo, when x happens to be a class object (or type object), is meant to be an unbound method to be called with instances of that class, or a bound method to operate on the class object itself. It seems that Python doesn't attempt to use the second interpretation at all. Despite this, various standard operations are dressed in magic methods with names surrounded by double underscores do work for class objects! And while str(x) is the same as x.__str__() for most objects, it's not true for class objects and type objects: str(x) goes through the C slot while x.__str__() doesn't work. The set of methods which have C slots would seem to be just a shortcut for performance, but actually it has a semantic significance. Namely class objects and type objects can have specialized implementations of those methods, but not of ordinary methods. Fortunately it doesn't matter much in practice because the set of methods supported by class objects is fixed, and it just happens to be the subset of the methods with C slots. Unless some other objects can play the role of classes, and then the problem might reappear; I'm completely ignorant about Python metaclasses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-09-05 11:22 Message: Logged In: YES user_id=357491 This is because exceptions now define a proper __unicode__() method in the PyMethodDef array. This is what gets called and it requires an exception instance. Before it just fell through to the tp_str slot and that didn't complain. Unless some knows a better way (short of defining a tp_unicode slot), the only way to make this work would be to rip out the __unicode__() method. This would then require the function in the tp_str slot to have to detect if its arguments need to be Unicode or not (and I don't know how to do that off the top of my head; is their a PyUnicode_Check()?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 From noreply at sourceforge.net Sat Sep 9 15:14:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 06:14:53 -0700 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-10 01:31 Message generated for change (Comment added) made by baijum81 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Ka-Ping Yee (ping) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- Comment By: Baiju M (baijum81) Date: 2006-09-09 18:44 Message: Logged In: YES user_id=565450 Due to this bug, 'pydoc modulename' is not working. pydoc tries to access __name__ attribute of classes, so it raises attribute error. (actually it is not a class, but an instance only). So please increase the priority of this bug. And this case is also not working (same issue): class X: __bases__ = () x = X() ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 10:55 Message: Logged In: YES user_id=80475 Ping, do you have a few minutes to look at this one and make sure its the right thing to do. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 00:45 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 22:14 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 23:20 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 16:10 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 15:31 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 13:31 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 06:06 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Sat Sep 9 19:18:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 10:18:17 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 01:51 Message generated for change (Comment added) made by diggableme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 17:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 16:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 15:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 15:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 13:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Sat Sep 9 22:02:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 13:02:38 -0700 Subject: [ python-Bugs-1555496 ] Bug in the match function Message-ID: Bugs item #1555496, was opened at 2006-09-09 22:02 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=1555496&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 Submitted By: wojtekwu (wojtekwu) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Bug in the match function Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> as = re.compile("(a|((a|b)*))") >>> wynik = as.match("aabaa") >>> wynik.end() 1 >>> as = re.compile("(((a|b)*)|a)") >>> wynik = as.match("aabaa") >>> wynik.end() 5 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470 From noreply at sourceforge.net Sat Sep 9 22:06:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 13:06:54 -0700 Subject: [ python-Bugs-1555496 ] Bug in the match function Message-ID: Bugs item #1555496, was opened at 2006-09-09 20:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&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 Submitted By: wojtekwu (wojtekwu) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Bug in the match function Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> as = re.compile("(a|((a|b)*))") >>> wynik = as.match("aabaa") >>> wynik.end() 1 >>> as = re.compile("(((a|b)*)|a)") >>> wynik = as.match("aabaa") >>> wynik.end() 5 >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-09 20:06 Message: Logged In: YES user_id=849994 IMHO that's not a bug, since we have a "leftmost alternative" strategy, not a "longest match". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470 From noreply at sourceforge.net Sat Sep 9 22:07:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 13:07:58 -0700 Subject: [ python-Bugs-1555501 ] Please include pliblist for all plattforms Message-ID: Bugs item #1555501, was opened at 2006-09-09 22:07 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=1555501&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 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555501&group_id=5470 From noreply at sourceforge.net Sun Sep 10 00:23:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 15:23:20 -0700 Subject: [ python-Bugs-1555496 ] Bug in the match function Message-ID: Bugs item #1555496, was opened at 2006-09-09 16:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: wojtekwu (wojtekwu) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Bug in the match function Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> as = re.compile("(a|((a|b)*))") >>> wynik = as.match("aabaa") >>> wynik.end() 1 >>> as = re.compile("(((a|b)*)|a)") >>> wynik = as.match("aabaa") >>> wynik.end() 5 >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-09 18:23 Message: Logged In: YES user_id=31435 That's right -- the first ("leftmost") alternative that matches wins; same as Perl, etc etc. Closing as Not-A-Bug. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-09 16:06 Message: Logged In: YES user_id=849994 IMHO that's not a bug, since we have a "leftmost alternative" strategy, not a "longest match". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555496&group_id=5470 From noreply at sourceforge.net Sun Sep 10 02:03:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 17:03:49 -0700 Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 10:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&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.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:03 Message: Logged In: YES user_id=21627 I fail to see the problem. You have to change the recursion limit; if you do, you risk a crash, as the documentation says: http://docs.python.org/lib/module-sys.html "This should be done with care, because a too-high limit can lead to a crash." With an unmodified recursionlimit in 2.4.3 on Windows, I get the expected RuntimeError. If it causes a crash on some system, it just means that the default recursion limit is too high for that platform (however, we don't seem to have a confirmation that the default recursion limit is too large for this application on any platform for Python 2.4 or 2.5). It is quite common that the system provides the main thread with a larger stack space than any additional thread, so it is not surprising that the stack overflow is detected on some system when the code is run in the main thread, yet crashes in an additional thread. The default recursion limit should be the conservative minimum of what the system minimally guarantees for any thread. It seems that the original problem has been fixed (although nobody apparently has tested Python 2.4 or 2.5 on Solaris8); I suggest to close this as fixed again. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 09:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-14 04:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 21:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 21:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply at sourceforge.net Sun Sep 10 02:08:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 17:08:10 -0700 Subject: [ python-Bugs-1548332 ] whichdb too dumb Message-ID: Bugs item #1548332, was opened at 2006-08-29 07:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&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: Invalid Priority: 5 Submitted By: Curtis Doty (dotysan) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb too dumb Initial Comment: On my system with db4, I noticed that whichdb doesn't know anything about more recent database types created by the bsddb module. Python 2.4.3 (#1, Jun 13 2006, 11:46:08) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> from whichdb import * >>> import bsddb >>> >>> dbfile= "hash" >>> bsddb.hashopen( dbfile) {} >>> whichdb( dbfile) 'dbhash' >>> # yay ... >>> dbfile= "btree" >>> bsddb.btopen( dbfile) {} >>> whichdb( dbfile) '' >>> # bah ... >>> dbfile= "recno" >>> bsddb.rnopen( dbfile) {} >>> whichdb( dbfile) '' >>> # humbug! It looks like both these database types share: #define DB_BTREEMAGIC 0x053162 So this might be a start: --- Python-2.5c1/Lib/whichdb.py.orig 2005-02-05 22:57:08.000000000 -0800 +++ Python-2.5c1/Lib/whichdb.py 2006-08-28 13:46:57.000000000 -0700 @@ -109,6 +109,10 @@ if magic in (0x00061561, 0x61150600): return "dbhash" + # Check for binary tree + if magic == 0x00053162: + return "btree" + # Unknown return "" But alas, I'm not clear on the best way to differentiate between btree and recno. The above example is on 2.4 but persists in 2.5. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:08 Message: Logged In: YES user_id=21627 It is not the job of whichdb to recognize certain database types created by the bsddb module. Instead, as the doc string says "Guess which db package to use to open a db file." The return value of whichdb is a *module name*. Since "btree" is not a module name, the proposed change is incorrect. Closing as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470 From noreply at sourceforge.net Sun Sep 10 02:09:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 17:09:56 -0700 Subject: [ python-Bugs-1545659 ] distutils needs vendor-packages support Message-ID: Bugs item #1545659, was opened at 2006-08-24 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 From noreply at sourceforge.net Sun Sep 10 02:13:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 17:13:14 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 02:16:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 17:16:27 -0700 Subject: [ python-Bugs-1543467 ] test_tempfile fails on cygwin Message-ID: Bugs item #1543467, was opened at 2006-08-20 15:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/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 127 ---------------------------------------------------------------------- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/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 127 [16:12] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:16 Message: Logged In: YES user_id=21627 The usual way of invoking test_tempfile would be ./python Lib/test/regrtest.py test_tempfile or ./python -mtest.regrtest test_tempfile Do these give you the same error? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-08-21 07:55 Message: Logged In: YES user_id=358087 Cygwin version is 1.5.21 (see attached output of cygcheck -s -v -r). What do you mean by "running directly"? I ran the test with the following command line (and it failed): ./python.exe -c 'from test.test_tempfile import test_main; test_main()' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 04:13 Message: Logged In: YES user_id=33168 What version of cygwin? I've been testing with 1.5.19 and greater and not had this problem. However, I've only run with regrtest. Do you have this problem only if running directly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 From noreply at sourceforge.net Sun Sep 10 08:36:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 23:36:46 -0700 Subject: [ python-Bugs-1543467 ] test_tempfile fails on cygwin Message-ID: Bugs item #1543467, was opened at 2006-08-20 16:18 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/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 127 ---------------------------------------------------------------------- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/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 127 [16:12] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-09-10 09:36 Message: Logged In: YES user_id=358087 In your way it seems OK :) [09:22] ~ $cd src/Python-2.5c1/ /home/mtebeka/src/Python-2.5c1 [09:23] ~/src/Python-2.5c1 $./python.exe -mtest.regrtest test_tempfile Could not find '/home/mtebeka/src/Python-2.5c1/Lib/test' in sys.path to remove it test_tempfile 1 test OK. [09:23] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 03:16 Message: Logged In: YES user_id=21627 The usual way of invoking test_tempfile would be ./python Lib/test/regrtest.py test_tempfile or ./python -mtest.regrtest test_tempfile Do these give you the same error? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-08-21 08:55 Message: Logged In: YES user_id=358087 Cygwin version is 1.5.21 (see attached output of cygcheck -s -v -r). What do you mean by "running directly"? I ran the test with the following command line (and it failed): ./python.exe -c 'from test.test_tempfile import test_main; test_main()' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 05:13 Message: Logged In: YES user_id=33168 What version of cygwin? I've been testing with 1.5.19 and greater and not had this problem. However, I've only run with regrtest. Do you have this problem only if running directly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 From noreply at sourceforge.net Sun Sep 10 09:14:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 00:14:35 -0700 Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 18:37 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&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.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 17:14 Message: Logged In: YES user_id=250749 As of 2.5, the stack size for a thread can be set before the thread is created. Windows and Linux seem to default to generous thread stack sizes (1MB or more), other platforms are parsimonious by comparison (eg FreeBSD at 64kB). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 10:03 Message: Logged In: YES user_id=21627 I fail to see the problem. You have to change the recursion limit; if you do, you risk a crash, as the documentation says: http://docs.python.org/lib/module-sys.html "This should be done with care, because a too-high limit can lead to a crash." With an unmodified recursionlimit in 2.4.3 on Windows, I get the expected RuntimeError. If it causes a crash on some system, it just means that the default recursion limit is too high for that platform (however, we don't seem to have a confirmation that the default recursion limit is too large for this application on any platform for Python 2.4 or 2.5). It is quite common that the system provides the main thread with a larger stack space than any additional thread, so it is not surprising that the stack overflow is detected on some system when the code is run in the main thread, yet crashes in an additional thread. The default recursion limit should be the conservative minimum of what the system minimally guarantees for any thread. It seems that the original problem has been fixed (although nobody apparently has tested Python 2.4 or 2.5 on Solaris8); I suggest to close this as fixed again. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 17:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-14 12:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 21:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 05:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 05:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply at sourceforge.net Sun Sep 10 09:27:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 00:27:20 -0700 Subject: [ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Message-ID: Bugs item #1550791, was opened at 2006-09-02 08:23 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. L?wis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 17:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 From noreply at sourceforge.net Sun Sep 10 11:53:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 02:53:28 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 11:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 02:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 05:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 04:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 04:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 03:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 06:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 06:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Sun Sep 10 12:26:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 03:26:06 -0700 Subject: [ python-Feature Requests-1547300 ] Wireless on Python Message-ID: Feature Requests item #1547300, was opened at 2006-08-26 23:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1547300&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: Nobody/Anonymous (nobody) Summary: Wireless on Python Initial Comment: It would be very nice if Python had a Wireless Module that works on all platforms. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 12:26 Message: Logged In: YES user_id=21627 Would you like to contribute one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1547300&group_id=5470 From noreply at sourceforge.net Sun Sep 10 12:36:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 03:36:46 -0700 Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode groups and block ranges needed Message-ID: Feature Requests item #1528154, was opened at 2006-07-25 06:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&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: None Status: Open Resolution: None Priority: 6 Submitted By: gmarketer (gmarketer) Assigned to: Nobody/Anonymous (nobody) Summary: New sequences for Unicode groups and block ranges needed Initial Comment: The special sequences consist of "\" and another character need to be added to RE sintax to simplify the finding of several Unicode classes like: * All uppercase letters * All lowercase letters ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 12:36 Message: Logged In: YES user_id=21627 If anything, I think Python should implement Unicode TR#18: http://www.unicode.org/unicode/reports/tr18/ This does include the \p notation for property expressions, e.g. \p{Ll} or \p{East Asian Width:Narrow}. We currently don't include the Script property, so \p{Greek} could not be implemented (we can, of course, add support for the script property). I can't find anything in the report that makes \p{IsGreek} valid, so we shouldn't support it. ---------------------------------------------------------------------- Comment By: gmarketer (gmarketer) Date: 2006-07-26 04:06 Message: Logged In: YES user_id=1334865 We need to process several strings in utf-8 and need to use regular expressions to match pattern, for ex.: r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY" We don't know how to implement this logic by our hands. Also, I found this logic implemented in Microsoft dot NET regular expressions: \p{name} Matches any character in the named character class 'name'. Supported names are Unicode groups and block ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc (currency). \P{name} Matches text not included in the named character class 'name'. We need same logic in regular expressions. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-07-25 09:45 Message: Logged In: YES user_id=38388 Could you make your request a little more specific ? We already have catregories in the re module, so adding a few more would be possible (patches are welcome !). However, we do need to know why you need them and whether there are other RE implementations that already have such special matching characters, e.g. the Perl RE implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470 From noreply at sourceforge.net Sun Sep 10 14:26:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 05:26:12 -0700 Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload Message-ID: Bugs item #1409455, was opened at 2006-01-18 22:09 Message generated for change (Comment added) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-09-10 12:26 Message: Logged In: YES user_id=24723 This fix seems to have caused issues for code that does the following: from email.Charset import Charset,QP from email.MIMEText import MIMEText charset = Charset('utf-8') charset.body_encoding = QP msg = MIMEText( u'Some text with chars that need encoding: \xa3', 'plain', ) # set the charset msg.set_charset(charset) print msg.as_string() Before this fix, the above would result in: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Some text with chars that need encoding: =A3 Now I get: Traceback (most recent call last): File "test_encoding.py", line 14, in ? msg.as_string() File "c:\python24\lib\email\Message.py", line 129, in as_string g.flatten(self, unixfrom=unixfrom) File "c:\python24\lib\email\Generator.py", line 82, in flatten self._write(msg) File "c:\python24\lib\email\Generator.py", line 113, in _write self._dispatch(msg) File "c:\python24\lib\email\Generator.py", line 139, in _dispatch meth(msg) File "c:\python24\lib\email\Generator.py", line 182, in _handle_text self._fp.write(payload) UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 41: ordinal not in range(128) Am I doing something wrong here or is this patch in error? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-02-08 13:34 Message: Logged In: YES user_id=12800 r42270 for Python 2.3/email 2.5. I will forward port these to Python 2.4 and 2.5 (email 3.0). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-02-08 03:07 Message: Logged In: YES user_id=12800 See the latest patch in issue 1409458: https://sourceforge.net/support/tracker.php?aid=1409538 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-02-06 03:42 Message: Logged In: YES user_id=12800 See the attached patch for what I think is ultimately the right fix. The idea is that when set_payload() is called, the payload is immediately encoded so that get_payload() will do the right thing. Also, Generator.py has to be fixed to not doubly encode the payload. Run against your example, it seems to DTRT. It also passes all but one of the email pkg unit tests. The one failure is, I believe due to an incorrect test. The patch includes a fix for that as well as adding a test for get_payload(decode=True). I'd like to get some feedback from the email-sig before applying this, but it seems right to me. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-01-20 23:19 Message: Logged In: YES user_id=1123998 I've looked at the email library and I see the problem. msg.set_payload() never QP encodes msg._payload. When the message is stringified or flattened by a generator, the generator's _handle_text() method does the encoding and it is msg._charset that signals the need to do this. Thus when the message object is ultimately converted to a suitable external form, the body is QP encoded, but internally it never is. Thus, subsequent msg.get_payload() calls return unexpected results. It appears (from minimal testing) that when a text message is parsed into an email.Message.Message instance, _charset is None even if there is a character set specification in a Content-Type: header. I have attached a patch (Message.py.patch.txt) which may fix the problem. It has only been tested against the already attached example.py so it is really untested. Also, it only addresses the quoted-printable case. I haven't even thought about whether there might be a similar problem involving base64. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 From noreply at sourceforge.net Sun Sep 10 16:52:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 07:52:02 -0700 Subject: [ python-Bugs-1545659 ] distutils needs vendor-packages support Message-ID: Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-10 14:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 From noreply at sourceforge.net Sun Sep 10 16:55:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 07:55:17 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 17:17:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 08:17:15 -0700 Subject: [ python-Bugs-1545659 ] distutils needs vendor-packages support Message-ID: Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Feature Request >Status: Closed Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 From noreply at sourceforge.net Sun Sep 10 17:24:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 08:24:09 -0700 Subject: [ python-Bugs-1545659 ] distutils needs vendor-packages support Message-ID: Bugs item #1545659, was opened at 2006-08-24 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Feature Request Status: Closed Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:24 Message: Logged In: YES user_id=21627 For the record: patch #1298835 wasn't refused; it was withdrawn by the submitter. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 From noreply at sourceforge.net Sun Sep 10 17:26:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 08:26:46 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 18:04:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 09:04:27 -0700 Subject: [ python-Bugs-1555842 ] email package and Unicode strings handling Message-ID: Bugs item #1555842, was opened at 2006-09-10 16:04 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=1555842&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 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: email package and Unicode strings handling Initial Comment: The support for Unicode strings in the email package (notably MIMEText and Header class) is not uniform. The behaviour with Unicode strings in Header is documented but the interface is not good. This code works, but it should not: >>> h = Header.Header(u"?????", charset="us-ascii") >>> m = Message.Message() >>> m["Subject"] = h >>> print m.as_string() Allowing this to work can cause confusion, I'm saying that the charset is us-ascii, not utf-8. With MIMEText I obtain: m = MIMEText.MIMEText(u"?????", _charset="us-ascii") >>> print m.as_string() [ exception ] I think that the correct behaviour (for all functions accepting strings) is: - Do not accept plain str strings (8-bit). Accept only if they are plain ascii (7-bit). - The charset specified should not be considered an hint, but the charset I want to be used. Regards Manlio Perillo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&group_id=5470 From noreply at sourceforge.net Sun Sep 10 19:35:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 10:35:46 -0700 Subject: [ python-Bugs-1555842 ] email package and Unicode strings handling Message-ID: Bugs item #1555842, was opened at 2006-09-10 16:04 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&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 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: email package and Unicode strings handling Initial Comment: The support for Unicode strings in the email package (notably MIMEText and Header class) is not uniform. The behaviour with Unicode strings in Header is documented but the interface is not good. This code works, but it should not: >>> h = Header.Header(u"?????", charset="us-ascii") >>> m = Message.Message() >>> m["Subject"] = h >>> print m.as_string() Allowing this to work can cause confusion, I'm saying that the charset is us-ascii, not utf-8. With MIMEText I obtain: m = MIMEText.MIMEText(u"?????", _charset="us-ascii") >>> print m.as_string() [ exception ] I think that the correct behaviour (for all functions accepting strings) is: - Do not accept plain str strings (8-bit). Accept only if they are plain ascii (7-bit). - The charset specified should not be considered an hint, but the charset I want to be used. Regards Manlio Perillo ---------------------------------------------------------------------- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-09-10 17:35 Message: Logged In: YES user_id=1054957 The last example is not right. Here is the correct one: >>> m = MIMEText.MIMEText(u"?????", _charset="utf-8") Traceback (most recent call last): File "", line 1, in ? File "C:\Python2.4\lib\email\MIMEText.py", line 28, in __init__ self.set_payload(_text, _charset) File "C:\Python2.4\lib\email\Message.py", line 218, in set_payload self.set_charset(charset) File "C:\Python2.4\lib\email\Message.py", line 260, in set_charset self._payload = charset.body_encode(self._payload) File "C:\Python2.4\lib\email\Charset.py", line 366, in body_encode return email.base64MIME.body_encode(s) File "C:\Python2.4\lib\email\base64MIME.py", line 136, in encode enc = b2a_base64(s[i:i + max_unencoded]) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) So it seems that email.Message does not handle Unicode strings. The code works if I set the charset to latin-1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&group_id=5470 From noreply at sourceforge.net Sun Sep 10 20:51:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 11:51:35 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 21:00:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 12:00:36 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 22:12:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 13:12:58 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-10 20:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 19:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Sun Sep 10 23:08:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 14:08:04 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 23:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 22:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Mon Sep 11 00:01:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 15:01:50 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-10 22:01 Message: Logged In: YES user_id=7887 Interesting. I was running tests directly most of the times and also in verbose mode, which indeed was hiding the problem that would happen when stdout is replaced. Now, one thing I wonder is about this: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/1424/step-test/0 Why is it failing? In the first run, when all buildbots were broken, this is what was happening. It does look like tests are succeeding, and the implementation is the same as the currently committed one, but buildbot still says it's broken for some reason, and no error messages. Strange. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 09:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 00:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Mon Sep 11 06:25:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 21:25:57 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-16 18:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: Closed >Resolution: Fixed >Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Neal Norwitz (nnorwitz) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-10 21:25 Message: Logged In: YES user_id=33168 I reverted the patch and added the test case for sgml so the infinite loop doesn't recur. Committed revision 51854. (head) Committed revision 51850. (2.5) Committed revision 51853. (2.4) I will add the hang_re test cause to test_crashers or somewhere. ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 14:40 Message: Logged In: YES user_id=1426755 Sorry, correct URL is http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47154&r1=47080&r2=47154 ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 14:24 Message: Logged In: YES user_id=1426755 Again FYI, here's the diff where presumably the bug was introduced: http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47080&r1=46996&r2=47080 ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2006-09-05 14:04 Message: Logged In: YES user_id=1426755 I've been testing quiver's test case: - With Eclipse's QuickREx plugin: it hangs. It was configured in PCRE mode (which uses Jakarta-ORO Perl 5 regular expressions implementation), and no additional options. - With grep: grep exits with a fatal error and dumps a stack trace. grep was run also in Perl mode, with the command: grep -P -f regexp.txt test.txt I can't find an explanation for this, but I don't know much about regexps. I hope it has some utility for the resolution of this bug nevertheless. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-08-17 21:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Mon Sep 11 06:26:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 21:26:40 -0700 Subject: [ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values Message-ID: Bugs item #1504333, was opened at 2006-06-11 05:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Sam Ruby (rubys) >Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib should allow angle brackets in quoted values Initial Comment: Real live example (search for "other
corrections") http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html This addresses the following (included in the file): # XXX The following should skip matching quotes (' or ") ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-10 21:26 Message: Logged In: YES user_id=33168 I reverted the patch and added the test case for sgml so the infinite loop doesn't recur. This was mentioned several times on python-dev. Committed revision 51854. (head) Committed revision 51850. (2.5) Committed revision 51853. (2.4) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-29 10:17 Message: Logged In: YES user_id=3066 I checked in a modified version of this patch: changed to use separate REs for start and end tags to reduce matching cost for end tags; extended tests; updated to avoid breaking previous changes to support IPv6 addresses in unquoted attribute values. Committed as revisions 47154 (trunk) and 47155 (release24-maint). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470 From noreply at sourceforge.net Mon Sep 11 07:16:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Sep 2006 22:16:48 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 07:16 Message: Logged In: YES user_id=21627 It often happens that the tests fail first and then pass when rerun; it is not that clear why that happens. In many cases, this has turned out to be a consequence of the sequence in which the tests are run, where earlier tests "break" some state information to let later tests fail. It should be possible to enhance regrtest/unittest to keep more information about a failure, e.g. which specific test method failed. This might give a clue in cases like this. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-11 00:01 Message: Logged In: YES user_id=7887 Interesting. I was running tests directly most of the times and also in verbose mode, which indeed was hiding the problem that would happen when stdout is replaced. Now, one thing I wonder is about this: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/1424/step-test/0 Why is it failing? In the first run, when all buildbots were broken, this is what was happening. It does look like tests are succeeding, and the implementation is the same as the currently committed one, but buildbot still says it's broken for some reason, and no error messages. Strange. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 11:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 02:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 05:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 04:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 04:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 03:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 06:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 06:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Mon Sep 11 12:17:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 03:17:49 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-11 10:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 19:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Mon Sep 11 12:47:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 03:47:39 -0700 Subject: [ python-Bugs-1556261 ] Move fpectl elsewhere in library reference Message-ID: Bugs item #1556261, was opened at 2006-09-11 10:47 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=1556261&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Move fpectl elsewhere in library reference Initial Comment: The fpectl module is not installed by default, but it still has a prominent place in the library reference. I think it should be moved to Optional Operating System Services and a note added at the top that it is not installed by default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470 From noreply at sourceforge.net Mon Sep 11 14:03:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 05:03:04 -0700 Subject: [ python-Bugs-1512604 ] Install on Windows Vista locks up Message-ID: Bugs item #1512604, was opened at 2006-06-26 13:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&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: Installation >Group: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Michael Lucas (michael_lucas) Assigned to: Nobody/Anonymous (nobody) Summary: Install on Windows Vista locks up Initial Comment: I have had problems trying to install this version on Vista. When the install gets to the verifying disk space requirements the system locks up. It does not go any further. I have to cancel the instalation of python. The only way I have got around this is to install an older version of python (version 2.3.5) this version does work, but there are newer versions that I want to work with on my system. If anyone has a work around for this please contact me at michael.lucas at us.army.mil ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 14:03 Message: Logged In: YES user_id=21627 It appears that this problem has been fixed in Vista RC1. Closing this report as third-party bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-07 07:08 Message: Logged In: YES user_id=21627 That's actually no surprise: /qb disables the user interface, so that the problematic interaction is skipped entirely. ---------------------------------------------------------------------- Comment By: Pat Lathem (plathem) Date: 2006-07-07 03:51 Message: Logged In: YES user_id=661716 FWIW, this can be worked around by using the command-line MSI installer: msiexec /i python-2.4.3.msi TARGETDIR="C:\Program Files\Python24" ALLUSERS=1 /qb Found that here: http://mail.python.org/pipermail/python-list/2006-June/347402.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-29 20:48 Message: Logged In: YES user_id=21627 I can confirm the problem, but I doubt I can do much about it. In fact, I believe this is a bug in Vista/Windows Installer 4.0. The installer GUI waits for the CostingComplete property to be set, but this never happens. If you are a beta tester, please make a bug report to Microsoft. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470 From noreply at sourceforge.net Mon Sep 11 14:04:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 05:04:25 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-23 00:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: Installation Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 14:04 Message: Logged In: YES user_id=21627 Closing this as "works for me". If it happens again, please create a new report with the exact steps needed to reproduce. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-30 06:40 Message: Logged In: YES user_id=21627 The alpha installers are at http://www.python.org/ftp/python/2.5/prev/ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-29 22:21 Message: Logged In: YES user_id=764593 I can no longer locate the alpha installers, but I'll see if I can reproduce it with the beta installer plus a 2.4 version. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-29 20:59 Message: Logged In: YES user_id=21627 I could not reproduce the problem. Can you please try to reproduce it, installing things in the order you did? Please provide all details, such as sequence of MSI invocations, options selected, reboots/logouts performed, etc. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 17:39 Message: Logged In: YES user_id=764593 All versions are binary downloads for windows, from python.org I have a 2.4, which seems not to be relevant. I don't remember whether I had installed 2.5a1, though I think so. If I had, it was successfully overwritten by 2.5a2. I had definately installed 2.5a2. The problem came when I attempted to install 2.5b1 on top of 2.5a2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-24 12:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Mon Sep 11 21:48:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 12:48:07 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 21:48 Message: Logged In: YES user_id=21627 It's ok for the Lib directory to be the same across Python versions because it means that the user doesn't have to reinstall the packages (atleast not the pure-python ones, and, conditionally, perhaps not even the binary ones) when the Python version changes. Python will automatically, transparently replace the byte code files when the system Python is updated, and the user only has to add a single directory to the PYTHONPATH. If the user has the convention to include ~/bin in his path, he doesn't need any additional setup for scripts that get installed. So, adding a version number into the directories would add additional inconvenience, since the user would have to install the same package multiple times, and because she would have to set PYTHONPATH differently depending on what Python version she wants to use. It is the way it is to please the user; changing it the way you propose would make it more inconvenient. Now, you suggest that the home scheme would be used by an OS vendor who likes to install into /usr/lib/python2.x. This is an abuse of the home scheme, and what works very well for a user apparently does not work well for an OS vendor. If the OS vendor tries this abuse anyway, he must live with the consequences. The user would be better advised to use the UNIX scheme, pass --prefix=/usr. This would automatically put things into /usr/lib/python2.x. Why the OS vendor would chose not do so, I cannot guess. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-11 12:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 23:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 22:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Mon Sep 11 22:24:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 13:24:25 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: John Levon (movement) Date: 2006-09-11 20:24 Message: Logged In: YES user_id=53034 Regarding the first part of your reply - I can understand that; thanks for the detailed rationale. Perhaps this bug is really about the distutils docs? In particular it seems useful to clarify the problems with non-pure modules as well. Regarding the second - it's only relevant due to the lack of upstream vendor-packages support. That is, I was trying to clean up our builds to not have to do: mv site-packages vendor-packages (You can refer to the original vendor-packages discussion if you're still asking why we don't install into the main Python directory.) I understand this was more of a hack than a solution, so consider that part void. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 19:48 Message: Logged In: YES user_id=21627 It's ok for the Lib directory to be the same across Python versions because it means that the user doesn't have to reinstall the packages (atleast not the pure-python ones, and, conditionally, perhaps not even the binary ones) when the Python version changes. Python will automatically, transparently replace the byte code files when the system Python is updated, and the user only has to add a single directory to the PYTHONPATH. If the user has the convention to include ~/bin in his path, he doesn't need any additional setup for scripts that get installed. So, adding a version number into the directories would add additional inconvenience, since the user would have to install the same package multiple times, and because she would have to set PYTHONPATH differently depending on what Python version she wants to use. It is the way it is to please the user; changing it the way you propose would make it more inconvenient. Now, you suggest that the home scheme would be used by an OS vendor who likes to install into /usr/lib/python2.x. This is an abuse of the home scheme, and what works very well for a user apparently does not work well for an OS vendor. If the OS vendor tries this abuse anyway, he must live with the consequences. The user would be better advised to use the UNIX scheme, pass --prefix=/usr. This would automatically put things into /usr/lib/python2.x. Why the OS vendor would chose not do so, I cannot guess. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-11 10:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 19:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Mon Sep 11 23:01:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 14:01:20 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 23:01 Message: Logged In: YES user_id=21627 Unfortunately, the "vendor-packages" directory was never really discussed. The only rationale I could find is from Rich Burridge, on 09-20-2005, and says "We have been told that this directory is inappropriate for vendor supplied packages, just as "site_perl" is inappropriate for Perl." This is hardly a convincing rationale: it is hearsay ("we have been told", rather than "we believe"), and it suggests that the only rationale for doing so is that Perl does so. That couldn't convince me; the Perl way of doing things has only in so far influenced Python as Perl was given as a bad example which is not to follow in the past. In any case, such discussion belongs to python-dev. I'm personally not convinced that adding vendor-packages to sys.path is necessary (why is site-packages not good enough?), but I'm also not strongly opposed to add yet another typically non-existing directory to the path (especially since Python 2.5 caches the absence of the directory so it gets skipped in subsequent imports) ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-11 22:24 Message: Logged In: YES user_id=53034 Regarding the first part of your reply - I can understand that; thanks for the detailed rationale. Perhaps this bug is really about the distutils docs? In particular it seems useful to clarify the problems with non-pure modules as well. Regarding the second - it's only relevant due to the lack of upstream vendor-packages support. That is, I was trying to clean up our builds to not have to do: mv site-packages vendor-packages (You can refer to the original vendor-packages discussion if you're still asking why we don't install into the main Python directory.) I understand this was more of a hack than a solution, so consider that part void. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-11 21:48 Message: Logged In: YES user_id=21627 It's ok for the Lib directory to be the same across Python versions because it means that the user doesn't have to reinstall the packages (atleast not the pure-python ones, and, conditionally, perhaps not even the binary ones) when the Python version changes. Python will automatically, transparently replace the byte code files when the system Python is updated, and the user only has to add a single directory to the PYTHONPATH. If the user has the convention to include ~/bin in his path, he doesn't need any additional setup for scripts that get installed. So, adding a version number into the directories would add additional inconvenience, since the user would have to install the same package multiple times, and because she would have to set PYTHONPATH differently depending on what Python version she wants to use. It is the way it is to please the user; changing it the way you propose would make it more inconvenient. Now, you suggest that the home scheme would be used by an OS vendor who likes to install into /usr/lib/python2.x. This is an abuse of the home scheme, and what works very well for a user apparently does not work well for an OS vendor. If the OS vendor tries this abuse anyway, he must live with the consequences. The user would be better advised to use the UNIX scheme, pass --prefix=/usr. This would automatically put things into /usr/lib/python2.x. Why the OS vendor would chose not do so, I cannot guess. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-11 12:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 23:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 22:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 21:00 Message: Logged In: YES user_id=21627 Why would a user not have the right to install to its own home directory? That's what the home scheme is there for. In any case, it seems that there won't be actual breakage, only a possible slowdown. I very much doubt that the slowdown would ever be significant, though. It seems you want to use the home scheme for something that it was not designed for. Notice that it is merely an abbreviation - you can specify the directories directly if you want to. I'm closing this as invalid: the original report ("Thus, breakage can occur.") is apparently wrong. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 20:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Tue Sep 12 00:31:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 15:31:33 -0700 Subject: [ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode Message-ID: Bugs item #1553496, was opened at 2006-09-06 16:03 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Walker Hale (walkerh) Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-09-11 22:31 Message: Logged In: YES user_id=308438 I don't feel that the current behaviour is inconsistent, because you normally want the current log file to be appended to, when the program starts. (Of course, you can override this to specify "w" and start with a new file for every run.) However, when you rollover, you want the new file to be truncated, and not have new log messages appended to existing data. Hence, "a" is used at first, and "w" at rollover. Remember, the log file before rollover (e.g. test.log) is renamed to test.log.n, and rolled-over output goes into test.log. Since the original test.log is now test.log.n, what does it mean to open test.log with "a"? Since test.log does not exist, opening with "w" and "a" are equivalent. If you spot a flaw in this reasoning, please re-open and give a more detailed scenario which explains exactly why the current behaviour is causing you a problem. In particular, it would help if you could walk me through a scenario which shows how the system would behave observably differently if "a" were used instead of "w" at rollover. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 From noreply at sourceforge.net Tue Sep 12 04:43:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 19:43:32 -0700 Subject: [ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars Message-ID: Bugs item #1556784, was opened at 2006-09-11 22:43 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=1556784&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 Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: [I'm putting this in category Python Library, because I assume Extensions Modules is for problems in the Extensions Module plumbing.] datetime.date and datetime.time's strftime() methods call wrap_strftime(), which limits the length of the format string to 127 chars before calling time.strftime(). This can be seen in the examples below. Note that in the third example, time.strftime() does not have a problem with a 128 character format string. >>> import datetime >>> datetime.date.today().strftime('x'*128) Traceback (most recent call last): File "", line 1, in MemoryError >>> import datetime >>> datetime.date.today().strftime('x'*256) Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&group_id=5470 From noreply at sourceforge.net Tue Sep 12 09:33:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 00:33:23 -0700 Subject: [ python-Bugs-1556895 ] typo in encoding name in email package Message-ID: Bugs item #1556895, was opened at 2006-09-12 09:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: typo in encoding name in email package Initial Comment: gb2132 should be gb2312... Here is a patch against email-2.5.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 From noreply at sourceforge.net Tue Sep 12 12:56:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 03:56:44 -0700 Subject: [ python-Bugs-1557037 ] datetime's strftime limits strings to 127 chars Message-ID: Bugs item #1557037, was opened at 2006-09-12 06:56 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=1557037&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 Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: [I'm putting this in category Python Library, because I assume Extensions Modules is for problems in the Extensions Module plumbing.] datetime.date and datetime.time's strftime() methods call wrap_strftime(), which limits the length of the format string to 127 chars before calling time.strftime(). This can be seen in the examples below. Note that in the third example, time.strftime() does not have a problem with a 128 character format string. >>> import datetime >>> datetime.date.today().strftime('x'*128) Traceback (most recent call last): File "", line 1, in MemoryError >>> import datetime >>> datetime.date.today().strftime('x'*256) Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&group_id=5470 From noreply at sourceforge.net Tue Sep 12 12:57:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 03:57:27 -0700 Subject: [ python-Bugs-1557037 ] datetime's strftime limits strings to 127 chars Message-ID: Bugs item #1557037, was opened at 2006-09-12 06:56 Message generated for change (Settings changed) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: [I'm putting this in category Python Library, because I assume Extensions Modules is for problems in the Extensions Module plumbing.] datetime.date and datetime.time's strftime() methods call wrap_strftime(), which limits the length of the format string to 127 chars before calling time.strftime(). This can be seen in the examples below. Note that in the third example, time.strftime() does not have a problem with a 128 character format string. >>> import datetime >>> datetime.date.today().strftime('x'*128) Traceback (most recent call last): File "", line 1, in MemoryError >>> import datetime >>> datetime.date.today().strftime('x'*256) Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&group_id=5470 From noreply at sourceforge.net Tue Sep 12 17:28:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 08:28:52 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 17:28 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=1557232&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Tue Sep 12 17:29:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 08:29:13 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 17:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Tue Sep 12 19:33:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 10:33:45 -0700 Subject: [ python-Bugs-1556895 ] typo in encoding name in email package Message-ID: Bugs item #1556895, was opened at 2006-09-12 03:33 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guillaume Rousse (guillomovitch) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: typo in encoding name in email package Initial Comment: gb2132 should be gb2312... Here is a patch against email-2.5.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 From noreply at sourceforge.net Tue Sep 12 22:01:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 13:01:31 -0700 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 07:38 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Closed Resolution: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-09-12 15:01 Message: Logged In: YES user_id=44345 I'm coming late to this party (it seems the bar is closed), however... At work we just stumbled upon a similar problem when trying to build the latest release of matplotlib (0.87.5, avaialble at http://matplotlib.sourceforge.net/) on Solaris 10 using gcc 3.4.1. We get errors like the following: In file included from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/bits/postypes.h:46, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iosfwd:50, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ios:44, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ostream:45, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iostream:45, from swig/agg_buffer.h:7, from src/agg.cxx:1584: /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:145: error: `::btowc' has not been declared /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:150: error: `::fwide' has not been declared If I add #include at the top of Python.h it builds fine (modulo a couple warnings). One warning which might be significant is: In file included from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:10, from src/agg.cxx:97: /opt/app/g++lib6/python-2.4/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/wchar.h:11, from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:7, from src/agg.cxx:97: /usr/include/sys/feature_tests.h:266:1: warning: this is the location of the previous definition I don't have enough gcc smarts to understand what's happening, or even if it's the same problem Dimitri encountered on Solaris 8, but it kind of looks like the same sort of problem to me. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-03 15:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 04:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 02:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-01 22:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 08:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Tue Sep 12 23:36:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 14:36:50 -0700 Subject: [ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Message-ID: Bugs item #1557490, was opened at 2006-09-12 17:36 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=1557490&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 Submitted By: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu .... Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 From noreply at sourceforge.net Wed Sep 13 00:12:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 15:12:34 -0700 Subject: [ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars Message-ID: Bugs item #1556784, was opened at 2006-09-11 22:43 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&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 Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: [I'm putting this in category Python Library, because I assume Extensions Modules is for problems in the Extensions Module plumbing.] datetime.date and datetime.time's strftime() methods call wrap_strftime(), which limits the length of the format string to 127 chars before calling time.strftime(). This can be seen in the examples below. Note that in the third example, time.strftime() does not have a problem with a 128 character format string. >>> import datetime >>> datetime.date.today().strftime('x'*128) Traceback (most recent call last): File "", line 1, in MemoryError >>> import datetime >>> datetime.date.today().strftime('x'*256) Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows. ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2006-09-12 18:12 Message: Logged In: YES user_id=411198 See patch http://python.org/sf/1557390 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&group_id=5470 From noreply at sourceforge.net Wed Sep 13 07:47:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 22:47:27 -0700 Subject: [ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Message-ID: Bugs item #1557490, was opened at 2006-09-12 14:36 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&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 Submitted By: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu .... Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:47 Message: Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 From noreply at sourceforge.net Wed Sep 13 07:50:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 22:50:28 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Wed Sep 13 08:00:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 23:00:18 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Wed Sep 13 08:22:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 23:22:09 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the ((((x)))) problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Wed Sep 13 09:44:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 00:44:52 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 00:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the ((((x)))) problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Wed Sep 13 15:12:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 06:12:12 -0700 Subject: [ python-Bugs-779460 ] plistlib should be moved out of plat-mac Message-ID: Bugs item #779460, was opened at 2003-07-29 11:01 Message generated for change (Comment added) made by guidog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&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 Submitted By: Sarwat Khan (sarwatfoo) Assigned to: Nobody/Anonymous (nobody) Summary: plistlib should be moved out of plat-mac Initial Comment: plistlib doesn't (I think, it shouldn't anyway) have any Mac dependancies and should be moved out of plat-mac so plists can be generated and parsed on non-Mac platforms. I intend to use it, for example, on a Linux web server in CGI scripts for basic XML handling. ---------------------------------------------------------------------- Comment By: Guido Guenther (guidog) Date: 2006-09-13 15:12 Message: Logged In: YES user_id=696207 Can this be done for python 2.5 please. It's need to run apple's caldav server on e.g. Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&group_id=5470 From noreply at sourceforge.net Wed Sep 13 17:32:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 08:32:56 -0700 Subject: [ python-Bugs-1557983 ] xlc 6 does not like bufferobject.c line22 Message-ID: Bugs item #1557983, was opened at 2006-09-13 15:32 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=1557983&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: prueba uno (pruebauno) Assigned to: Nobody/Anonymous (nobody) Summary: xlc 6 does not like bufferobject.c line22 Initial Comment: The VisualAge 6 Compiler on AIX complains about the extra comma on line 22 of bufferobject. Doing the following change keeps the compiler happy. enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, - ANY_BUFFER, }; enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, + ANY_BUFFER }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470 From noreply at sourceforge.net Wed Sep 13 17:49:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 08:49:28 -0700 Subject: [ python-Bugs-1557983 ] xlc 6 does not like bufferobject.c line22 Message-ID: Bugs item #1557983, was opened at 2006-09-13 17:32 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: prueba uno (pruebauno) Assigned to: Nobody/Anonymous (nobody) Summary: xlc 6 does not like bufferobject.c line22 Initial Comment: The VisualAge 6 Compiler on AIX complains about the extra comma on line 22 of bufferobject. Doing the following change keeps the compiler happy. enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, - ANY_BUFFER, }; enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, + ANY_BUFFER }; ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2006-09-13 17:49 Message: Logged In: YES user_id=43607 That's a bug in the compiler, not in Python. The C standard has: enum-speci?er: enum identi?eropt { enumerator-list } enum identi?eropt { enumerator-list , } enum identi?er enumerator-list: enumerator enumerator-list , enumerator enumerator: enumeration-constant enumeration-constant = constant-expression >From the first production you can see that the comma at the end is allowed. This has been true since at least 1980. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470 From noreply at sourceforge.net Wed Sep 13 17:50:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 08:50:39 -0700 Subject: [ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Message-ID: Bugs item #1557490, was opened at 2006-09-12 17:36 Message generated for change (Comment added) made by tony_bigbee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&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 Submitted By: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu .... Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. ---------------------------------------------------------------------- >Comment By: Tony Bigbee (tony_bigbee) Date: 2006-09-13 11:50 Message: Logged In: YES user_id=1478976 I have confirmed that gcc 3.4.2 also successfully builds an ELF 64-bit for 2.5c2 and the interpreter works. Putting the sparcv9 64-bit shared libraries first in LD_LIBRARY_PATH also fixes the extension building problem nnorwitz noted. Only a few extension modules fail to build (per the 2.5 Release Candidate 2 news item) because of dependence of 32-bit ELF class .sos: _tkinter (libtk8.4.so, libtcl8.4.so) _sqlite3 (libsqlite3.so) _ssl ((libcrypto.a(digest.o)) _hashlib (libcrypto.a(digest.o)) bz2 (libbz2.a(bzlib.o)) But this might be fixed by recompiling these libraries as 64-bit. LD_LIBRARY_PATH=/usr/lib/sparcv9:/usr/local/lib/sparcv9: ... Will report back results attempting 4.0.2 and LD_LIBRARY_PATH modification to see if extension modules can be built to mirror 3.4.2 results. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 01:47 Message: Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 From noreply at sourceforge.net Wed Sep 13 19:35:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 10:35:55 -0700 Subject: [ python-Bugs-1558072 ] 'setup.py install' crashes when installing python-bibtex Message-ID: Bugs item #1558072, was opened at 2006-09-13 19:35 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=1558072&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matejcik (spektrum) Assigned to: Nobody/Anonymous (nobody) Summary: 'setup.py install' crashes when installing python-bibtex Initial Comment: when installing python-bibtex (http://sourceforge.net/project/showfiles.php?group_id=4825&package_id=93590&release_id=361584) , python crashes as follows: titan:/tmp/python-bibtex-1.2.2# python setup.py install running install running check running build running build_ext *** glibc detected *** python: munmap_chunk(): invalid pointer: 0xb7c530b0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7d379e2] /tmp/python-bibtex-1.2.2/build/lib.linux-i686-2.5/_bibtex.so[0xb7839f15] /usr/lib/libpython2.5.so.1.0[0xb7e737ea] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x473)[0xb7ecf393] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0xb7ecf763] /usr/lib/libpython2.5.so.1.0[0xb7ee7ad6] /usr/lib/libpython2.5.so.1.0(PyRun_FileExFlags+0x8e)[0xb7ee7b8e] /usr/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xb7ee9218] /usr/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0xb7ee997a] /usr/lib/libpython2.5.so.1.0(Py_Main+0xa23)[0xb7ef2e13] python(main+0x32)[0x80485f2] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7ce987c] python[0x8048531] ======= Memory map: ======== Ne?sp??n? ukon?en (SIGABRT) (This is after 'python setup.py build' successfully finished) Machine is i386, python is compiled with -D_FORTIFY_SOURCE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 From noreply at sourceforge.net Wed Sep 13 20:55:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 11:55:20 -0700 Subject: [ python-Bugs-1552892 ] ConfigParser converts option names to lower case on set() Message-ID: Bugs item #1552892, was opened at 2006-09-05 11:35 Message generated for change (Comment added) made by suslik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&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.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: daniel (suslik) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser converts option names to lower case on set() Initial Comment: Python 2.4.2 Using set() in ConfigParser module converts all characters in option names to lower case. To reproduce: >>> import ConfigParser >>> cfg = ConfigParser.ConfigParser() >>> cfg.add_section('SectioN') >>> cfg.set('SectioN','OpTiOn","ValuE') >>> cfg.items('SectioN') [('option', 'ValuE')] ---------------------------------------------------------------------- >Comment By: daniel (suslik) Date: 2006-09-13 11:55 Message: Logged In: YES user_id=633916 Hmm, "broken" behavior by-design or not - it still makes it impossible to use ConfigParser straight out in KDE, where almost all option names are AaaaBbbbCccc. I just went with a completely different parser. http://wiki.python.org/moin/ConfigParserShootout ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 22:53 Message: Logged In: YES user_id=849994 Mark is correct. This is not a bug. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-09-05 20:30 Message: Logged In: YES user_id=1591633 I can reproduce this on Win XP, Python 2.4, however, it doesn't seem to be a bug. In the docs (http://docs.python.org/lib/module-ConfigParser.html), it states that "All option names used in interpolation will be passed through the optionxform() method just like any other option name reference. For example, using the default implementation of optionxform() (which converts option names to lower case), the values "foo %(bar)s" and "foo %(BAR)s" are equivalent." You might consider subclassing if this is an inconvenience for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470 From noreply at sourceforge.net Thu Sep 14 00:05:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 15:05:47 -0700 Subject: [ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump Message-ID: Bugs item #1558223, was opened at 2006-09-14 00:05 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=1558223&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.4 Status: Open Resolution: None Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 From noreply at sourceforge.net Thu Sep 14 05:34:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 20:34:04 -0700 Subject: [ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump Message-ID: Bugs item #1558223, was opened at 2006-09-13 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 20:34 Message: Logged In: YES user_id=33168 Please file this bug report with mod_python. That's typically the cause and it will likely be very hard for any Python developer to create this setup and much less try to reproduce the error. If you can provoke the same error without mod_python or other third party C extensions, please file a bug report with the minimal test case to reproduce. If you need a work-around, I would suggest changing to a different version of mod_python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 From noreply at sourceforge.net Thu Sep 14 05:39:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 20:39:05 -0700 Subject: [ python-Bugs-1558072 ] 'setup.py install' crashes when installing python-bibtex Message-ID: Bugs item #1558072, was opened at 2006-09-13 10:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matejcik (spektrum) Assigned to: Nobody/Anonymous (nobody) Summary: 'setup.py install' crashes when installing python-bibtex Initial Comment: when installing python-bibtex (http://sourceforge.net/project/showfiles.php?group_id=4825&package_id=93590&release_id=361584) , python crashes as follows: titan:/tmp/python-bibtex-1.2.2# python setup.py install running install running check running build running build_ext *** glibc detected *** python: munmap_chunk(): invalid pointer: 0xb7c530b0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7d379e2] /tmp/python-bibtex-1.2.2/build/lib.linux-i686-2.5/_bibtex.so[0xb7839f15] /usr/lib/libpython2.5.so.1.0[0xb7e737ea] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x473)[0xb7ecf393] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0xb7ecf763] /usr/lib/libpython2.5.so.1.0[0xb7ee7ad6] /usr/lib/libpython2.5.so.1.0(PyRun_FileExFlags+0x8e)[0xb7ee7b8e] /usr/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xb7ee9218] /usr/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0xb7ee997a] /usr/lib/libpython2.5.so.1.0(Py_Main+0xa23)[0xb7ef2e13] python(main+0x32)[0x80485f2] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7ce987c] python[0x8048531] ======= Memory map: ======== Ne?sp??n? ukon?en (SIGABRT) (This is after 'python setup.py build' successfully finished) Machine is i386, python is compiled with -D_FORTIFY_SOURCE ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 20:39 Message: Logged In: YES user_id=33168 I notice the second to last stack frame is in _bibtex.so. Please file a bug report with python-bibtex. If you can verify the problem doesn't occur with any third party C extensions, please create a bug with a minimal test case. This should be much easier for a python-bibtex developer to debug than a Python developer. It's typically also the case that these sorts of problems are in third party extensions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 From noreply at sourceforge.net Thu Sep 14 15:22:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 06:22:47 -0700 Subject: [ python-Bugs-1557983 ] xlc 6 does not like bufferobject.c line22 Message-ID: Bugs item #1557983, was opened at 2006-09-13 15:32 Message generated for change (Comment added) made by pruebauno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: prueba uno (pruebauno) Assigned to: Nobody/Anonymous (nobody) Summary: xlc 6 does not like bufferobject.c line22 Initial Comment: The VisualAge 6 Compiler on AIX complains about the extra comma on line 22 of bufferobject. Doing the following change keeps the compiler happy. enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, - ANY_BUFFER, }; enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, + ANY_BUFFER }; ---------------------------------------------------------------------- >Comment By: prueba uno (pruebauno) Date: 2006-09-14 13:22 Message: Logged In: YES user_id=30777 All right, I guess I have to complain to IBM then :-) ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-09-13 15:49 Message: Logged In: YES user_id=43607 That's a bug in the compiler, not in Python. The C standard has: enum-speci?er: enum identi?eropt { enumerator-list } enum identi?eropt { enumerator-list , } enum identi?er enumerator-list: enumerator enumerator-list , enumerator enumerator: enumeration-constant enumeration-constant = constant-expression >From the first production you can see that the comma at the end is allowed. This has been true since at least 1980. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470 From noreply at sourceforge.net Thu Sep 14 19:51:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 10:51:13 -0700 Subject: [ python-Bugs-1558802 ] Tru64 make install failure Message-ID: Bugs item #1558802, was opened at 2006-09-14 10:51 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=1558802&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 make install failure Initial Comment: "make install" of Python 2.5c2 fails under Tru64 Unix V5.1. The failure is fixed by the simple patch below. I.e., simply remove two lines from Makefile.pre.in. Apparently the native make doesn't support comments where commands are expected. diff -r -u Python-2.5c2/Makefile.pre.in Python-2.5c2_cci/Makefile.pre.in --- Python-2.5c2/Makefile.pre.in 2006-07-30 09:20:10.000000000 -0700 +++ Python-2.5c2_cci/Makefile.pre.in 2006-09-14 10:17:12.000000000 -0700 @@ -850,8 +850,6 @@ $(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config $(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup $(DESTDIR)$(LIBPL)/makesetup $(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh - # Substitution happens here, as the completely-expanded BINDIR - # is not available in configure sed -e "s, at EXENAME@,$(BINDIR)/python$(VERSION)$(EXE)," < $(srcdir)/Misc/python-config.in >python-config $(INSTALL_SCRIPT) python-config $(DESTDIR)$(BINDIR)/python$(VERSION)-config rm python-config ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&group_id=5470 From noreply at sourceforge.net Thu Sep 14 23:03:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 14:03:43 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by dstrozzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 17:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 13:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 12:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 11:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 11:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Thu Sep 14 23:10:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 14:10:15 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 23:10 Message: Logged In: YES user_id=580910 The scary bit is that the bug was "fixed" due to unclear differences between the build environment used for 2.5c1 and 2.5c2. I'll be building 2.5final as well, so expect this will stay fixed but I'm not entirely happy due to not knowing what caused the failure in the first place. It looks like 2.5c1 was build with a slighly different version of GCC (although both machines has Xcode 2.3 installed). BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this weekend. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 23:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 19:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 17:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Thu Sep 14 23:16:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 14:16:10 -0700 Subject: [ python-Bugs-1552935 ] Pythonw doesn't get rebuilt if version number changes Message-ID: Bugs item #1552935, was opened at 2006-09-05 21:37 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&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: Macintosh >Group: Python 2.6 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Pythonw doesn't get rebuilt if version number changes Initial Comment: If the Python version number changes (as it did this week) Mac/pythonw should get rebuilt so it fires up the correct real Python executable. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 23:16 Message: Logged In: YES user_id=580910 pythonw should depend on the Makefile and the Makefile should be automaticly rebuild when config.status changes (just like the toplevel Makefile). I'll check in a patch this weekend, I need to test before I do the checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&group_id=5470 From noreply at sourceforge.net Fri Sep 15 01:45:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 16:45:10 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 19:45 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=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan (evanpowers) Assigned to: Jack Jansen (jackjansen) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Fri Sep 15 06:29:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 21:29:08 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 16:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan (evanpowers) >Assigned to: Anthony Baxter (anthonybaxter) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 21:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Fri Sep 15 06:29:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 21:29:25 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 16:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan (evanpowers) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 21:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 21:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Fri Sep 15 06:30:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 21:30:14 -0700 Subject: [ python-Bugs-1558802 ] Tru64 make install failure Message-ID: Bugs item #1558802, was opened at 2006-09-14 10:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Tru64 make install failure Initial Comment: "make install" of Python 2.5c2 fails under Tru64 Unix V5.1. The failure is fixed by the simple patch below. I.e., simply remove two lines from Makefile.pre.in. Apparently the native make doesn't support comments where commands are expected. diff -r -u Python-2.5c2/Makefile.pre.in Python-2.5c2_cci/Makefile.pre.in --- Python-2.5c2/Makefile.pre.in 2006-07-30 09:20:10.000000000 -0700 +++ Python-2.5c2_cci/Makefile.pre.in 2006-09-14 10:17:12.000000000 -0700 @@ -850,8 +850,6 @@ $(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config $(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup $(DESTDIR)$(LIBPL)/makesetup $(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh - # Substitution happens here, as the completely-expanded BINDIR - # is not available in configure sed -e "s, at EXENAME@,$(BINDIR)/python$(VERSION)$(EXE)," < $(srcdir)/Misc/python-config.in >python-config $(INSTALL_SCRIPT) python-config $(DESTDIR)$(BINDIR)/python$(VERSION)-config rm python-config ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 21:30 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&group_id=5470 From noreply at sourceforge.net Fri Sep 15 10:17:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 01:17:20 -0700 Subject: [ python-Bugs-1559142 ] some section links (previous, up, next) missing last word Message-ID: Bugs item #1559142, was opened at 2006-09-15 04:17 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=1559142&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 Submitted By: Tim Smith (thimsmith) Assigned to: Nobody/Anonymous (nobody) Summary: some section links (previous, up, next) missing last word Initial Comment: The Previous, Up and Next links in the Library Reference are often missing the last word. Examples: http://www.python.org/doc/current/lib/module-operator.html """Previous: 3.9 UserString Up: 3. Python Runtime Services Next: 3.10.1 Mapping Operators to """ (Next link missing last word "Functions".) http://www.python.org/doc/current/lib/weakref-example.html """Previous: 3.3.1 Weak Reference Objects Up: 3.3 weakref Next: 3.3.3 Weak References in """ (Next link missing last two words "Extension Types".) There are *many* examples of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 From noreply at sourceforge.net Fri Sep 15 17:58:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 08:58:23 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 19:45 Message generated for change (Comment added) made by evanpowers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Evan (evanpowers) Date: 2006-09-15 11:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Fri Sep 15 18:19:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 09:19:56 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-15 01:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 18:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 17:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Fri Sep 15 20:08:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 11:08:54 -0700 Subject: [ python-Bugs-1559515 ] time.strptime() access non exitant attribute in calendar.py Message-ID: Bugs item #1559515, was opened at 2006-09-15 18:08 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=1559515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: betatim (thead) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() access non exitant attribute in calendar.py Initial Comment: >>> import time >>> time.strptime(time.ctime()) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 74, in __init__ self.__calc_weekday() File "/usr/lib/python2.4/_strptime.py", line 94, in __calc_weekday a_weekday = [calendar.day_abbr[i].lower() for i in range(7)] AttributeError: 'module' object has no attribute 'day_abbr' >>> time.ctime() 'Fri Sep 15 19:06:18 2006' The default format used by strptime() should match the output of ctime(). Even when specifying the format I get exactly the same error. I have recently upgraded to gcc 4.1.1 and glibc-2.4-r3. Using python-2.4.3. I am not quite sure what causes this. cheers tim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 From noreply at sourceforge.net Fri Sep 15 20:09:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 11:09:32 -0700 Subject: [ python-Bugs-1559515 ] time.strptime() access non existant attribute in calendar.py Message-ID: Bugs item #1559515, was opened at 2006-09-15 18:08 Message generated for change (Settings changed) made by thead You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: betatim (thead) Assigned to: Nobody/Anonymous (nobody) >Summary: time.strptime() access non existant attribute in calendar.py Initial Comment: >>> import time >>> time.strptime(time.ctime()) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 74, in __init__ self.__calc_weekday() File "/usr/lib/python2.4/_strptime.py", line 94, in __calc_weekday a_weekday = [calendar.day_abbr[i].lower() for i in range(7)] AttributeError: 'module' object has no attribute 'day_abbr' >>> time.ctime() 'Fri Sep 15 19:06:18 2006' The default format used by strptime() should match the output of ctime(). Even when specifying the format I get exactly the same error. I have recently upgraded to gcc 4.1.1 and glibc-2.4-r3. Using python-2.4.3. I am not quite sure what causes this. cheers tim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 From noreply at sourceforge.net Fri Sep 15 21:04:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 12:04:09 -0700 Subject: [ python-Bugs-1559515 ] time.strptime() access non existant attribute in calendar.py Message-ID: Bugs item #1559515, was opened at 2006-09-15 18:08 Message generated for change (Comment added) made by thead You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: betatim (thead) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() access non existant attribute in calendar.py Initial Comment: >>> import time >>> time.strptime(time.ctime()) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 74, in __init__ self.__calc_weekday() File "/usr/lib/python2.4/_strptime.py", line 94, in __calc_weekday a_weekday = [calendar.day_abbr[i].lower() for i in range(7)] AttributeError: 'module' object has no attribute 'day_abbr' >>> time.ctime() 'Fri Sep 15 19:06:18 2006' The default format used by strptime() should match the output of ctime(). Even when specifying the format I get exactly the same error. I have recently upgraded to gcc 4.1.1 and glibc-2.4-r3. Using python-2.4.3. I am not quite sure what causes this. cheers tim ---------------------------------------------------------------------- >Comment By: betatim (thead) Date: 2006-09-15 19:04 Message: Logged In: YES user_id=1231298 to make sure there wasn't anything boviously wrong with my time and strptime i run test_time.py and test_strptime.py both of which have passed all tests ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 From noreply at sourceforge.net Fri Sep 15 21:41:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 12:41:29 -0700 Subject: [ python-Bugs-1559515 ] time.strptime() access non existant attribute in calendar.py Message-ID: Bugs item #1559515, was opened at 2006-09-15 11:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: betatim (thead) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() access non existant attribute in calendar.py Initial Comment: >>> import time >>> time.strptime(time.ctime()) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 74, in __init__ self.__calc_weekday() File "/usr/lib/python2.4/_strptime.py", line 94, in __calc_weekday a_weekday = [calendar.day_abbr[i].lower() for i in range(7)] AttributeError: 'module' object has no attribute 'day_abbr' >>> time.ctime() 'Fri Sep 15 19:06:18 2006' The default format used by strptime() should match the output of ctime(). Even when specifying the format I get exactly the same error. I have recently upgraded to gcc 4.1.1 and glibc-2.4-r3. Using python-2.4.3. I am not quite sure what causes this. cheers tim ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-09-15 12:41 Message: Logged In: YES user_id=357491 Tested on Python 2.4, 2.5, and trunk and all work for me. Closing as invalid. If you look at the traceback there is an issue with the calendar module in your installation, not with time.strptime() (looks like calendar.day_abbr is missing). I would run test_calendar and see what happens with that. If that test fails then file a bug report on that (and maybe also test_datetime since that is where the calendar module gets its information for the day-abbr). ---------------------------------------------------------------------- Comment By: betatim (thead) Date: 2006-09-15 12:04 Message: Logged In: YES user_id=1231298 to make sure there wasn't anything boviously wrong with my time and strptime i run test_time.py and test_strptime.py both of which have passed all tests ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559515&group_id=5470 From noreply at sourceforge.net Fri Sep 15 21:55:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 12:55:04 -0700 Subject: [ python-Feature Requests-1559549 ] Exception need structured information associated with them Message-ID: Feature Requests item #1559549, was opened at 2006-09-15 15:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&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 Submitted By: Ned Batchelder (nedbat) Assigned to: Nobody/Anonymous (nobody) Summary: Exception need structured information associated with them Initial Comment: Exceptions would be more useful if they had some structured information attached to them. For example, an ImportError could have the name of the module that could not be imported. This would make it possible to deal with exceptions in more powerful ways. For more discussion: http://www.nedbatchelder.com/blog/200609.html#e20060906T055924 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&group_id=5470 From noreply at sourceforge.net Fri Sep 15 21:55:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 12:55:25 -0700 Subject: [ python-Feature Requests-1559549 ] Exceptions need structured information associated with them Message-ID: Feature Requests item #1559549, was opened at 2006-09-15 15:55 Message generated for change (Settings changed) made by nedbat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&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 Submitted By: Ned Batchelder (nedbat) Assigned to: Nobody/Anonymous (nobody) >Summary: Exceptions need structured information associated with them Initial Comment: Exceptions would be more useful if they had some structured information attached to them. For example, an ImportError could have the name of the module that could not be imported. This would make it possible to deal with exceptions in more powerful ways. For more discussion: http://www.nedbatchelder.com/blog/200609.html#e20060906T055924 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&group_id=5470 From noreply at sourceforge.net Sat Sep 16 01:24:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 16:24:12 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 19:45 Message generated for change (Comment added) made by evanpowers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Evan (evanpowers) Date: 2006-09-15 19:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 12:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 11:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sat Sep 16 07:13:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 22:13:42 -0700 Subject: [ python-Bugs-1559684 ] shutil.copyfile incomplete on NTFS Message-ID: Bugs item #1559684, was opened at 2006-09-16 00: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=1559684&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfile incomplete on NTFS Initial Comment: Files on NTFS 5 volumes can contain multiple data streams. Copyfile currently just reads the default unnamed stream, losing document summary information and any named streams that have been added to the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559684&group_id=5470 From noreply at sourceforge.net Sat Sep 16 13:28:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 04:28:50 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&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: 9 Submitted By: Jack Howarth (jwhowarth) >Assigned to: Neal Norwitz (nnorwitz) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-09-16 11:28 Message: Logged In: YES user_id=4771 More of the same kind of problem: abs(-sys.maxint-1) sometimes gives -sys.maxint-1. It would be a good idea to review all places that need to special-case -sys.maxint-1 for overflow detection. (It would be a still better idea to review all overflow detection code, but that may have to wait after the 2.5 release). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 04:04 Message: Logged In: YES user_id=33168 Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4. ---------------------------------------------------------------------- Comment By: David Hopwood (dhopwood) Date: 2006-08-26 23:24 Message: Logged In: YES user_id=634468 The correct patch is the one that uses if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x) The one that uses (unsigned int)x will break some 64-bit platforms where int != long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 20:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 20:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 15:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 15:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 14:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 14:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 14:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 11:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 09:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Sat Sep 16 14:15:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 05:15:31 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 12:15 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=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 14:20:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 05:20:15 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 12:15 Message generated for change (Comment added) made by rplatten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- >Comment By: Ron Platten (rplatten) Date: 2006-09-16 12:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 18:46:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 09:46:46 -0700 Subject: [ python-Bugs-1559818 ] list.sort does nothing when both cmp and key are given Message-ID: Bugs item #1559818, was opened at 2006-09-16 18: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=1559818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: list.sort does nothing when both cmp and key are given Initial Comment: Python 2.5c1 (r25c1:51305, Sep 3 2006, 12:19:21) [GCC 4.2.0 20060806 (experimental) (PLD-Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = [1, 200, 30] >>> x.sort(lambda x, y: x>> x [1, 200, 30] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559818&group_id=5470 From noreply at sourceforge.net Sat Sep 16 18:50:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 09:50:53 -0700 Subject: [ python-Bugs-1559818 ] list.sort does nothing when both cmp and key are given Message-ID: Bugs item #1559818, was opened at 2006-09-16 18:46 Message generated for change (Comment added) made by qrczak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559818&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: list.sort does nothing when both cmp and key are given Initial Comment: Python 2.5c1 (r25c1:51305, Sep 3 2006, 12:19:21) [GCC 4.2.0 20060806 (experimental) (PLD-Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = [1, 200, 30] >>> x.sort(lambda x, y: x>> x [1, 200, 30] ---------------------------------------------------------------------- >Comment By: Marcin 'Qrczak' Kowalczyk (qrczak) Date: 2006-09-16 18:50 Message: Logged In: YES user_id=50234 Oops, sorry, I forgot that cmp is a three-way comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559818&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:23:41 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 14:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:23 Message: Logged In: YES user_id=21627 How do you know that pythonw does not execute? It works fine for me (and, indeed, IDLE is started with pythonw). ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 14:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:29:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:29:23 -0700 Subject: [ python-Bugs-1559684 ] shutil.copyfile incomplete on NTFS Message-ID: Bugs item #1559684, was opened at 2006-09-16 07:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559684&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfile incomplete on NTFS Initial Comment: Files on NTFS 5 volumes can contain multiple data streams. Copyfile currently just reads the default unnamed stream, losing document summary information and any named streams that have been added to the file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:29 Message: Logged In: YES user_id=21627 copyfile indeed fails to copy a lot of attributes of the file, e.g. the file owner and group are not copied, and neither are the ACLs. Unfortunately, it is not possible to implement a full copy; shutil.copyfile has always only copied the file contents. To implement a full copy, more Win32 would need to be exposed. Use the CopyFile function from the Win32 extensions for a full copy. Reclassifying this as a documentation bug: the documentation should mention that this only copies the direct file contents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559684&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:33:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:33:05 -0700 Subject: [ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Message-ID: Bugs item #1557490, was opened at 2006-09-12 23:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&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 Submitted By: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu .... Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:33 Message: Logged In: YES user_id=21627 If this is indeed compiler-dependent, it will be very difficult to analyse: it could be a compiler bug (i.e. the compiler generating bad code), or it could be a Python bug (the Python C code not being fully portable or correct). ---------------------------------------------------------------------- Comment By: Tony Bigbee (tony_bigbee) Date: 2006-09-13 17:50 Message: Logged In: YES user_id=1478976 I have confirmed that gcc 3.4.2 also successfully builds an ELF 64-bit for 2.5c2 and the interpreter works. Putting the sparcv9 64-bit shared libraries first in LD_LIBRARY_PATH also fixes the extension building problem nnorwitz noted. Only a few extension modules fail to build (per the 2.5 Release Candidate 2 news item) because of dependence of 32-bit ELF class .sos: _tkinter (libtk8.4.so, libtcl8.4.so) _sqlite3 (libsqlite3.so) _ssl ((libcrypto.a(digest.o)) _hashlib (libcrypto.a(digest.o)) bz2 (libbz2.a(bzlib.o)) But this might be fixed by recompiling these libraries as 64-bit. LD_LIBRARY_PATH=/usr/lib/sparcv9:/usr/local/lib/sparcv9: ... Will report back results attempting 4.0.2 and LD_LIBRARY_PATH modification to see if extension modules can be built to mirror 3.4.2 results. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 07:47 Message: Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:43:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:43:22 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 12:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-16 17:43 Message: Logged In: YES user_id=849994 If pythonw.exe is started without any argument, is it supposed to do anything? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 17:23 Message: Logged In: YES user_id=21627 How do you know that pythonw does not execute? It works fine for me (and, indeed, IDLE is started with pythonw). ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 12:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:52:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:52:11 -0700 Subject: [ python-Feature Requests-1559549 ] ImportError needs attributes for module and file name Message-ID: Feature Requests item #1559549, was opened at 2006-09-15 21:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&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 Submitted By: Ned Batchelder (nedbat) Assigned to: Nobody/Anonymous (nobody) >Summary: ImportError needs attributes for module and file name Initial Comment: Exceptions would be more useful if they had some structured information attached to them. For example, an ImportError could have the name of the module that could not be imported. This would make it possible to deal with exceptions in more powerful ways. For more discussion: http://www.nedbatchelder.com/blog/200609.html#e20060906T055924 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:52 Message: Logged In: YES user_id=21627 Exceptions do have structured informations, for example py> try: ... open("/tmp/xxx") ... except IOError, e: ... print e.__dict__ ... {'errno': 2, 'args': (2, 'No such file or directory'), 'strerror': 'No such file or directory', 'filename': '/tmp/xxx'} It's just that ImportError doesn't, so I'm retitling this request to restrict attention to ImportError. If you have other proposals for specific information that should be on specific exceptions, please submit a separate issue. Would you like to work on this specific problem? I think ImportError should get a module attribute (always set), and a filename attribute (set only if a file was selected, yet failed to import; otherwise set to None). It probably will require some refactoring of C code to simplify raising ImportError in the importing code. Explicit raises of ImportError should also be considered; those in the standard library should be fixed to include atleast the module; raising ImportError without giving a module should set the module to None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1559549&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:55:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:55:26 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 14:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:55 Message: Logged In: YES user_id=21627 If pythonw is started without an argument, it immediately quits. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-16 19:43 Message: Logged In: YES user_id=849994 If pythonw.exe is started without any argument, is it supposed to do anything? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:23 Message: Logged In: YES user_id=21627 How do you know that pythonw does not execute? It works fine for me (and, indeed, IDLE is started with pythonw). ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 14:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 22:45:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 13:45:50 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 12:15 Message generated for change (Comment added) made by rplatten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- >Comment By: Ron Platten (rplatten) Date: 2006-09-16 20:45 Message: Logged In: YES user_id=769736 In that case, it must be working perfectly. IDLE does work OK. I thought that clicking on pythonw used to start the program, but it must be OK now. Sorry for the comment. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 17:55 Message: Logged In: YES user_id=21627 If pythonw is started without an argument, it immediately quits. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-16 17:43 Message: Logged In: YES user_id=849994 If pythonw.exe is started without any argument, is it supposed to do anything? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 17:23 Message: Logged In: YES user_id=21627 How do you know that pythonw does not execute? It works fine for me (and, indeed, IDLE is started with pythonw). ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 12:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sat Sep 16 23:04:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 14:04:48 -0700 Subject: [ python-Bugs-1559747 ] 2.5c2 pythonw does not execute Message-ID: Bugs item #1559747, was opened at 2006-09-16 14:15 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Ron Platten (rplatten) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c2 pythonw does not execute Initial Comment: After installation of the .msi installer, pythonw.exe will not execute. Also, IDLE no longer appears anywhere. ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 22:45 Message: Logged In: YES user_id=769736 In that case, it must be working perfectly. IDLE does work OK. I thought that clicking on pythonw used to start the program, but it must be OK now. Sorry for the comment. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:55 Message: Logged In: YES user_id=21627 If pythonw is started without an argument, it immediately quits. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-16 19:43 Message: Logged In: YES user_id=849994 If pythonw.exe is started without any argument, is it supposed to do anything? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:23 Message: Logged In: YES user_id=21627 How do you know that pythonw does not execute? It works fine for me (and, indeed, IDLE is started with pythonw). ---------------------------------------------------------------------- Comment By: Ron Platten (rplatten) Date: 2006-09-16 14:20 Message: Logged In: YES user_id=769736 IDLE does appear and works fine. Sorry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559747&group_id=5470 From noreply at sourceforge.net Sun Sep 17 08:22:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 23:22:07 -0700 Subject: [ python-Bugs-1560032 ] confusing error msg from random.randint Message-ID: Bugs item #1560032, was opened at 2006-09-17 06:22 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=1560032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: confusing error msg from random.randint Initial Comment: See the following output. The reason for the confusing message is that random.randint is actually a bound method to a Random instance inside the module, i.e. someone got a little bit too clever. It should be an ordinary function that calls that instance method instead. >>> import random >>> random.randint(10000) Traceback (most recent call last): File "", line 1, in ? TypeError: randint() takes exactly 3 arguments (2 given) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560032&group_id=5470 From noreply at sourceforge.net Sun Sep 17 13:47:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 04:47:29 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-15 01:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 13:47 Message: Logged In: YES user_id=580910 I've uploaded a new installer to http://homagepages.mac.com/ ronaldoussoren, its the file python-2.5c2-macosx2006-09-17.dmg. Could you please test if this fixes the installation problems for you? I'd really appricate if you could post the contents of the installer log if installation failed (in Installer.app use the menu File -> Show Log, then select 'Show Everything', save that file and add it to this bug). This version has two minor changes w.r.t. the previous one: 1) the application subpackage won't try to install a custom icon on the MacPython 2.5 folder. After reading some pages on the interweb I'm starting to believe that installing a custom icon will require a postinstall script and that's not something I want to add at this point of the release cycle (if ever). 2) the fixsystempython subpackage won't abort the installation when the system python's Makefile was patched by someone else. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-16 01:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 18:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 17:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sun Sep 17 14:24:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 05:24:02 -0700 Subject: [ python-Bugs-1560114 ] Tutorial: incorrect info about package importing and mac Message-ID: Bugs item #1560114, was opened at 2006-09-17 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&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 Submitted By: C L (cl_) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: incorrect info about package importing and mac Initial Comment: Section 6.4.1 of the Python tutorial says: "Now what happens when the user writes from Sound.Effects import *? Ideally, one would hope that this somehow goes out to the filesystem, finds which submodules are present in the package, and imports them all. Unfortunately, this operation does not work very well on Mac and Windows platforms, where the filesystem does not always have accurate information about the case of a filename! On these platforms, there is no guaranteed way to know whether a file ECHO.PY should be imported as a module echo, Echo or ECHO." This is incorrect. It's true that the (default *) Mac file system does not allow file names differing only in case in the same directory, and lets you access a file by any variation of case; but the file system always records and returns the file name with the exact capitalization that was given when the name was assigned. In other words, if you create a file called "MixedCase.py" you can access it as "mixedcase.py", "MiXeDcAsE.pY" etc., but if you list the contents of its parent directory the name will always be given as "MixedCase.py". This has been true of all versions of the Mac OS going back to System 1.0. Therefore, none of that paragraph applies to any Mac system; on the contrary, the file system always has accurate information about the case of a file name. That section of the text should be changed to remove the reference to the Mac platform. (*: recent Mac OS X systems also allow one to use the HFSX filesystem variant, which allows file names differing only in case and matches file names only when the case is exactly identical - ie, the fully case-sensitive Unix semantics. But again, this has no bearing on the ability to reliably obtain the exact case of the name of a file.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470 From noreply at sourceforge.net Sun Sep 17 16:09:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 07:09:20 -0700 Subject: [ python-Bugs-1560161 ] Better/faster implementation of os.path.split Message-ID: Bugs item #1560161, was opened at 2006-09-17 14:09 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=1560161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.split Initial Comment: hi, os.path.split is quite bad regarding performance on long pathnames: def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] if head and head != '/'*len(head): head = head.rstrip('/') return head, tail especially this: '/'*len(head) this constructs an unnecessary string sometimes thousands of chars long. better would be: if head and len(head) != head.count('/') BUT: what is this 'if head and head != '/'*len(head):' for? this if is imho useless, because if head exists and is not all '/' => rstrip '/' imho better would be: rstrip '/' from head and if head is empty add a '/' would be the same effect, because a singel '/' is just the same as a path as '/'*len(head). def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] head = head.rstrip('/') if not head: head = '/' return head, tail such a implementation would be ways faster for long pathnames. greets, michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 From noreply at sourceforge.net Sun Sep 17 16:40:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 07:40:50 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 19:45 Message generated for change (Comment added) made by evanpowers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Evan (evanpowers) Date: 2006-09-17 10:40 Message: Logged In: YES user_id=1598476 Looking at http://homepage.mac.com/ronaldoussoren, I only see the following files: Universal mpkg/pyobjc-1.3.8a0-python2.4-macosx10.4.dmg anthony/python-2.5b3-macosx2006-08-03.dmg anthony/python-2.5c2-macosx2006-09-12.dmg python-2.5c1-macosx2006-08-28.dmg I'll download the 2.5c2 one and see if the MD5 is different just in case. Are you sure you uploaded it? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 07:47 Message: Logged In: YES user_id=580910 I've uploaded a new installer to http://homagepages.mac.com/ ronaldoussoren, its the file python-2.5c2-macosx2006-09-17.dmg. Could you please test if this fixes the installation problems for you? I'd really appricate if you could post the contents of the installer log if installation failed (in Installer.app use the menu File -> Show Log, then select 'Show Everything', save that file and add it to this bug). This version has two minor changes w.r.t. the previous one: 1) the application subpackage won't try to install a custom icon on the MacPython 2.5 folder. After reading some pages on the interweb I'm starting to believe that installing a custom icon will require a postinstall script and that's not something I want to add at this point of the release cycle (if ever). 2) the fixsystempython subpackage won't abort the installation when the system python's Makefile was patched by someone else. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 19:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 12:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 11:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sun Sep 17 16:55:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 07:55:14 -0700 Subject: [ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname Message-ID: Bugs item #1560179, was opened at 2006-09-17 14:55 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=1560179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.basename/dirname Initial Comment: hi, basename/dirname could do better (especially on long pathnames) def basename(p): return split(p)[1] def dirname(p): return split(p)[0] both construct base and dirname and discard the unused one. what about that? def basename(p): i = p.rfind('/') + 1 return p[i:] def dirname(p): i = p.rfind('/') + 1 return p[:i] greets, michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 From noreply at sourceforge.net Sun Sep 17 17:57:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 08:57:00 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-15 01:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 17:57 Message: Logged In: YES user_id=580910 Arghhh, I uploaded the wrong file. The right one is there now. MD5 (python-2.5c2-macosx2006-09-17.dmg) = 2f4fb47cb881863c8fc47927dd716a2a ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-17 16:40 Message: Logged In: YES user_id=1598476 Looking at http://homepage.mac.com/ronaldoussoren, I only see the following files: Universal mpkg/pyobjc-1.3.8a0-python2.4-macosx10.4.dmg anthony/python-2.5b3-macosx2006-08-03.dmg anthony/python-2.5c2-macosx2006-09-12.dmg python-2.5c1-macosx2006-08-28.dmg I'll download the 2.5c2 one and see if the MD5 is different just in case. Are you sure you uploaded it? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 13:47 Message: Logged In: YES user_id=580910 I've uploaded a new installer to http://homagepages.mac.com/ ronaldoussoren, its the file python-2.5c2-macosx2006-09-17.dmg. Could you please test if this fixes the installation problems for you? I'd really appricate if you could post the contents of the installer log if installation failed (in Installer.app use the menu File -> Show Log, then select 'Show Everything', save that file and add it to this bug). This version has two minor changes w.r.t. the previous one: 1) the application subpackage won't try to install a custom icon on the MacPython 2.5 folder. After reading some pages on the interweb I'm starting to believe that installing a custom icon will require a postinstall script and that's not something I want to add at this point of the release cycle (if ever). 2) the fixsystempython subpackage won't abort the installation when the system python's Makefile was patched by someone else. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-16 01:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 18:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 17:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sun Sep 17 19:22:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 10:22:38 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-14 19:45 Message generated for change (Comment added) made by evanpowers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Evan (evanpowers) Date: 2006-09-17 13:22 Message: Logged In: YES user_id=1598476 The new installer appears to have worked perfectly. (I have the installer log file if you still want it.) Thanks very much. Python 2.5 is quite exciting! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 11:57 Message: Logged In: YES user_id=580910 Arghhh, I uploaded the wrong file. The right one is there now. MD5 (python-2.5c2-macosx2006-09-17.dmg) = 2f4fb47cb881863c8fc47927dd716a2a ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-17 10:40 Message: Logged In: YES user_id=1598476 Looking at http://homepage.mac.com/ronaldoussoren, I only see the following files: Universal mpkg/pyobjc-1.3.8a0-python2.4-macosx10.4.dmg anthony/python-2.5b3-macosx2006-08-03.dmg anthony/python-2.5c2-macosx2006-09-12.dmg python-2.5c1-macosx2006-08-28.dmg I'll download the 2.5c2 one and see if the MD5 is different just in case. Are you sure you uploaded it? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 07:47 Message: Logged In: YES user_id=580910 I've uploaded a new installer to http://homagepages.mac.com/ ronaldoussoren, its the file python-2.5c2-macosx2006-09-17.dmg. Could you please test if this fixes the installation problems for you? I'd really appricate if you could post the contents of the installer log if installation failed (in Installer.app use the menu File -> Show Log, then select 'Show Everything', save that file and add it to this bug). This version has two minor changes w.r.t. the previous one: 1) the application subpackage won't try to install a custom icon on the MacPython 2.5 folder. After reading some pages on the interweb I'm starting to believe that installing a custom icon will require a postinstall script and that's not something I want to add at this point of the release cycle (if ever). 2) the fixsystempython subpackage won't abort the installation when the system python's Makefile was patched by someone else. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 19:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 12:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 11:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 00:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sun Sep 17 20:43:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 11:43:35 -0700 Subject: [ python-Bugs-1558983 ] 2.5c2 macosx installer aborts during "GUI Applications" Message-ID: Bugs item #1558983, was opened at 2006-09-15 01:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&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: Macintosh Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Evan (evanpowers) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 2.5c2 macosx installer aborts during "GUI Applications" Initial Comment: When I run the installer in python-2.5c2-macosx2006-09-12.dmg, it continues until the "GUI Applications" phase, during which it fails saying "There were errors installing the software. Please try installing again". (Which doesn't work.) I noticed that at the same moment it does this, Console.app's console.log window adds the following line: 2006-09-14 19:12:21.568 Installer[1884] Exception raised during posting of notification. Ignored. exception: Some files for PythonApplications-2.5 may not have been written correctly. (code 1) I've also determined that if I try installing again, but this time click Customize on the Installation Type screen, then uncheck "GUI Applications 2.1MB", the installation proceeds successfully. I'm running OS X 10.3.9 on PowerPC. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 20:43 Message: Logged In: YES user_id=580910 Thanks for testing this. I'm glad the new version of the installer works correctly. The changes were commited on the release25-maint branch in revision 51902 and to the trunk in revision 51903. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-17 19:22 Message: Logged In: YES user_id=1598476 The new installer appears to have worked perfectly. (I have the installer log file if you still want it.) Thanks very much. Python 2.5 is quite exciting! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 17:57 Message: Logged In: YES user_id=580910 Arghhh, I uploaded the wrong file. The right one is there now. MD5 (python-2.5c2-macosx2006-09-17.dmg) = 2f4fb47cb881863c8fc47927dd716a2a ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-17 16:40 Message: Logged In: YES user_id=1598476 Looking at http://homepage.mac.com/ronaldoussoren, I only see the following files: Universal mpkg/pyobjc-1.3.8a0-python2.4-macosx10.4.dmg anthony/python-2.5b3-macosx2006-08-03.dmg anthony/python-2.5c2-macosx2006-09-12.dmg python-2.5c1-macosx2006-08-28.dmg I'll download the 2.5c2 one and see if the MD5 is different just in case. Are you sure you uploaded it? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 13:47 Message: Logged In: YES user_id=580910 I've uploaded a new installer to http://homagepages.mac.com/ ronaldoussoren, its the file python-2.5c2-macosx2006-09-17.dmg. Could you please test if this fixes the installation problems for you? I'd really appricate if you could post the contents of the installer log if installation failed (in Installer.app use the menu File -> Show Log, then select 'Show Everything', save that file and add it to this bug). This version has two minor changes w.r.t. the previous one: 1) the application subpackage won't try to install a custom icon on the MacPython 2.5 folder. After reading some pages on the interweb I'm starting to believe that installing a custom icon will require a postinstall script and that's not something I want to add at this point of the release cycle (if ever). 2) the fixsystempython subpackage won't abort the installation when the system python's Makefile was patched by someone else. ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-16 01:24 Message: Logged In: YES user_id=1598476 Yes, I'll be available. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-15 18:19 Message: Logged In: YES user_id=580910 I had some problems with pax(1) when I created the installer, and specifically with the "MacPython 2.5" folder in /Applications which should have a custom icon. I'm going to rebuild the 2.5c2 installer tomorrow, but without a custom icon on the "MacPython 2.5" folder. Would you be available for testing? I have a 10.3.9 box, but didn't have this problem when I tested the installer there (earlier this week). ---------------------------------------------------------------------- Comment By: Evan (evanpowers) Date: 2006-09-15 17:58 Message: Logged In: YES user_id=1598476 BTW, neither 2.5b3 nor 2.5c1 have this problem with the installer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Ronald so he sees this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 06:29 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558983&group_id=5470 From noreply at sourceforge.net Sun Sep 17 21:23:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 12:23:58 -0700 Subject: [ python-Bugs-1552935 ] Pythonw doesn't get rebuilt if version number changes Message-ID: Bugs item #1552935, was opened at 2006-09-05 21:37 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&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: Macintosh Group: Python 2.6 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Pythonw doesn't get rebuilt if version number changes Initial Comment: If the Python version number changes (as it did this week) Mac/pythonw should get rebuilt so it fires up the correct real Python executable. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:23 Message: Logged In: YES user_id=580910 This should be fixed in revision 51904. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 23:16 Message: Logged In: YES user_id=580910 pythonw should depend on the Makefile and the Makefile should be automaticly rebuild when config.status changes (just like the toplevel Makefile). I'll check in a patch this weekend, I need to test before I do the checkin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552935&group_id=5470 From noreply at sourceforge.net Sun Sep 17 21:27:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 12:27:45 -0700 Subject: [ python-Bugs-1555501 ] Please include pliblist for all plattforms Message-ID: Bugs item #1555501, was opened at 2006-09-09 22:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555501&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555501&group_id=5470 From noreply at sourceforge.net Sun Sep 17 22:27:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 13:27:39 -0700 Subject: [ python-Bugs-1555501 ] Please include pliblist for all plattforms Message-ID: Bugs item #1555501, was opened at 2006-09-09 22:07 Message generated for change (Comment added) made by guidog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555501&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido ---------------------------------------------------------------------- >Comment By: Guido Guenther (guidog) Date: 2006-09-17 22:27 Message: Logged In: YES user_id=696207 That's sad since it looks unproblematic. Please add it to 2.6 then. Thanks a lot, -- Guido ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555501&group_id=5470 From noreply at sourceforge.net Sun Sep 17 22:35:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 13:35:47 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 22:35 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=1560327&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 07:55:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Sep 2006 22:55:47 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-17 22:55 Message: Logged In: YES user_id=33168 Attaching a new patch with tests. There probably should be more tests, but this is all I can think of at this point. I think I've covered the cases of the recursive definition properly now. Conceptually this is a very small patch. I've added a bunch of asserts and broken some complex lines up though. The first chunk deals with complex_args and elides superfluous parens around (x). The second chunk does the same eliding but for non-complex args. Any number of extra parens should be elided properly now. I will apply to head and 2.5.1 later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 00:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the ((((x)))) problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Mon Sep 18 09:23:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 00:23:24 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: Closed Resolution: None Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 13:05:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 04:05:52 -0700 Subject: [ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname Message-ID: Bugs item #1560179, was opened at 2006-09-17 14:55 Message generated for change (Settings changed) made by einsteinmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&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: Deleted Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.basename/dirname Initial Comment: hi, basename/dirname could do better (especially on long pathnames) def basename(p): return split(p)[1] def dirname(p): return split(p)[0] both construct base and dirname and discard the unused one. what about that? def basename(p): i = p.rfind('/') + 1 return p[i:] def dirname(p): i = p.rfind('/') + 1 return p[:i] greets, michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 From noreply at sourceforge.net Mon Sep 18 13:08:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 04:08:01 -0700 Subject: [ python-Bugs-1560161 ] Better/faster implementation of os.path.split Message-ID: Bugs item #1560161, was opened at 2006-09-17 14:09 Message generated for change (Comment added) made by einsteinmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.split Initial Comment: hi, os.path.split is quite bad regarding performance on long pathnames: def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] if head and head != '/'*len(head): head = head.rstrip('/') return head, tail especially this: '/'*len(head) this constructs an unnecessary string sometimes thousands of chars long. better would be: if head and len(head) != head.count('/') BUT: what is this 'if head and head != '/'*len(head):' for? this if is imho useless, because if head exists and is not all '/' => rstrip '/' imho better would be: rstrip '/' from head and if head is empty add a '/' would be the same effect, because a singel '/' is just the same as a path as '/'*len(head). def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] head = head.rstrip('/') if not head: head = '/' return head, tail such a implementation would be ways faster for long pathnames. greets, michael ---------------------------------------------------------------------- >Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:08 Message: Logged In: YES user_id=1600082 sorry, haven't benchmarked my solution ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 From noreply at sourceforge.net Mon Sep 18 13:25:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 04:25:39 -0700 Subject: [ python-Bugs-1560161 ] Better/faster implementation of os.path.split Message-ID: Bugs item #1560161, was opened at 2006-09-17 14:09 Message generated for change (Comment added) made by einsteinmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open >Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.split Initial Comment: hi, os.path.split is quite bad regarding performance on long pathnames: def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] if head and head != '/'*len(head): head = head.rstrip('/') return head, tail especially this: '/'*len(head) this constructs an unnecessary string sometimes thousands of chars long. better would be: if head and len(head) != head.count('/') BUT: what is this 'if head and head != '/'*len(head):' for? this if is imho useless, because if head exists and is not all '/' => rstrip '/' imho better would be: rstrip '/' from head and if head is empty add a '/' would be the same effect, because a singel '/' is just the same as a path as '/'*len(head). def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] head = head.rstrip('/') if not head: head = '/' return head, tail such a implementation would be ways faster for long pathnames. greets, michael ---------------------------------------------------------------------- >Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:25 Message: Logged In: YES user_id=1600082 patch passes all unittests for posixpath. basename( 310 ) means basename called with path of length 310 sum = 0.0453672409058 min = 4.19616699219e-05 posixpath.basename( 310 ) sum = 0.15571641922 min = 0.000146865844727 posixpath_orig.basename( 310 ) sum = 0.0432558059692 min = 4.10079956055e-05 posixpath.basename( 106 ) sum = 0.128361940384 min = 0.000113964080811 posixpath_orig.basename( 106 ) sum = 0.0422701835632 min = 4.10079956055e-05 posixpath.basename( 21 ) sum = 0.118340730667 min = 0.000111818313599 posixpath_orig.basename( 21 ) so this optimized basename is about 3 times faster as the old one and gets even faster for longer paths. sum = 0.124966621399 min = 0.000120878219604 posixpath.dirname( 310 ) sum = 0.156893730164 min = 0.000144958496094 posixpath_orig.dirname( 310 ) sum = 0.0986065864563 min = 9.10758972168e-05 posixpath.dirname( 106 ) sum = 0.117443084717 min = 0.000113964080811 posixpath_orig.dirname( 106 ) sum = 0.0905299186707 min = 8.89301300049e-05 posixpath.dirname( 21 ) sum = 0.118889808655 min = 0.000111103057861 posixpath_orig.dirname( 21 ) optimized dirname is also faster but not that much. but it saves an allocation which could save a few cycles later. ---------------------------------------------------------------------- Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:08 Message: Logged In: YES user_id=1600082 sorry, haven't benchmarked my solution ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 From noreply at sourceforge.net Mon Sep 18 13:29:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 04:29:21 -0700 Subject: [ python-Bugs-1560161 ] Better/faster implementation of os.path.split Message-ID: Bugs item #1560161, was opened at 2006-09-17 14:09 Message generated for change (Comment added) made by einsteinmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.split Initial Comment: hi, os.path.split is quite bad regarding performance on long pathnames: def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] if head and head != '/'*len(head): head = head.rstrip('/') return head, tail especially this: '/'*len(head) this constructs an unnecessary string sometimes thousands of chars long. better would be: if head and len(head) != head.count('/') BUT: what is this 'if head and head != '/'*len(head):' for? this if is imho useless, because if head exists and is not all '/' => rstrip '/' imho better would be: rstrip '/' from head and if head is empty add a '/' would be the same effect, because a singel '/' is just the same as a path as '/'*len(head). def split(p): i = p.rfind('/') + 1 head, tail = p[:i], p[i:] head = head.rstrip('/') if not head: head = '/' return head, tail such a implementation would be ways faster for long pathnames. greets, michael ---------------------------------------------------------------------- >Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:29 Message: Logged In: YES user_id=1600082 @#&^%#@$ webformular :( ---------------------------------------------------------------------- Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:25 Message: Logged In: YES user_id=1600082 patch passes all unittests for posixpath. basename( 310 ) means basename called with path of length 310 sum = 0.0453672409058 min = 4.19616699219e-05 posixpath.basename( 310 ) sum = 0.15571641922 min = 0.000146865844727 posixpath_orig.basename( 310 ) sum = 0.0432558059692 min = 4.10079956055e-05 posixpath.basename( 106 ) sum = 0.128361940384 min = 0.000113964080811 posixpath_orig.basename( 106 ) sum = 0.0422701835632 min = 4.10079956055e-05 posixpath.basename( 21 ) sum = 0.118340730667 min = 0.000111818313599 posixpath_orig.basename( 21 ) so this optimized basename is about 3 times faster as the old one and gets even faster for longer paths. sum = 0.124966621399 min = 0.000120878219604 posixpath.dirname( 310 ) sum = 0.156893730164 min = 0.000144958496094 posixpath_orig.dirname( 310 ) sum = 0.0986065864563 min = 9.10758972168e-05 posixpath.dirname( 106 ) sum = 0.117443084717 min = 0.000113964080811 posixpath_orig.dirname( 106 ) sum = 0.0905299186707 min = 8.89301300049e-05 posixpath.dirname( 21 ) sum = 0.118889808655 min = 0.000111103057861 posixpath_orig.dirname( 21 ) optimized dirname is also faster but not that much. but it saves an allocation which could save a few cycles later. ---------------------------------------------------------------------- Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 11:08 Message: Logged In: YES user_id=1600082 sorry, haven't benchmarked my solution ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470 From noreply at sourceforge.net Mon Sep 18 14:08:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 05:08:43 -0700 Subject: [ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname Message-ID: Bugs item #1560179, was opened at 2006-09-17 14:55 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.basename/dirname Initial Comment: hi, basename/dirname could do better (especially on long pathnames) def basename(p): return split(p)[1] def dirname(p): return split(p)[0] both construct base and dirname and discard the unused one. what about that? def basename(p): i = p.rfind('/') + 1 return p[i:] def dirname(p): i = p.rfind('/') + 1 return p[:i] greets, michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 From noreply at sourceforge.net Mon Sep 18 14:42:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 05:42:41 -0700 Subject: [ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname Message-ID: Bugs item #1560179, was opened at 2006-09-17 14:55 Message generated for change (Comment added) made by einsteinmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: Better/faster implementation of os.path.basename/dirname Initial Comment: hi, basename/dirname could do better (especially on long pathnames) def basename(p): return split(p)[1] def dirname(p): return split(p)[0] both construct base and dirname and discard the unused one. what about that? def basename(p): i = p.rfind('/') + 1 return p[i:] def dirname(p): i = p.rfind('/') + 1 return p[:i] greets, michael ---------------------------------------------------------------------- >Comment By: Michael Gebetsroither (einsteinmg) Date: 2006-09-18 12:42 Message: Logged In: YES user_id=1600082 posixpath with this patch passes all test from test_posixpath cleanly. benchmark: basename( 310 ) means basename called with a 310 chars long path sum = 0.0435626506805 min = 4.19616699219e-05 posixpath.basename( 310 ) sum = 0.152147769928 min = 0.00014591217041 posixpath_orig.basename( 310 ) sum = 0.0436658859253 min = 4.07695770264e-05 posixpath.basename( 106 ) sum = 0.117312431335 min = 0.000112771987915 posixpath_orig.basename( 106 ) sum = 0.0426909923553 min = 4.07695770264e-05 posixpath.basename( 21 ) sum = 0.113305330276 min = 0.000110864639282 posixpath_orig.basename( 21 ) sum = 0.12392115593 min = 0.000121831893921 posixpath.dirname( 310 ) sum = 0.152860403061 min = 0.00014591217041 posixpath_orig.dirname( 310 ) sum = 0.0942873954773 min = 9.08374786377e-05 posixpath.dirname( 106 ) sum = 0.114937067032 min = 0.000111818313599 posixpath_orig.dirname( 106 ) sum = 0.0918889045715 min = 8.79764556885e-05 posixpath.dirname( 21 ) sum = 0.114675760269 min = 0.000109910964966 posixpath_orig.dirname( 21 ) greets ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470 From noreply at sourceforge.net Mon Sep 18 16:53:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 07:53:42 -0700 Subject: [ python-Bugs-1560794 ] strftime('%z') behaving differently with/without time arg. Message-ID: Bugs item #1560794, was opened at 2006-09-18 16:53 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=1560794&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Knut Aksel R?ysland (knutroy) Assigned to: Nobody/Anonymous (nobody) Summary: strftime('%z') behaving differently with/without time arg. Initial Comment: According to the documentation, time.strftime will use time.localtime, when no time tuple is provided as argument. So, I wonder if it is desired behavior that %z returns different values in the following two cases: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.strftime('%Y-%m-%dT%H:%M:%S%z') '2006-09-18T16:12:05+0200' >>> time.strftime('%Y-%m-%dT%H:%M:%S%z', time.localtime()) '2006-09-18T16:12:05+0000' The first behavior is what I am looking for. I realize that %z is not documented, so maybe it should be rejected instead of giving surprising results, like above. This behavior is observed on different Linux systems under different versions of Python, e.g. on Ubuntu Dapper Drake running Python 2.4.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&group_id=5470 From noreply at sourceforge.net Mon Sep 18 19:26:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 10:26:16 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 22:35 Message generated for change (Comment added) made by blueyed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: Closed Resolution: None Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- >Comment By: daniel hahler (blueyed) Date: 2006-09-18 19:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 09:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 19:49:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 10:49:46 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: Closed >Resolution: Invalid Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 17:49 Message: Logged In: YES user_id=849994 Sure, if you like... ---------------------------------------------------------------------- Comment By: daniel hahler (blueyed) Date: 2006-09-18 17:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 20:39:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 11:39:35 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 22:35 Message generated for change (Comment added) made by blueyed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: Closed Resolution: Invalid Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- >Comment By: daniel hahler (blueyed) Date: 2006-09-18 20:39 Message: Logged In: YES user_id=663176 I cannot comment on infogami. It says the following is spam: """ Please note that olddict.copy() does not "deepcopy" the dictionary. So if you have a dictionary of objects, those will still be copied by reference. """ I've tried rephrasing it slightly, to no avail. Can you update the wiki page directly? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 19:49 Message: Logged In: YES user_id=849994 Sure, if you like... ---------------------------------------------------------------------- Comment By: daniel hahler (blueyed) Date: 2006-09-18 19:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 09:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 20:53:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 11:53:49 -0700 Subject: [ python-Bugs-1560327 ] copy() method of dictionaries is not "deep" Message-ID: Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: daniel hahler (blueyed) >Assigned to: A.M. Kuchling (akuchling) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 18:53 Message: Logged In: YES user_id=849994 Sorry, I can't since I don't have any privileges there too. Assigning to AMK, perhaps he can do something about it. ---------------------------------------------------------------------- Comment By: daniel hahler (blueyed) Date: 2006-09-18 18:39 Message: Logged In: YES user_id=663176 I cannot comment on infogami. It says the following is spam: """ Please note that olddict.copy() does not "deepcopy" the dictionary. So if you have a dictionary of objects, those will still be copied by reference. """ I've tried rephrasing it slightly, to no avail. Can you update the wiki page directly? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 17:49 Message: Logged In: YES user_id=849994 Sure, if you like... ---------------------------------------------------------------------- Comment By: daniel hahler (blueyed) Date: 2006-09-18 17:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 From noreply at sourceforge.net Mon Sep 18 21:57:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 12:57:56 -0700 Subject: [ python-Bugs-1560984 ] python 2.5 fails to build with --as-needed Message-ID: Bugs item #1560984, was opened at 2006-09-18 19:57 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=1560984&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 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 fails to build with --as-needed Initial Comment: Passing -Wl,--as-needed to gcc in LDFLAGS gives an error, patch currently in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&group_id=5470 From noreply at sourceforge.net Tue Sep 19 09:32:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 00:32:31 -0700 Subject: [ python-Bugs-1561243 ] mac installer profile patch vs. .bash_login Message-ID: Bugs item #1561243, was opened at 2006-09-19 09:32 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=1561243&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: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: mac installer profile patch vs. .bash_login Initial Comment: The mac installer for 2.4.3 and 2.5 patches ~/.profile or ~/.bash_profile. If a .bash_login file exists and no .bash_profile exists the installer currently creates a .profile, which won't be used by bash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470 From noreply at sourceforge.net Tue Sep 19 12:15:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 03:15:42 -0700 Subject: [ python-Bugs-1561333 ] -xcode=pic32 option is not supported on Solaris x86 Sun C Message-ID: Bugs item #1561333, was opened at 2006-09-19 18:15 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=1561333&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.4 Status: Open Resolution: None Priority: 5 Submitted By: James Lick (jlick) Assigned to: Nobody/Anonymous (nobody) Summary: -xcode=pic32 option is not supported on Solaris x86 Sun C Initial Comment: Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when Sun C is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates a warning that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&group_id=5470 From noreply at sourceforge.net Tue Sep 19 19:55:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 10:55:37 -0700 Subject: [ python-Feature Requests-1561634 ] String searching performance improvement Message-ID: Feature Requests item #1561634, was opened at 2006-09-19 12:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&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: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Nick Welch (mackstann) Assigned to: Nobody/Anonymous (nobody) Summary: String searching performance improvement Initial Comment: The current string searching (str.find) seems to use the simplest possible method of searching, which is simply comparing character by character. A simple speed improvement would be to take needle[-1] and start searching at haystack[len(needle)-1]. Then check again at haystack[len(needle)*2-1]. etc. If the last character doesn't match, then the rest of the string couldn't possibly match. I'm sure there are other methods of speeding up string searching but this seems like a pretty simple and easy improvement. If I have some time I will go ahead and try implementing it myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&group_id=5470 From noreply at sourceforge.net Tue Sep 19 23:26:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 14:26:30 -0700 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 12:21 Message generated for change (Comment added) made by amcnabb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&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.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:26 Message: Logged In: YES user_id=1234027 I'm having this same problem with Python 2.5. I checked, and "/usr/lib/libmpc.a" is present. I've only tried with gcc, and I'm getting the exact same errors as above. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:56 Message: Logged In: YES user_id=71407 Before giving up I'd try to reset PATH before running configure in the Python directory. I had all kinds of trouble with the freeware tools on path. Here is what I use: /usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11 Python 2.4 really works under IRIX, incl. the socket module. I have it going on three different machines. On one machine the timestamp for libmpc.a is from 1998! ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 10:43 Message: Logged In: YES user_id=1179755 Ralf, Strange, I DO have that library: ls -l /usr/lib/libmpc* -r--r--r-- 1 root sys 1220 Mar 13 2001 /usr/lib/libmpc.a It makes no sense to me that the SGI MIPS compilers can't find a library that's in a default location. Very peculiar. I guess I'm just going to have to give up on getting Python 2.4 working completely under Irix. We need both network and _locale to work in order for the various scripts we have in place to work correctly and I can't get it to compile with gcc. [*sigh*] ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess you could just remove the -lmpc from the link line. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 08:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python \ Modules/python.o \ libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 09:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 09:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 07:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Tue Sep 19 23:42:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 14:42:32 -0700 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 12:21 Message generated for change (Comment added) made by amcnabb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&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.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:42 Message: Logged In: YES user_id=1234027 When I use the native IRIX cc to compile socketmodule.c in Python 2.5, I get: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i nclude -I./Include -I. -I/usr/local/include -I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au to/fsc/awm27/bzr/Python-2.5 -c /auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372 Macro "MAX" (declared at line 77 of "/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an incompatible redefinition. #define MAX(a,b) (((a)>(b))?(a):(b)) ^ When I commented out the macro definition in socketmodule.c, I was able to get it to compile (with the IRIX compiler). It seems to me that --without-gcc should be the default for IRIX until the gcc problem gets fixed because ./configure is currently automatically choosing gcc as the compiler when both are available. And I'm really not sure why the "#undef MAX" didn't happen. Anyway, I hope this is helpful for someone. ---------------------------------------------------------------------- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:26 Message: Logged In: YES user_id=1234027 I'm having this same problem with Python 2.5. I checked, and "/usr/lib/libmpc.a" is present. I've only tried with gcc, and I'm getting the exact same errors as above. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:56 Message: Logged In: YES user_id=71407 Before giving up I'd try to reset PATH before running configure in the Python directory. I had all kinds of trouble with the freeware tools on path. Here is what I use: /usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11 Python 2.4 really works under IRIX, incl. the socket module. I have it going on three different machines. On one machine the timestamp for libmpc.a is from 1998! ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 10:43 Message: Logged In: YES user_id=1179755 Ralf, Strange, I DO have that library: ls -l /usr/lib/libmpc* -r--r--r-- 1 root sys 1220 Mar 13 2001 /usr/lib/libmpc.a It makes no sense to me that the SGI MIPS compilers can't find a library that's in a default location. Very peculiar. I guess I'm just going to have to give up on getting Python 2.4 working completely under Irix. We need both network and _locale to work in order for the various scripts we have in place to work correctly and I can't get it to compile with gcc. [*sigh*] ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess you could just remove the -lmpc from the link line. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 08:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python \ Modules/python.o \ libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 09:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 09:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 07:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Wed Sep 20 02:10:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 17:10:36 -0700 Subject: [ python-Feature Requests-1561634 ] String searching performance improvement Message-ID: Feature Requests item #1561634, was opened at 2006-09-19 12:55 Message generated for change (Settings changed) made by mackstann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&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: Performance Group: Python 2.6 >Status: Deleted Resolution: None Priority: 5 Submitted By: Nick Welch (mackstann) Assigned to: Nobody/Anonymous (nobody) Summary: String searching performance improvement Initial Comment: The current string searching (str.find) seems to use the simplest possible method of searching, which is simply comparing character by character. A simple speed improvement would be to take needle[-1] and start searching at haystack[len(needle)-1]. Then check again at haystack[len(needle)*2-1]. etc. If the last character doesn't match, then the rest of the string couldn't possibly match. I'm sure there are other methods of speeding up string searching but this seems like a pretty simple and easy improvement. If I have some time I will go ahead and try implementing it myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&group_id=5470 From noreply at sourceforge.net Wed Sep 20 02:26:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 17:26:55 -0700 Subject: [ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Message-ID: Bugs item #1550791, was opened at 2006-09-01 22:23 Message generated for change (Comment added) made by dmpotts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&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: Tkinter Group: Python 2.5 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. L?wis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no ---------------------------------------------------------------------- >Comment By: Davin (dmpotts) Date: 2006-09-20 00:26 Message: Logged In: YES user_id=1588828 Excellent question -- they appear to be absent -- that would explain a thing or two. Apologies for the confusion -- changing status to Invalid. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 07:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 From noreply at sourceforge.net Wed Sep 20 06:06:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 21:06:33 -0700 Subject: [ python-Bugs-1008295 ] logging.getLevelName returns a number Message-ID: Bugs item #1008295, was opened at 2004-08-12 23:56 Message generated for change (Comment added) made by stevepole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. ---------------------------------------------------------------------- Comment By: Steve Pole (stevepole) Date: 2006-09-20 06:06 Message: Logged In: YES user_id=455201 I understand this is not a bug, it's by design. It still looks like a bug, though. Please consider the following code: import logging defaultLoglevel = logging.DEBUG newLoglevel = 'WARNING' logging.basicConfig (level = defaultLoglevel, format = '%(message)s') print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () logging.getLogger ().setLevel (newLoglevel.upper ()) print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () Output: DEBUG 10 30 WARNING So the result basically inverts. Is that really the way it is supposed to work ? Or am I misunderstanding something ? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-08-20 14:36 Message: Logged In: YES user_id=308438 This is not a bug, it's by design. Current CVS throws an exception if raiseExceptions is set and you pass anything other than an integer as the log level. The CVS documentation has also been updated to clarify that the level passed in is the integer rather than the level name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 From noreply at sourceforge.net Wed Sep 20 07:59:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 22:59:44 -0700 Subject: [ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Message-ID: Bugs item #1550791, was opened at 2006-09-02 00:23 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&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: Tkinter Group: Python 2.5 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. L?wis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no ---------------------------------------------------------------------- Comment By: Davin (dmpotts) Date: 2006-09-20 02:26 Message: Logged In: YES user_id=1588828 Excellent question -- they appear to be absent -- that would explain a thing or two. Apologies for the confusion -- changing status to Invalid. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 09:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 From noreply at sourceforge.net Wed Sep 20 13:01:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 04:01:34 -0700 Subject: [ python-Bugs-1562092 ] Dedent with Italian keyboard Message-ID: Bugs item #1562092, was opened at 2006-09-20 13:01 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=1562092&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: neclepsio (neclepsio82) Assigned to: Nobody/Anonymous (nobody) Summary: Dedent with Italian keyboard Initial Comment: In IDLE, with an Italian keyboard, it's impossible to dedent the text without using the menu, because the shortcut Ctrl+] cannot be typed. In fact, with an Italian keybaord, the ] is typed with Ctrl+Alt++. While indent can be achieved with Tab, so that's no problem, dedent is only accesible from menu: I suggest you to shortcut it as Shift+Tab too, like many other IDEs. Thank you Ignazio ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470 From noreply at sourceforge.net Wed Sep 20 14:33:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 05:33:49 -0700 Subject: [ python-Bugs-1562171 ] Fails to install on Fedora Core 5 Message-ID: Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 From noreply at sourceforge.net Wed Sep 20 15:10:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 06:10:34 -0700 Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command line... Message-ID: Bugs item #1562193, was opened at 2006-09-20 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=1562193&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faramir^ (faramir2) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE Hung up after open script by command line... Initial Comment: Hello, I wrote that code in python and saved as prx.py: --- CUT --- from BaseHTTPServer import HTTPServer, BaseHTTPRequestHandler from time import strftime, gmtime import urllib2 import thread from sys import stdout class RequestHandler(BaseHTTPRequestHandler): def serve(self): print "%s %s %s\r\n%s" % (self.command, self.path, self.request_version, self.headers) header={} header["content-length"]=0 for i in str(self.headers).split("\r\n"): j=i.split(":", 1) if len(j)==2: header[j[0].strip().lower()] = j[1].strip() content=self.rfile.read(int(header["content- length"])) print content url="http://faramir2.prv.pl" u=urllib2.urlopen(url) for i,j in u.info().items(): print "%s: %s" % (i,j) self.server_version = "Apache" self.sys_version = "" self.send_response(200) self.send_header("Content-type", "text/html; charset=ISO-8859-2") self.send_header("Connectin", "close") self.end_headers() def do_POST(self): self.serve() def do_HEAD(self): self.serve() def do_GET(self): self.serve() address = ("", 80) server = HTTPServer(address, RequestHandler) thread.start_new_thread(server.serve_forever, () ) --- CUT --- When I right click on that file and select "Edit with IDLE" it opens. Then when I push F5 the script is running. *Python Shell* is restarting. But when I try to connect by browser to http:// localhost:80/ IDLE Hung-up. I don't see that hung ups when I open IDLE from shortcut and then in IDLE open file prx.py and run it works normally - good. IDLE does't hung up. I don't know why it works like that, but I think that it's bug.. Python version: 2.5c2 Tk version: 8.4 IDLE version: 1.2c2 OS Version: Microsoft Windows XP Professional with SP2 --- Again: * Freeze: > "C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw" -n -e "prx.py" // then F5 on IDLE // when run open Browser and try to open page: http:// localhost:80 // IDLE freezes * Works ok: > "C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw" -e // open prx.py in IDLE // press F5 on IDLE // run Browwser and try to open page: http:// localhost:80 // all works ok --- regards, Marek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470 From noreply at sourceforge.net Wed Sep 20 15:47:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 06:47:09 -0700 Subject: [ python-Bugs-1008295 ] logging.getLevelName returns a number Message-ID: Bugs item #1008295, was opened at 2004-08-12 21:56 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-09-20 13:47 Message: Logged In: YES user_id=308438 Yes, that's the way it's supposed to work - the map works both ways, allowing the mapping of names to levels as well as levels to names. This is because both types of mapping are needed in the package, and it makes sense to reuse the dictionary rather than have two separate dictionaries. In your example, you are calling setLevel with a string argument [newLoglevel.upper ()], which is incorrect. I will clarify the setLevel() documentation to point out that the level passed to setLevel() is an integer. ---------------------------------------------------------------------- Comment By: Steve Pole (stevepole) Date: 2006-09-20 04:06 Message: Logged In: YES user_id=455201 I understand this is not a bug, it's by design. It still looks like a bug, though. Please consider the following code: import logging defaultLoglevel = logging.DEBUG newLoglevel = 'WARNING' logging.basicConfig (level = defaultLoglevel, format = '%(message)s') print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () logging.getLogger ().setLevel (newLoglevel.upper ()) print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () Output: DEBUG 10 30 WARNING So the result basically inverts. Is that really the way it is supposed to work ? Or am I misunderstanding something ? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-08-20 12:36 Message: Logged In: YES user_id=308438 This is not a bug, it's by design. Current CVS throws an exception if raiseExceptions is set and you pass anything other than an integer as the log level. The CVS documentation has also been updated to clarify that the level passed in is the integer rather than the level name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 From noreply at sourceforge.net Wed Sep 20 17:50:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 08:50:48 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 11:50 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=1562308&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 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Wed Sep 20 19:49:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 10:49:57 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Wed Sep 20 19:53:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 10:53:20 -0700 Subject: [ python-Bugs-1562171 ] Fails to install on Fedora Core 5 Message-ID: Bugs item #1562171, was opened at 2006-09-20 05:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 From noreply at sourceforge.net Wed Sep 20 20:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 11:08:42 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 11:50 Message generated for change (Comment added) made by lukemoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- >Comment By: Luke Moore (lukemoore) Date: 2006-09-20 14:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 13:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Thu Sep 21 03:21:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 18:21:25 -0700 Subject: [ python-Bugs-1562583 ] asyncore.dispatcher.set_reuse_addr not documented. Message-ID: Bugs item #1562583, was opened at 2006-09-20 18: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=1562583&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore.dispatcher.set_reuse_addr not documented. Initial Comment: I could not find this in http://docs.python.org/lib/module-asyncore.html nor in http://docs.python.org/lib/genindex.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562583&group_id=5470 From noreply at sourceforge.net Thu Sep 21 06:15:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 21:15:58 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 21:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. ---------------------------------------------------------------------- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 11:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Thu Sep 21 06:16:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 21:16:12 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) >Assigned to: Neal Norwitz (nnorwitz) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 21:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. ---------------------------------------------------------------------- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 11:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Thu Sep 21 09:05:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 00:05:34 -0700 Subject: [ python-Bugs-1562171 ] Fails to install on Fedora Core 5 Message-ID: Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Comment added) made by mnsummerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. ---------------------------------------------------------------------- >Comment By: Mark Summerfield (mnsummerfield) Date: 2006-09-21 07:05 Message: Logged In: YES user_id=1602435 I didn't run out of disk space, I've 28GB free... I did try several times, (including make clean, rerun configure, make, make tests, and make install), and yes, it always failed in the same place. And just to make really sure, I have just tried the whole process again. I deleted my Python-2.5 directory, unpacked the whole thing again, ran configure, added -fwrapv to the Makefile, and ran make and make test. This time make test had only one "unexpected" skipped test: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 283 tests OK. 36 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 1 skip unexpected on linux2: test_bsddb Next I ran make install... and it worked! Maybe there's some dependency on having a dbm of some sort? Anyway, sorry for the false alarm. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 17:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 From noreply at sourceforge.net Thu Sep 21 10:23:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 01:23:18 -0700 Subject: [ python-Bugs-1562716 ] Spurious tab/space warning Message-ID: Bugs item #1562716, was opened at 2006-09-21 10:23 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=1562716&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious tab/space warning Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tabnanny Tokenizing Error" "Token Error: EOF in multi-line statement" for i in range(10): a = list("123")) The second line is indented with 8 or 4 spaces, doesn't matter which. Can't recall this happening in the IDLE version bundled with py2.4. Don't know if IDLE or the tabnanny module is the culprit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&group_id=5470 From noreply at sourceforge.net Thu Sep 21 10:25:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 01:25:20 -0700 Subject: [ python-Bugs-1562716 ] Spurious tab/space warning Message-ID: Bugs item #1562716, was opened at 2006-09-21 10:23 Message generated for change (Comment added) made by torhu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious tab/space warning Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tabnanny Tokenizing Error" "Token Error: EOF in multi-line statement" for i in range(10): a = list("123")) The second line is indented with 8 or 4 spaces, doesn't matter which. Can't recall this happening in the IDLE version bundled with py2.4. Don't know if IDLE or the tabnanny module is the culprit. ---------------------------------------------------------------------- >Comment By: torhu (torhu) Date: 2006-09-21 10:25 Message: Logged In: YES user_id=1038085 I also had somone on #python confirm this behavior for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&group_id=5470 From noreply at sourceforge.net Thu Sep 21 10:29:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 01:29:02 -0700 Subject: [ python-Bugs-1562719 ] Spurious Tab/space error Message-ID: Bugs item #1562719, was opened at 2006-09-21 10:29 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=1562719&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious Tab/space error Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tab/space error" "Error: Inconsistent indentation detected!" Etc. for i in range(10): a = list("123")) x = 5 The second line is indented with 8 spaces. Can't recall this happening in the IDLE version bundled with py2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&group_id=5470 From noreply at sourceforge.net Thu Sep 21 10:29:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 01:29:23 -0700 Subject: [ python-Bugs-1562719 ] Spurious Tab/space error Message-ID: Bugs item #1562719, was opened at 2006-09-21 10:29 Message generated for change (Settings changed) made by torhu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&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: IDLE >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious Tab/space error Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tab/space error" "Error: Inconsistent indentation detected!" Etc. for i in range(10): a = list("123")) x = 5 The second line is indented with 8 spaces. Can't recall this happening in the IDLE version bundled with py2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&group_id=5470 From noreply at sourceforge.net Thu Sep 21 10:30:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 01:30:08 -0700 Subject: [ python-Bugs-1562719 ] Spurious Tab/space error Message-ID: Bugs item #1562719, was opened at 2006-09-21 10:29 Message generated for change (Comment added) made by torhu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: Spurious Tab/space error Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tab/space error" "Error: Inconsistent indentation detected!" Etc. for i in range(10): a = list("123")) x = 5 The second line is indented with 8 spaces. Can't recall this happening in the IDLE version bundled with py2.4. ---------------------------------------------------------------------- >Comment By: torhu (torhu) Date: 2006-09-21 10:30 Message: Logged In: YES user_id=1038085 I also had somone on #python confirm this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562719&group_id=5470 From noreply at sourceforge.net Thu Sep 21 11:15:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 02:15:58 -0700 Subject: [ python-Bugs-1562716 ] Spurious Tabnanny error Message-ID: Bugs item #1562716, was opened at 2006-09-21 10:23 Message generated for change (Settings changed) made by torhu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) >Summary: Spurious Tabnanny error Initial Comment: IDLE 1.2, Py 2.5 on WinXP SP2. The extra parenthesis on the second line triggers a warning message box: "Tabnanny Tokenizing Error" "Token Error: EOF in multi-line statement" for i in range(10): a = list("123")) The second line is indented with 8 or 4 spaces, doesn't matter which. Can't recall this happening in the IDLE version bundled with py2.4. Don't know if IDLE or the tabnanny module is the culprit. ---------------------------------------------------------------------- Comment By: torhu (torhu) Date: 2006-09-21 10:25 Message: Logged In: YES user_id=1038085 I also had somone on #python confirm this behavior for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562716&group_id=5470 From noreply at sourceforge.net Thu Sep 21 13:59:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 04:59:41 -0700 Subject: [ python-Bugs-1562822 ] decimal module borks thread Message-ID: Bugs item #1562822, was opened at 2006-09-21 13:59 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=1562822&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaster (steevel) Assigned to: Nobody/Anonymous (nobody) Summary: decimal module borks thread Initial Comment: I got across this while trying to use MySQLdb in a thread. Since MySQLdb imports decimal I got the same error there. Code: (This happens in both 2.4 and 2.5) import thread, time, sys if len(sys.argv) > 1: import threading def test (): import decimal print 'Exiting test.' thread.start_new_thread(test, ()) time.sleep(1) Output: $ ./thread.py 1 Exiting test. $ ./thread.py Exiting test. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&group_id=5470 From noreply at sourceforge.net Thu Sep 21 14:02:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 05:02:04 -0700 Subject: [ python-Bugs-1560984 ] python 2.5 fails to build with --as-needed Message-ID: Bugs item #1560984, was opened at 2006-09-18 19:57 Message generated for change (Settings changed) made by masterdriverz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&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: Duplicate Priority: 5 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 fails to build with --as-needed Initial Comment: Passing -Wl,--as-needed to gcc in LDFLAGS gives an error, patch currently in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&group_id=5470 From noreply at sourceforge.net Thu Sep 21 14:02:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 05:02:26 -0700 Subject: [ python-Bugs-1560984 ] python 2.5 fails to build with --as-needed Message-ID: Bugs item #1560984, was opened at 2006-09-18 19:57 Message generated for change (Comment added) made by masterdriverz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&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: Duplicate Priority: 5 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 fails to build with --as-needed Initial Comment: Passing -Wl,--as-needed to gcc in LDFLAGS gives an error, patch currently in the works. ---------------------------------------------------------------------- >Comment By: Chaza (masterdriverz) Date: 2006-09-21 12:02 Message: Logged In: YES user_id=1096685 Patch submitted to https://sourceforge.net/tracker/index.php?func=detail&aid=1562825&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&group_id=5470 From noreply at sourceforge.net Thu Sep 21 18:19:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 09:19:51 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 11:50 Message generated for change (Comment added) made by lukemoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) >Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- >Comment By: Luke Moore (lukemoore) Date: 2006-09-21 12:19 Message: Logged In: YES user_id=1437974 For me, the output of 'valgrind --version' is valgrind-3.2.0-Debian. I get warnings from some tests when I run the test suite under valgrind. When I ran the tests, I uncommented the first block of ###-commented suppressions in valgrind-python.supp and ran: valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp --quiet ./python -E -tt ./Lib/test/regrtest.py -u bsddb,network (Note that I can reproduce the warning I'm seeing the valgrind-python.supp suppressions file.) The test suite warnings I get are: test_asynchat ==2425== Thread 2: ==2425== Conditional jump or move depends on uninitialised value(s) ==2425== at 0x415F09C: __pthread_manager (manager.c:128) ==2425== by 0x4291309: clone (clone.S:119) ==2425== ==2425== Syscall param clone(child_tidptr) contains uninitialised byte(s) ==2425== at 0x42912FC: clone (clone.S:100) ==2425== by 0x4291309: clone (clone.S:119) test_capi ==2420== ==2420== Thread 1: ==2420== Syscall param write(buf) points to uninitialised byte(s) ==2420== at 0x415E4AF: pthread_detach (join.c:216) ==2420== by 0x40F6BCA: PyThread_start_new_thread (thread_pthread.h:197) ==2420== by 0x4E82952: test_thread_state (_testcapimodule.c:663) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== Address 0xAEB75F74 is on thread 1's stack test_codecs ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40A445F: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2395) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40A0F30: unicode_resize (unicodeobject.c:188) ==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250) ==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2383) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x40A0F32: unicode_resize (unicodeobject.c:188) ==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250) ==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2383) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) test_codeop ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x403EAF3: parsetok (parsetok.c:189) ==2420== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==2420== by 0x40ED793: Py_CompileStringFlags (pythonrun.c:1311) ==2420== by 0x40C043A: builtin_compile (bltinmodule.c:464) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) test_ctypes ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40692E5: PyInt_FromLong (intobject.c:87) ==2420== by 0x6B12F18: l_get (cfield.c:810) ==2420== by 0x6B0FC8A: _CallProc (callproc.c:740) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x6B15703: ffi_call (ffi.c:237) ==2420== by 0x6B0FADE: _CallProc (callproc.c:665) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x6B15706: ffi_call (ffi.c:237) ==2420== by 0x6B0FADE: _CallProc (callproc.c:665) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) test_gzip ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC1CA: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC153: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC18E: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-21 00:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. ---------------------------------------------------------------------- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 14:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 13:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Thu Sep 21 19:55:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 10:55:39 -0700 Subject: [ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk Message-ID: Bugs item #1563046, was opened at 2006-09-21 10:55 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=1563046&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470 From noreply at sourceforge.net Thu Sep 21 20:53:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 11:53:18 -0700 Subject: [ python-Bugs-1563079 ] code.InteractiveConsole() and closed sys.stdout Message-ID: Bugs item #1563079, was opened at 2006-09-21 13:53 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=1563079&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: code.InteractiveConsole() and closed sys.stdout Initial Comment: This code raises a ValueError: import code c = code.InteractiveConsole() c.interact() import sys sys.stdout.close() because the InteractiveConsole uses raw_input() to display its prompt. I'm not sure where the correct place to fix this is. One possible way is to allow raw_input() to take optional arguments to use instead of sys.stdin and sys.stdout. Another (easier?) way to fix this problem might be to beef up InteractiveConsole.raw_input() a bit. I'm open to either option, but I think InteractiveConsole needs to continue working even if the user closes sys.stdout. This applies to the 2.4 and 2.5 branches as well as the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563079&group_id=5470 From noreply at sourceforge.net Thu Sep 21 21:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 12:23:19 -0700 Subject: [ python-Bugs-1562308 ] uninitialized memory read in parsetok() Message-ID: Bugs item #1562308, was opened at 2006-09-20 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&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 Submitted By: Luke Moore (lukemoore) Assigned to: Nobody/Anonymous (nobody) Summary: uninitialized memory read in parsetok() Initial Comment: When running python2.5 under valgrind and running exec "" valgrind issues the following warning: ==6661== Conditional jump or move depends on uninitialised value(s) ==6661== at 0x403EAF3: parsetok (parsetok.c:189) ==6661== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==6661== by 0x40EF852: PyRun_StringFlags (pythonrun.c:1225) ==6661== by 0x40CB7FF: PyEval_EvalFrameEx (ceval.c:4202) ==6661== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==6661== by 0x40CCA74: PyEval_EvalCode (ceval.c:494) ==6661== by 0x40EF3A1: PyRun_InteractiveOneFlags (pythonrun.c:1264) ==6661== by 0x40EF5A2: PyRun_InteractiveLoopFlags (pythonrun.c:714) ==6661== by 0x40EF6CA: PyRun_AnyFileExFlags (pythonrun.c:683) ==6661== by 0x40F930D: Py_Main (main.c:496) ==6661== by 0x8048591: main (in /usr/bin/python2.5) Valgrind does not give warnings when doing the same thing with python2.4.3. After further investigation, it looks like tok->line_start is uninitialized. Initializing to null in tok_new() removes the valgrind warning, but I have no idea if this is the correct fix. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-21 12:23 Message: Logged In: YES user_id=33168 The ones complaining about pthread (test_asynchat, test_capi) are not a problem. test_codecs is worrisome. I don't believe test_ctypes is a problem and I'm guessing that the test_gzip problem is either due to test_ctypes or an internal gzip library problem. BTW, you might want to read Misc/README.valgrind if you haven't already. You also need to skip test_socket_ssl as that causes a bunch of uninitialized memory warnings due to the SSL library. Thanks for the reports, I'll try to take a look at them later. ---------------------------------------------------------------------- Comment By: Luke Moore (lukemoore) Date: 2006-09-21 09:19 Message: Logged In: YES user_id=1437974 For me, the output of 'valgrind --version' is valgrind-3.2.0-Debian. I get warnings from some tests when I run the test suite under valgrind. When I ran the tests, I uncommented the first block of ###-commented suppressions in valgrind-python.supp and ran: valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp --quiet ./python -E -tt ./Lib/test/regrtest.py -u bsddb,network (Note that I can reproduce the warning I'm seeing the valgrind-python.supp suppressions file.) The test suite warnings I get are: test_asynchat ==2425== Thread 2: ==2425== Conditional jump or move depends on uninitialised value(s) ==2425== at 0x415F09C: __pthread_manager (manager.c:128) ==2425== by 0x4291309: clone (clone.S:119) ==2425== ==2425== Syscall param clone(child_tidptr) contains uninitialised byte(s) ==2425== at 0x42912FC: clone (clone.S:100) ==2425== by 0x4291309: clone (clone.S:119) test_capi ==2420== ==2420== Thread 1: ==2420== Syscall param write(buf) points to uninitialised byte(s) ==2420== at 0x415E4AF: pthread_detach (join.c:216) ==2420== by 0x40F6BCA: PyThread_start_new_thread (thread_pthread.h:197) ==2420== by 0x4E82952: test_thread_state (_testcapimodule.c:663) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== Address 0xAEB75F74 is on thread 1's stack test_codecs ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40A445F: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2395) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40A0F30: unicode_resize (unicodeobject.c:188) ==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250) ==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2383) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x40A0F32: unicode_resize (unicodeobject.c:188) ==2420== by 0x40A105B: _PyUnicode_New (unicodeobject.c:250) ==2420== by 0x40A43F7: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:2383) ==2420== by 0x410D796: unicode_internal_decode (_codecsmodule.c:225) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C4DCA: PyEval_CallObjectWithKeywords (ceval.c:3435) ==2420== by 0x40DAEAE: PyCodec_Decode (codecs.c:377) ==2420== by 0x4084FD3: PyString_AsDecodedObject (stringobject.c:391) ==2420== by 0x4086A92: string_decode (stringobject.c:3260) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) test_codeop ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x403EAF3: parsetok (parsetok.c:189) ==2420== by 0x40ED673: PyParser_ASTFromString (pythonrun.c:1354) ==2420== by 0x40ED793: Py_CompileStringFlags (pythonrun.c:1311) ==2420== by 0x40C043A: builtin_compile (bltinmodule.c:464) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) test_ctypes ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x40692E5: PyInt_FromLong (intobject.c:87) ==2420== by 0x6B12F18: l_get (cfield.c:810) ==2420== by 0x6B0FC8A: _CallProc (callproc.c:740) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x6B15703: ffi_call (ffi.c:237) ==2420== by 0x6B0FADE: _CallProc (callproc.c:665) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Use of uninitialised value of size 4 ==2420== at 0x6B15706: ffi_call (ffi.c:237) ==2420== by 0x6B0FADE: _CallProc (callproc.c:665) ==2420== by 0x6B0B48D: CFuncPtr_call (_ctypes.c:3357) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C6CB8: PyEval_EvalFrameEx (ceval.c:3777) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) test_gzip ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC1CA: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC153: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x40CABC8: PyEval_EvalFrameEx (ceval.c:3662) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== ==2420== Conditional jump or move depends on uninitialised value(s) ==2420== at 0x52DC18E: longest_match (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DCEB0: deflate_slow (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52DD6BF: deflate (in /home/luke/dev/hfs/dsolib/libz.so.1.2.3) ==2420== by 0x52D4DE9: PyZlib_flush (zlibmodule.c:605) ==2420== by 0x407BF6C: PyCFunction_Call (methodobject.c:108) ==2420== by 0x40CBF63: PyEval_EvalFrameEx (ceval.c:3566) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CB1C9: PyEval_EvalFrameEx (ceval.c:3652) ==2420== by 0x40CC8E5: PyEval_EvalCodeEx (ceval.c:2833) ==2420== by 0x4067C59: function_call (funcobject.c:517) ==2420== by 0x4045066: PyObject_Call (abstract.c:1860) ==2420== by 0x40C98D5: PyEval_EvalFrameEx (ceval.c:3846) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 21:15 Message: Logged In: YES user_id=33168 The proposed fix should be made, but I can't reproduce the problem. That bugs me. I'm running valgrind 3.2.0, what version are you running? I tried with gcc 3.3.x on x86 and gcc 3.4.x and 4.1.1 on amd64. Both are on gentoo. Have you run the entire regression suite with valgrind? I did, but given I'm not seeing these problems, I wonder if there might be issues lurking. ---------------------------------------------------------------------- Comment By: Luke Moore (lukemoore) Date: 2006-09-20 11:08 Message: Logged In: YES user_id=1437974 Running the python statement exec "" in the interactive shell will trigger the warning for me. I'm running Debian unstable, and can reproduce the problem with its RC1 python2.5 package built with gcc 4.1: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 I can also reproduce the problem with my own build of the official 2.5 release with built gcc 4.0: Python 2.5 (r25:51908, Sep 19 2006, 15:38:29) [GCC 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)] on linux2 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 10:49 Message: Logged In: YES user_id=33168 Thanks for the report. What is the python code that caused this warning to be generated? I've run valgrind with the standard tests and don't recall this error. Without looking at the code, the proposed fix seems to make sense (though from the name, I would have guessed that line_start is an int rather than a pointer). Also, what system and compiler are you using and how did you build python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562308&group_id=5470 From noreply at sourceforge.net Thu Sep 21 23:02:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 14:02:54 -0700 Subject: [ python-Bugs-1479785 ] Quitter object masked Message-ID: Bugs item #1479785, was opened at 2006-05-01 11:01 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&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: IDLE Group: Python 2.5 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: Quitter object masked Initial Comment: 2.5 introduces a Quitter object (defined in site.py) to make the quit/exit message more friendly. Lines 480-482 of PyShell.py override this, so that users of Idle never see the improved feature. Unfortunately, simply removing those lines isn't quite enough to solve the problem, as IDLE catches SystemExit exceptions. Getting around that, I didn't have time to track down yet. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 12:43 Message: Logged In: YES user_id=580910 When I type quit() in the Python Shell window I get a dialog that says: > The program is still running! > Do you want to kill it? (Python 2.5c1) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 01:03 Message: Logged In: YES user_id=149084 Rev 51306: Patch #1540892 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 From noreply at sourceforge.net Fri Sep 22 00:09:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 15:09:30 -0700 Subject: [ python-Bugs-1563185 ] ,msi fails for AMD Turion 64 mobile Message-ID: Bugs item #1563185, was opened at 2006-09-21 17:09 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=1563185&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: ,msi fails for AMD Turion 64 mobile Initial Comment: I tried to install python-2.5.amd64.msi on my HP notebook with an AMD Turion 64 Mobile and I got the error message "This installation is not supported by this processor type." Is this really different than some other AMD 64, or do you just fail to recognize the ID? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563185&group_id=5470 From noreply at sourceforge.net Fri Sep 22 03:10:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 18:10:04 -0700 Subject: [ python-Bugs-1563236 ] temporary file(s) Message-ID: Bugs item #1563236, was opened at 2006-09-22 03: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=1563236&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: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: temporary file(s) Initial Comment: After runnig Lib/test/test.py I have found some temporary files - the major is __db,004 can it be deleted ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563236&group_id=5470 From noreply at sourceforge.net Fri Sep 22 03:15:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 18:15:35 -0700 Subject: [ python-Bugs-1563238 ] http//... test file Message-ID: Bugs item #1563238, was opened at 2006-09-22 03:15 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=1563238&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: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: http//... test file Initial Comment: Whilte testing 2.5 (release-build) i have found that python tries to download some files from internet. Low connectin isn't big deal at this time but it's frustrating - korean letters at polish xp ? - I havn't see that combination ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563238&group_id=5470 From noreply at sourceforge.net Fri Sep 22 03:20:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 18:20:37 -0700 Subject: [ python-Bugs-1563243 ] python_d python Message-ID: Bugs item #1563243, was opened at 2006-09-22 03:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: python_d python Initial Comment: I'v added _d to python (python_d.exe) while performing standard tests ... it dies after testInfinitRecursion without any message - just dissapears :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470 From noreply at sourceforge.net Fri Sep 22 05:48:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 20:48:59 -0700 Subject: [ python-Bugs-1562822 ] decimal module borks thread Message-ID: Bugs item #1562822, was opened at 2006-09-21 04:59 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaster (steevel) Assigned to: Nobody/Anonymous (nobody) Summary: decimal module borks thread Initial Comment: I got across this while trying to use MySQLdb in a thread. Since MySQLdb imports decimal I got the same error there. Code: (This happens in both 2.4 and 2.5) import thread, time, sys if len(sys.argv) > 1: import threading def test (): import decimal print 'Exiting test.' thread.start_new_thread(test, ()) time.sleep(1) Output: $ ./thread.py 1 Exiting test. $ ./thread.py Exiting test. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-21 20:48 Message: Logged In: YES user_id=341410 I believe it is an issue with the import lock. If you 'import decimal' prior to starting up your subthread, everything will run fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&group_id=5470 From noreply at sourceforge.net Fri Sep 22 10:14:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 01:14:23 -0700 Subject: [ python-Bugs-1563238 ] http//... test file Message-ID: Bugs item #1563238, was opened at 2006-09-22 01:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563238&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: http//... test file Initial Comment: Whilte testing 2.5 (release-build) i have found that python tries to download some files from internet. Low connectin isn't big deal at this time but it's frustrating - korean letters at polish xp ? - I havn't see that combination ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-22 08:14 Message: Logged In: YES user_id=849994 If you enable the resource "urlfetch", the test suite will try to fetch some files required to test the east asian codecs. This is expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563238&group_id=5470 From noreply at sourceforge.net Fri Sep 22 10:15:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 01:15:27 -0700 Subject: [ python-Bugs-1563236 ] temporary file(s) Message-ID: Bugs item #1563236, was opened at 2006-09-22 01:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563236&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: None >Status: Closed Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: temporary file(s) Initial Comment: After runnig Lib/test/test.py I have found some temporary files - the major is __db,004 can it be deleted ? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-22 08:15 Message: Logged In: YES user_id=849994 Yes, you can delete them. They should be automatically removed by the bsddb test suite, but on Windows, there are sometimes file locking problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563236&group_id=5470 From noreply at sourceforge.net Fri Sep 22 10:21:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 01:21:07 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-22 01:21 Message: Logged In: YES user_id=33168 Committed revision 51972. (2.6) Still needs backport. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-17 22:55 Message: Logged In: YES user_id=33168 Attaching a new patch with tests. There probably should be more tests, but this is all I can think of at this point. I think I've covered the cases of the recursive definition properly now. Conceptually this is a very small patch. I've added a bunch of asserts and broken some complex lines up though. The first chunk deals with complex_args and elides superfluous parens around (x). The second chunk does the same eliding but for non-complex args. Any number of extra parens should be elided properly now. I will apply to head and 2.5.1 later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 00:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the ((((x)))) problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Fri Sep 22 19:19:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 10:19:16 -0700 Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems Message-ID: Bugs item #1563630, was opened at 2006-09-22 17:19 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=1563630&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 From noreply at sourceforge.net Fri Sep 22 19:56:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 10:56:54 -0700 Subject: [ python-Bugs-1562822 ] decimal module borks thread Message-ID: Bugs item #1562822, was opened at 2006-09-21 13:59 Message generated for change (Comment added) made by steevel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaster (steevel) Assigned to: Nobody/Anonymous (nobody) Summary: decimal module borks thread Initial Comment: I got across this while trying to use MySQLdb in a thread. Since MySQLdb imports decimal I got the same error there. Code: (This happens in both 2.4 and 2.5) import thread, time, sys if len(sys.argv) > 1: import threading def test (): import decimal print 'Exiting test.' thread.start_new_thread(test, ()) time.sleep(1) Output: $ ./thread.py 1 Exiting test. $ ./thread.py Exiting test. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 ---------------------------------------------------------------------- >Comment By: Jaster (steevel) Date: 2006-09-22 19:56 Message: Logged In: YES user_id=1117967 I don't get this interface. Why can't I post a comment? To josiahcarlson: The program I'm currently writing is module based and I don't know what python modules my users will import. It shouldn't matter tho, either this is a "bug" or it needs to go in the documentation that you can't import them in a thread if you havent already imported them before. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-22 05:48 Message: Logged In: YES user_id=341410 I believe it is an issue with the import lock. If you 'import decimal' prior to starting up your subthread, everything will run fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&group_id=5470 From noreply at sourceforge.net Fri Sep 22 22:25:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 13:25:44 -0700 Subject: [ python-Bugs-1562822 ] decimal module borks thread Message-ID: Bugs item #1562822, was opened at 2006-09-21 04:59 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaster (steevel) Assigned to: Nobody/Anonymous (nobody) Summary: decimal module borks thread Initial Comment: I got across this while trying to use MySQLdb in a thread. Since MySQLdb imports decimal I got the same error there. Code: (This happens in both 2.4 and 2.5) import thread, time, sys if len(sys.argv) > 1: import threading def test (): import decimal print 'Exiting test.' thread.start_new_thread(test, ()) time.sleep(1) Output: $ ./thread.py 1 Exiting test. $ ./thread.py Exiting test. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python2.5/lib/python2.5/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.5/lib/python2.5/threading.py", line 656, in __exitfunc self._Thread__delete() File "/usr/local/python2.5/lib/python2.5/threading.py", line 540, in __delete del _active[_get_ident()] KeyError: -1209698640 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-22 13:25 Message: Logged In: YES user_id=341410 It's not so much that you can't import in a thread, it's that you can't import in a thread when the importer is running in another thread. When you run a module via 'python module.py', Python compiles that module into bytecode, then imports the module, which results in the module being executed. The execution of the module performs the various imports, function definitions, class definitions, etc. When you start up a thread while the module is being imported, the import lock doesn't know what to do and bails out, leaving you with the situation you are having. Try rewriting your module like: import thread import time import decimal def test(): import decimal print "exiting test" def main(): thread.start_new_thread(test, ()) time.sleep(1) Then running it via: python -c "import tmodule;tmodule.main()" And really, aside from "importing in a thread can be troublesome, if you don't know what you are doing, don't do it", what kind of documentation change would you suggest, and where would it go? ---------------------------------------------------------------------- Comment By: Jaster (steevel) Date: 2006-09-22 10:56 Message: Logged In: YES user_id=1117967 I don't get this interface. Why can't I post a comment? To josiahcarlson: The program I'm currently writing is module based and I don't know what python modules my users will import. It shouldn't matter tho, either this is a "bug" or it needs to go in the documentation that you can't import them in a thread if you havent already imported them before. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-09-21 20:48 Message: Logged In: YES user_id=341410 I believe it is an issue with the import lock. If you 'import decimal' prior to starting up your subthread, everything will run fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562822&group_id=5470 From noreply at sourceforge.net Fri Sep 22 23:15:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 14:15:20 -0700 Subject: [ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems Message-ID: Bugs item #1563630, was opened at 2006-09-22 12:19 Message generated for change (Comment added) made by jordanramz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani ---------------------------------------------------------------------- Comment By: jordanramz (jordanramz) Date: 2006-09-22 16:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everytime I go back to run it, the hourglass on my mouse shows up for a few seconds and then nothing. At first I had v2.4.3 because that's what we're using in my class, but I tried v2.5(final) thinking it would help, but it didn't, so I reinstalled v2.4.3. I noticed that with my task manager in view, when I click the IDLE program my processes jump up one number for a few seconds also, then goes back. So apparently it's running but then ending before it loads up? I tried messing with my firewall and stuff also, with no success, so I'm in the same boat as you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 From noreply at sourceforge.net Sat Sep 23 00:17:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 15:17:45 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 01:17 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=1563759&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 00:35:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 15:35:24 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by dstrozzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: David Strozzi (dstrozzi) Date: 2006-09-22 18:35 Message: Logged In: YES user_id=1056922 Hi, Python 2.5 installs, and idle runs, perfectly on my 10.3.9 system! Kudos to our noble MacOS builder! Looks like the problem vanished. I'm going to risk bugging people here about my inability to compile numpy 1.0* (* = betas and current release candidate 1) on the same 10.3.9 system. The end of this post is a dump of trying to install as per numpy directions. One line is very suspicious: C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -arch pcc -arch i386?? Smells bad. 10.4u.sdk?? I have sys 10.3.9; /Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but not 10.4u. Right after this, I get the error: gcc: cannot specify -o with -c or -S and multiple compilations gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't replaced my 'main' gcc with it. Anyway, thoughts are greatly appreciated, both by me and presumably the numpy people (who haven't replied to any of my bug postings :) ) ********** The whole dump ************** > python setup.py install Running from numpy source directory. F2PY Version 2_3198 blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] running install running build running config_fc running build_src building py_modules sources building extension "numpy.core.multiarray" sources Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' gcc: _configtest.c gcc: cannot specify -o with -c or -S and multiple compilations gcc: cannot specify -o with -c or -S and multiple compilations failure. removing: _configtest.c _configtest.o numpy/core/setup.py:50: DeprecationWarning: raising a string exception is deprecated raise "ERROR: Failed to test configuration" Traceback (most recent call last): File "setup.py", line 89, in setup_package() File "setup.py", line 82, in setup_package configuration=configuration ) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py", line 16, in run r = old_install.run(self) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py", line 506, in run self.run_command('build') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 87, in run self.build_sources() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 106, in build_sources self.build_extension_sources(ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 212, in build_extension_sources sources = self.generate_sources(sources, ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 270, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 50, in generate_config_h raise "ERROR: Failed to test configuration" ERROR: Failed to test configuration strozzi2 at riata: ~/downloads/numpy-1.0rc1 > ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 17:10 Message: Logged In: YES user_id=580910 The scary bit is that the bug was "fixed" due to unclear differences between the build environment used for 2.5c1 and 2.5c2. I'll be building 2.5final as well, so expect this will stay fixed but I'm not entirely happy due to not knowing what caused the failure in the first place. It looks like 2.5c1 was build with a slighly different version of GCC (although both machines has Xcode 2.3 installed). BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this weekend. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 17:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 13:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 12:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 11:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 11:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Sat Sep 23 02:07:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 17:07:20 -0700 Subject: [ python-Bugs-1563807 ] Build of Python 2.5 on AIX 5.3 with GCC Fails Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 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=1563807&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Daniel Clark (djbclark) Assigned to: Nobody/Anonymous (nobody) Summary: Build of Python 2.5 on AIX 5.3 with GCC Fails Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 02:48:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 17:48:19 -0700 Subject: [ python-Bugs-1563807 ] Build of Python 2.5 on AIX 5.3 with GCC Fails Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Daniel Clark (djbclark) >Assigned to: Thomas Heller (theller) Summary: Build of Python 2.5 on AIX 5.3 with GCC Fails Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 03:00:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 18:00:33 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with g fails with ld ffi error on AIX 5.3 GCC Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Settings changed) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) >Summary: _ctypes built with g fails with ld ffi error on AIX 5.3 GCC Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 03:01:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 18:01:45 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Settings changed) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) >Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 04:07:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 19:07:09 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 05:44:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 20:44:57 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:00:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:00:39 -0700 Subject: [ python-Bugs-1563963 ] Typo in whatsnew/pep-342.html Message-ID: Bugs item #1563963, was opened at 2006-09-23 13:00 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=1563963&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Xavier Bassery (balthus) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in whatsnew/pep-342.html Initial Comment: In http://docs.python.org/whatsnew/pep-342.html the following a word is missing in the following excerpt: "Because yield will often be returning None, you should always check for this case. Don't just use its value in expressions unless you're sure that the send() method will be the only method used *$$* resume your generator function." My guess is that "to" would be a good candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:15:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:15:55 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:18:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:18:06 -0700 Subject: [ python-Bugs-1563185 ] ,msi fails for AMD Turion 64 mobile Message-ID: Bugs item #1563185, was opened at 2006-09-22 00:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563185&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: ,msi fails for AMD Turion 64 mobile Initial Comment: I tried to install python-2.5.amd64.msi on my HP notebook with an AMD Turion 64 Mobile and I got the error message "This installation is not supported by this processor type." Is this really different than some other AMD 64, or do you just fail to recognize the ID? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:18 Message: Logged In: YES user_id=21627 You should download the 32-bit installer, not the 64-bit installer, as you apparently run a 32-bit operating system (on your dual-mode 32/64-bit processor). The AMD64 MSI file can work only on a 64-bit operating system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563185&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:19:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:19:11 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 00:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:19 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:23:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:23:07 -0700 Subject: [ python-Bugs-1563981 ] IDLE invokes completion even when running code Message-ID: Bugs item #1563981, was opened at 2006-09-23 13:23 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=1563981&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE invokes completion even when running code Initial Comment: When you do raw_input() A instead of putting the tab character into the input buffer, IDLE opens the completion window. It should not do this, since the user is interacting with its application, not with the Python interpreter at this point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563981&group_id=5470 From noreply at sourceforge.net Sat Sep 23 13:37:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 04:37:48 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Closed Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:06:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:06:50 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:12:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:12:28 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 00:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 13:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:19 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:14:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:14:37 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:29:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:29:16 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:37:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:37:05 -0700 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Closed Resolution: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=21627 Skip, your problem is completely independent of the problem reported here. It rather has to do with the way Sun non-C89 API. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-09-12 22:01 Message: Logged In: YES user_id=44345 I'm coming late to this party (it seems the bar is closed), however... At work we just stumbled upon a similar problem when trying to build the latest release of matplotlib (0.87.5, avaialble at http://matplotlib.sourceforge.net/) on Solaris 10 using gcc 3.4.1. We get errors like the following: In file included from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/bits/postypes.h:46, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iosfwd:50, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ios:44, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ostream:45, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iostream:45, from swig/agg_buffer.h:7, from src/agg.cxx:1584: /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:145: error: `::btowc' has not been declared /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:150: error: `::fwide' has not been declared If I add #include at the top of Python.h it builds fine (modulo a couple warnings). One warning which might be significant is: In file included from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:10, from src/agg.cxx:97: /opt/app/g++lib6/python-2.4/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/wchar.h:11, from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:7, from src/agg.cxx:97: /usr/include/sys/feature_tests.h:266:1: warning: this is the location of the previous definition I don't have enough gcc smarts to understand what's happening, or even if it's the same problem Dimitri encountered on Solaris 8, but it kind of looks like the same sort of problem to me. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-03 22:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 11:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:54:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:54:56 -0700 Subject: [ python-Bugs-1564039 ] 2.6 changes stomp on 2.5 docs Message-ID: Bugs item #1564039, was opened at 2006-09-23 08: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=1564039&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: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: ggpauly (ggpauly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.6 changes stomp on 2.5 docs Initial Comment: Several links of the 2.5 changes index go to 2.6 changes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:55:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:55:10 -0700 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:56:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:56:00 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 15:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:56:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:56:29 -0700 Subject: [ python-Bugs-1562171 ] Fails to install on Fedora Core 5 Message-ID: Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Settings changed) made by mnsummerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. ---------------------------------------------------------------------- Comment By: Mark Summerfield (mnsummerfield) Date: 2006-09-21 07:05 Message: Logged In: YES user_id=1602435 I didn't run out of disk space, I've 28GB free... I did try several times, (including make clean, rerun configure, make, make tests, and make install), and yes, it always failed in the same place. And just to make really sure, I have just tried the whole process again. I deleted my Python-2.5 directory, unpacked the whole thing again, ran configure, added -fwrapv to the Makefile, and ran make and make test. This time make test had only one "unexpected" skipped test: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 283 tests OK. 36 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 1 skip unexpected on linux2: test_bsddb Next I ran make install... and it worked! Maybe there's some dependency on having a dbm of some sort? Anyway, sorry for the false alarm. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 17:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:56:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:56:39 -0700 Subject: [ python-Bugs-1562171 ] Fails to install on Fedora Core 5 Message-ID: Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Settings changed) made by mnsummerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. ---------------------------------------------------------------------- Comment By: Mark Summerfield (mnsummerfield) Date: 2006-09-21 07:05 Message: Logged In: YES user_id=1602435 I didn't run out of disk space, I've 28GB free... I did try several times, (including make clean, rerun configure, make, make tests, and make install), and yes, it always failed in the same place. And just to make really sure, I have just tried the whole process again. I deleted my Python-2.5 directory, unpacked the whole thing again, ran configure, added -fwrapv to the Makefile, and ran make and make test. This time make test had only one "unexpected" skipped test: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 283 tests OK. 36 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 1 skip unexpected on linux2: test_bsddb Next I ran make install... and it worked! Maybe there's some dependency on having a dbm of some sort? Anyway, sorry for the false alarm. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 17:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 From noreply at sourceforge.net Sat Sep 23 14:57:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 05:57:07 -0700 Subject: [ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects Message-ID: Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. ---------------------------------------------------------------------- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:57 Message: Logged In: YES user_id=1067739 test_struct_run.py works in 2.4, throws exception in 2.5 ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 15:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 From noreply at sourceforge.net Sat Sep 23 20:12:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 11:12:24 -0700 Subject: [ python-Bugs-1563963 ] Typo in whatsnew/pep-342.html Message-ID: Bugs item #1563963, was opened at 2006-09-23 04:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Xavier Bassery (balthus) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in whatsnew/pep-342.html Initial Comment: In http://docs.python.org/whatsnew/pep-342.html the following a word is missing in the following excerpt: "Because yield will often be returning None, you should always check for this case. Don't just use its value in expressions unless you're sure that the send() method will be the only method used *$$* resume your generator function." My guess is that "to" would be a good candidate. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-23 11:12 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51988. 2.5 Committed revision 51989. head ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&group_id=5470 From noreply at sourceforge.net Sat Sep 23 20:52:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 11:52:26 -0700 Subject: [ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk Message-ID: Bugs item #1563046, was opened at 2006-09-21 19:55 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-23 20:52 Message: Logged In: YES user_id=580910 If this gets used (and that's a big if at the moment) it should not look in the users private library folder, because the system might be used by multiple users and a system wide install should not use files that happen to be in the home directory of one of them. I don't like using this script during installation but would prefer a slightly different solution: ship this script in /Applications/MacPython 2.5 and tell users about it in our documentation (the installer documentation, the pythonmac.org FAQ and possibly the tkinter docs). If Tiger's copy of Tk is really bad enough to avoid using it completely we should find a way to ship a minimal copy of Tcl/Tk with our installer (installed into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/ {Tcl,Tk}.framework), again with your script installed in the applications folder for people that want to use a bleeding edge copy of Tk. I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks because of the support issue this raises: it is hard enough to debug problems as it is without users haveing slightly different library versions. BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, / Library/Frameworks is named like that in all languages, the name you see in the Finder might be different but that's because the Finder localizes the names of a number of folders (hence the ".localized" file in a number of folders). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470 From noreply at sourceforge.net Sat Sep 23 20:52:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Sep 2006 11:52:07 -0700 Subject: [ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk Message-ID: Bugs item #1563046, was opened at 2006-09-21 19:55 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-23 20:52 Message: Logged In: YES user_id=580910 If this gets used (and that's a big if at the moment) it should not look in the users private library folder, because the system might be used by multiple users and a system wide install should not use files that happen to be in the home directory of one of them. I don't like using this script during installation but would prefer a slightly different solution: ship this script in /Applications/MacPython 2.5 and tell users about it in our documentation (the installer documentation, the pythonmac.org FAQ and possibly the tkinter docs). If Tiger's copy of Tk is really bad enough to avoid using it completely we should find a way to ship a minimal copy of Tcl/Tk with our installer (installed into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/ {Tcl,Tk}.framework), again with your script installed in the applications folder for people that want to use a bleeding edge copy of Tk. I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks because of the support issue this raises: it is hard enough to debug problems as it is without users haveing slightly different library versions. BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, / Library/Frameworks is named like that in all languages, the name you see in the Finder might be different but that's because the Finder localizes the names of a number of folders (hence the ".localized" file in a number of folders). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470 From noreply at sourceforge.net Sun Sep 24 15:05:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 06:05:52 -0700 Subject: [ python-Bugs-1564508 ] BaseCookie does not support "$Port" Message-ID: Bugs item #1564508, was opened at 2006-09-24 15:05 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=1564508&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 Submitted By: Anders Aagaard (aagaande) Assigned to: Nobody/Anonymous (nobody) Summary: BaseCookie does not support "$Port" Initial Comment: Sending a cookie containing $Port to python's Cookie.py causes this exception: File "/usr/lib64/python2.4/Cookie.py", line 621, in load self.__ParseString(rawdata) File "/usr/lib64/python2.4/Cookie.py", line 646, in __ParseString M[ K[1:] ] = V File "/usr/lib64/python2.4/Cookie.py", line 437, in __setitem__ raise CookieError("Invalid Attribute %s" % K) CookieError: Invalid Attribute port For RFC2965 compatibility more keys has to be added to the Morsel class in the same file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564508&group_id=5470 From noreply at sourceforge.net Sun Sep 24 18:15:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 09:15:37 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open >Resolution: Fixed Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-24 18:15 Message: Logged In: YES user_id=580910 I'm seriously temped to call the problem you're having with numpy a bug in their system. What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) is build as a universal binary on OSX 10.4. This is why you see '-arch ppc - arch x86' in the compiler invocation. This works correctly on 10.4 but not on 10.3.9, which is why distutils strips those arguments from the command-line on 10.3 systems. That's all fine when you use the stock distutils, but numpy uses custom build commands and those don't work correctly with a universal build of python on 10.3. The easiest way for you to get going again is open /Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then try to build numpy again ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-23 00:35 Message: Logged In: YES user_id=1056922 Hi, Python 2.5 installs, and idle runs, perfectly on my 10.3.9 system! Kudos to our noble MacOS builder! Looks like the problem vanished. I'm going to risk bugging people here about my inability to compile numpy 1.0* (* = betas and current release candidate 1) on the same 10.3.9 system. The end of this post is a dump of trying to install as per numpy directions. One line is very suspicious: C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -arch pcc -arch i386?? Smells bad. 10.4u.sdk?? I have sys 10.3.9; /Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but not 10.4u. Right after this, I get the error: gcc: cannot specify -o with -c or -S and multiple compilations gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't replaced my 'main' gcc with it. Anyway, thoughts are greatly appreciated, both by me and presumably the numpy people (who haven't replied to any of my bug postings :) ) ********** The whole dump ************** > python setup.py install Running from numpy source directory. F2PY Version 2_3198 blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] running install running build running config_fc running build_src building py_modules sources building extension "numpy.core.multiarray" sources Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' gcc: _configtest.c gcc: cannot specify -o with -c or -S and multiple compilations gcc: cannot specify -o with -c or -S and multiple compilations failure. removing: _configtest.c _configtest.o numpy/core/setup.py:50: DeprecationWarning: raising a string exception is deprecated raise "ERROR: Failed to test configuration" Traceback (most recent call last): File "setup.py", line 89, in setup_package() File "setup.py", line 82, in setup_package configuration=configuration ) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py", line 16, in run r = old_install.run(self) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py", line 506, in run self.run_command('build') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 87, in run self.build_sources() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 106, in build_sources self.build_extension_sources(ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 212, in build_extension_sources sources = self.generate_sources(sources, ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 270, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 50, in generate_config_h raise "ERROR: Failed to test configuration" ERROR: Failed to test configuration strozzi2 at riata: ~/downloads/numpy-1.0rc1 > ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 23:10 Message: Logged In: YES user_id=580910 The scary bit is that the bug was "fixed" due to unclear differences between the build environment used for 2.5c1 and 2.5c2. I'll be building 2.5final as well, so expect this will stay fixed but I'm not entirely happy due to not knowing what caused the failure in the first place. It looks like 2.5c1 was build with a slighly different version of GCC (although both machines has Xcode 2.3 installed). BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this weekend. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 23:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 19:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 17:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Sun Sep 24 19:18:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 10:18:49 -0700 Subject: [ python-Bugs-1564039 ] 2.6 changes stomp on 2.5 docs Message-ID: Bugs item #1564039, was opened at 2006-09-23 14:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&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: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: ggpauly (ggpauly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.6 changes stomp on 2.5 docs Initial Comment: Several links of the 2.5 changes index go to 2.6 changes ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-24 19:18 Message: Logged In: YES user_id=21627 Several of these have been fixed a few days ago. Can you spot any more? If so, please provide exact URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470 From noreply at sourceforge.net Sun Sep 24 20:46:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 11:46:29 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: Fixed Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-24 20:46 Message: Logged In: YES user_id=580910 It turns out to be a buglet in python2.5 after all. There is some code in distutils.sysconfig to strip out the -arch and -isysroot flags from the build flags when you ask for them through that way, but that doesn't fix all variables that need to be fixed. I'll apply a patch in the morning. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-24 18:15 Message: Logged In: YES user_id=580910 I'm seriously temped to call the problem you're having with numpy a bug in their system. What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) is build as a universal binary on OSX 10.4. This is why you see '-arch ppc - arch x86' in the compiler invocation. This works correctly on 10.4 but not on 10.3.9, which is why distutils strips those arguments from the command-line on 10.3 systems. That's all fine when you use the stock distutils, but numpy uses custom build commands and those don't work correctly with a universal build of python on 10.3. The easiest way for you to get going again is open /Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then try to build numpy again ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-23 00:35 Message: Logged In: YES user_id=1056922 Hi, Python 2.5 installs, and idle runs, perfectly on my 10.3.9 system! Kudos to our noble MacOS builder! Looks like the problem vanished. I'm going to risk bugging people here about my inability to compile numpy 1.0* (* = betas and current release candidate 1) on the same 10.3.9 system. The end of this post is a dump of trying to install as per numpy directions. One line is very suspicious: C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -arch pcc -arch i386?? Smells bad. 10.4u.sdk?? I have sys 10.3.9; /Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but not 10.4u. Right after this, I get the error: gcc: cannot specify -o with -c or -S and multiple compilations gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't replaced my 'main' gcc with it. Anyway, thoughts are greatly appreciated, both by me and presumably the numpy people (who haven't replied to any of my bug postings :) ) ********** The whole dump ************** > python setup.py install Running from numpy source directory. F2PY Version 2_3198 blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] running install running build running config_fc running build_src building py_modules sources building extension "numpy.core.multiarray" sources Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' gcc: _configtest.c gcc: cannot specify -o with -c or -S and multiple compilations gcc: cannot specify -o with -c or -S and multiple compilations failure. removing: _configtest.c _configtest.o numpy/core/setup.py:50: DeprecationWarning: raising a string exception is deprecated raise "ERROR: Failed to test configuration" Traceback (most recent call last): File "setup.py", line 89, in setup_package() File "setup.py", line 82, in setup_package configuration=configuration ) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py", line 16, in run r = old_install.run(self) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py", line 506, in run self.run_command('build') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 87, in run self.build_sources() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 106, in build_sources self.build_extension_sources(ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 212, in build_extension_sources sources = self.generate_sources(sources, ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 270, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 50, in generate_config_h raise "ERROR: Failed to test configuration" ERROR: Failed to test configuration strozzi2 at riata: ~/downloads/numpy-1.0rc1 > ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 23:10 Message: Logged In: YES user_id=580910 The scary bit is that the bug was "fixed" due to unclear differences between the build environment used for 2.5c1 and 2.5c2. I'll be building 2.5final as well, so expect this will stay fixed but I'm not entirely happy due to not knowing what caused the failure in the first place. It looks like 2.5c1 was build with a slighly different version of GCC (although both machines has Xcode 2.3 installed). BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this weekend. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 23:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 19:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 17:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Mon Sep 25 01:43:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 16:43:07 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-24 23:43 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=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Mon Sep 25 08:17:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 23:17:38 -0700 Subject: [ python-Bugs-1564039 ] 2.6 changes stomp on 2.5 docs Message-ID: Bugs item #1564039, was opened at 2006-09-23 12:54 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&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: Python 2.6 >Status: Pending Resolution: None Priority: 5 Submitted By: ggpauly (ggpauly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.6 changes stomp on 2.5 docs Initial Comment: Several links of the 2.5 changes index go to 2.6 changes ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-24 17:18 Message: Logged In: YES user_id=21627 Several of these have been fixed a few days ago. Can you spot any more? If so, please provide exact URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470 From noreply at sourceforge.net Mon Sep 25 08:18:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 23:18:46 -0700 Subject: [ python-Bugs-1560984 ] python 2.5 fails to build with --as-needed Message-ID: Bugs item #1560984, was opened at 2006-09-18 19:57 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&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 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 fails to build with --as-needed Initial Comment: Passing -Wl,--as-needed to gcc in LDFLAGS gives an error, patch currently in the works. ---------------------------------------------------------------------- Comment By: Chaza (masterdriverz) Date: 2006-09-21 12:02 Message: Logged In: YES user_id=1096685 Patch submitted to https://sourceforge.net/tracker/index.php?func=detail&aid=1562825&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&group_id=5470 From noreply at sourceforge.net Mon Sep 25 09:05:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 00:05:13 -0700 Subject: [ python-Bugs-1557232 ] Parser crash Message-ID: Bugs item #1557232, was opened at 2006-09-12 15:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Closed >Resolution: Fixed Priority: 7 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-25 07:05 Message: Logged In: YES user_id=849994 Backported in rev. 51999. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-22 08:21 Message: Logged In: YES user_id=33168 Committed revision 51972. (2.6) Still needs backport. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-18 05:55 Message: Logged In: YES user_id=33168 Attaching a new patch with tests. There probably should be more tests, but this is all I can think of at this point. I think I've covered the cases of the recursive definition properly now. Conceptually this is a very small patch. I've added a bunch of asserts and broken some complex lines up though. The first chunk deals with complex_args and elides superfluous parens around (x). The second chunk does the same eliding but for non-complex args. Any number of extra parens should be elided properly now. I will apply to head and 2.5.1 later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 07:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 06:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the ((((x)))) problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 06:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((((((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 05:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(((((x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 From noreply at sourceforge.net Mon Sep 25 14:51:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 05:51:47 -0700 Subject: [ python-Bugs-1565071 ] update Lib/plat-linux2/IN.py Message-ID: Bugs item #1565071, was opened at 2006-09-25 14:51 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=1565071&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: update Lib/plat-linux2/IN.py Initial Comment: there's a request to update this module to add missing IN.SIO* definitions. How should that be done? Just re-running h2py drops all SIO* definitions, because the linux/sockios.h header isn't included anymore. requested at http://launchpad.net/bugs/58081 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&group_id=5470 From noreply at sourceforge.net Mon Sep 25 15:15:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 06:15:05 -0700 Subject: [ python-Bugs-1565087 ] Misbehaviour in zipfile Message-ID: Bugs item #1565087, was opened at 2006-09-25 13:15 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=1565087&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 Submitted By: Richard Philips (rphilips) Assigned to: Nobody/Anonymous (nobody) Summary: Misbehaviour in zipfile Initial Comment: Python 2.5 In library module zipfile, a ZipFile object has method write( filename[, arcname[, compress_type]]) If arcname is not specified, it defaults to the pathname of filename without a drive letter and with leading path separators removed. That is OK. But if arcname is explicitely specified, the drive letter and leading path separators are also removed. I think that is not OK. thanks, Richard Philips ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565087&group_id=5470 From noreply at sourceforge.net Mon Sep 25 16:28:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 07:28:48 -0700 Subject: [ python-Bugs-1565129 ] make plistlib.py available in every install Message-ID: Bugs item #1565129, was opened at 2006-09-25 16:28 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=1565129&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: make plistlib.py available in every install Initial Comment: [requested in http://bugs.debian.org/386738] plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too it's e.g. needed for packaging calendar-server -- Apple's calendar server The module could be packaged separately, but should better be used from the standard library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470 From noreply at sourceforge.net Mon Sep 25 17:08:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 08:08:57 -0700 Subject: [ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows Message-ID: Bugs item #1565150, was opened at 2006-09-25 11:08 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=1565150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 From noreply at sourceforge.net Mon Sep 25 17:10:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 08:10:07 -0700 Subject: [ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows Message-ID: Bugs item #1565150, was opened at 2006-09-25 11:08 Message generated for change (Comment added) made by glassfordm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 ---------------------------------------------------------------------- >Comment By: Mike Glassford (glassfordm) Date: 2006-09-25 11:10 Message: Logged In: YES user_id=963931 Sorry, although it can be inferred from the report, I should mention that this is with Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 From noreply at sourceforge.net Mon Sep 25 17:42:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 08:42:22 -0700 Subject: [ python-Bugs-1565129 ] make plistlib.py available in every install Message-ID: Bugs item #1565129, was opened at 2006-09-25 16:28 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: make plistlib.py available in every install Initial Comment: [requested in http://bugs.debian.org/386738] plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too it's e.g. needed for packaging calendar-server -- Apple's calendar server The module could be packaged separately, but should better be used from the standard library. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-09-25 17:42 Message: Logged In: YES user_id=1326842 This is a duplicate of bug #779460: http://www.python.org/sf/779460 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&group_id=5470 From noreply at sourceforge.net Mon Sep 25 22:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 13:43:30 -0700 Subject: [ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk Message-ID: Bugs item #1563046, was opened at 2006-09-21 10:55 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2006-09-25 13:43 Message: Logged In: YES user_id=431773 I see what you mean about different installations. I think the following might work better: - Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. This will fall back to the built in /System/Library/Frameworks if the user has not installed an 8.4 of their own. It avoids a few of the issues you bring up and is simpler and more robust than what I originally suggested. Advantages: - All installations would be the same. - If the user installs a new Tcl/Tk after installing Python, it would be used (unless it's 8.5, which would not be safe to try with Python). It still does not address your concern than a user might accidentally have a Tcl/Tk that they don't want to use. I'd personally be happier if users could easily upgrade their Tcl/Tk (since the installed one is so bad), so I see this as more of an advantage than a disadvantage. Users aren't going to typically install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've seen more requests for help than I have over the years. I'm not keen on including a Tcl/Tk for several reasons: - It can be tricky to add needed additions (my app uses the "snack" sound library, for example). A standard Tcl/Tk makes this much easier (and in fact ActiveState Tcl/Tk already includes all additions most folks would want). - There is no universal Tcl/Tk yet (though one is planned). I personally don't want to try to build one. - Which version would you use? Even 8.4.11 has some important known bugs, and 8.4.13 has different ones (at least one of which is very nasty for my application, so I stick with 8.4.11 for now). So my personal suggestion is that we modify _tkinter.so using Bob Ippolito's recipe unchanged (no fancy script that hunts for an installed Tcl/Tk). It will be completely compatible with the built in Tcl/Tk but gives any real users of Tcl/ Tk (anyone who isn't just writing "hello world") a trivial way to get a decent version. I also suggest ditching the python script (or simplifying it to just institute Bob's recipe, but a shell script probably makes more sense for that job). Note that Bob's recipe is in the comments at the top of my python script. Thanks for the note about /Library/Frameworks. I had no idea it was a universal name. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-23 11:52 Message: Logged In: YES user_id=580910 If this gets used (and that's a big if at the moment) it should not look in the users private library folder, because the system might be used by multiple users and a system wide install should not use files that happen to be in the home directory of one of them. I don't like using this script during installation but would prefer a slightly different solution: ship this script in /Applications/MacPython 2.5 and tell users about it in our documentation (the installer documentation, the pythonmac.org FAQ and possibly the tkinter docs). If Tiger's copy of Tk is really bad enough to avoid using it completely we should find a way to ship a minimal copy of Tcl/Tk with our installer (installed into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/ {Tcl,Tk}.framework), again with your script installed in the applications folder for people that want to use a bleeding edge copy of Tk. I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks because of the support issue this raises: it is hard enough to debug problems as it is without users haveing slightly different library versions. BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, / Library/Frameworks is named like that in all languages, the name you see in the Finder might be different but that's because the Finder localizes the names of a number of folders (hence the ".localized" file in a number of folders). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470 From noreply at sourceforge.net Mon Sep 25 23:11:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 14:11:51 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-24 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Mon Sep 25 23:33:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 14:33:43 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-24 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Tue Sep 26 06:20:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 21:20:42 -0700 Subject: [ python-Bugs-1565150 ] os.stat() subsecond file mode time is incorrect on Windows Message-ID: Bugs item #1565150, was opened at 2006-09-25 08:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Glassford (glassfordm) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() subsecond file mode time is incorrect on Windows Initial Comment: Either the new ability of os.stat() to report subsecond file modification times, or the os.utime() function, appears to have a bug on Windows. The following script illustrates. The problem is that the decimal part of the modification time reported by os.stat() is always equal to the decimal part of what was passed to os.utime() divided by ten (and rounded). ###Begin Script import os strPath = "c:/test.xxx" #Create the file f = open(strPath, 'w') f.close() #Set the file mod time t1 = 1159195039.2 os.utime(strPath, (t1, t1)) #Get the file mod time t2 = os.stat(strPath).st_mtime print t1, t2 ###Sample output 1159195039.2 1159195039.02 ---------------------------------------------------------------------- Comment By: Mike Glassford (glassfordm) Date: 2006-09-25 08:10 Message: Logged In: YES user_id=963931 Sorry, although it can be inferred from the report, I should mention that this is with Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565150&group_id=5470 From noreply at sourceforge.net Tue Sep 26 07:34:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 22:34:50 -0700 Subject: [ python-Bugs-1565509 ] Repair or Change installation error Message-ID: Bugs item #1565509, was opened at 2006-09-26 05:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Repair or Change installation error Initial Comment: When I re-run the Python 2.5 final installer and choose either Repair or Change options, it makes it to the "Publish product information" step then says: "A network error occurred while attempting to read from the file: C:\Documents and Settings\username\Desktop\python-2.5 [1].msi" The thing is, I saved the file as python-2.5.msi and the file it mentions does not exist. If I copy python- 2.5.msi to python-2.5[1].msi, then run python-2.5.msi, the installation works! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565509&group_id=5470 From noreply at sourceforge.net Tue Sep 26 08:10:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 23:10:00 -0700 Subject: [ python-Bugs-1565514 ] does not raise SystemError on too many nested blocks Message-ID: Bugs item #1565514, was opened at 2006-09-26 06: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=1565514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: does not raise SystemError on too many nested blocks Initial Comment: Simple script attached, in python 2.4.3 I get reasonable results: C:\>.\python24\python.exe nested.py File "nested.py", line 22 while 22: SystemError: too many statically nested blocks C:\> However in python 2.5 I get nothing: C:\>.\python25\python.exe nested.py C:\> Shouldn't the same error be raised? (Note that it's not executing the file, or the prints would occur). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 From noreply at sourceforge.net Tue Sep 26 08:58:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 23:58:18 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 06:58 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=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Tue Sep 26 11:10:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 02:10:54 -0700 Subject: [ python-Bugs-1565468 ] Install on WinXP always goes to C:\ Message-ID: Bugs item #1565468, was opened at 2006-09-25 23:05 Message generated for change (Comment added) made by piercew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wayne Pierce (piercew) Assigned to: Nobody/Anonymous (nobody) Summary: Install on WinXP always goes to C:\ Initial Comment: When I install Python on WinXP it always goes go C:\ even though I select C:\Python . This happens when Python is installed for just me or for all users on a system. The system is running WinXP SP 2 and the account installing has enough rights to install applications. An install log has been attached. ---------------------------------------------------------------------- >Comment By: Wayne Pierce (piercew) Date: 2006-09-26 05:10 Message: Logged In: YES user_id=4553 Since I cannot attach a file to a bug report I have placed the python.log file at http://shalofin.googlepages.com/python.log ---------------------------------------------------------------------- Comment By: Wayne Pierce (piercew) Date: 2006-09-25 23:40 Message: Logged In: YES user_id=4553 I am unable to attach a file. Every time a file is attached I receive a 'page cannot be found' error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&group_id=5470 From noreply at sourceforge.net Tue Sep 26 12:04:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 03:04:58 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 02:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-26 06:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Tue Sep 26 12:39:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 03:39:15 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-25 01:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:39 Message: Logged In: YES user_id=38388 Armin, is it possible that the missing Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is causing this ? I just had a look at the code and it appears that the comparison code checks the flag rather than just looking at the slot itself (didn't even know there was such a type flag). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Tue Sep 26 12:55:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 03:55:29 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-25 01:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:55 Message: Logged In: YES user_id=38388 Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via Py_TPFLAGS_DEFAULT. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:39 Message: Logged In: YES user_id=38388 Armin, is it possible that the missing Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is causing this ? I just had a look at the code and it appears that the comparison code checks the flag rather than just looking at the slot itself (didn't even know there was such a type flag). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Tue Sep 26 13:13:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 04:13:29 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-25 01:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 13:13 Message: Logged In: YES user_id=38388 In any case, the introduction of the Unicode tp_richcompare slot is likely the cause for this behavior: $python2.5 lowerstr.py u'baR' == l'Bar'? False $ python2.4 lowerstr.py u'baR' == l'Bar'? True Note that in both Python 2.4 and 2.5, the lowerstr.__eq__() method is not even called. This is probably due to the fact that Unicode can compare itself to strings, so the w.__eq__(v) part of the rich comparison is never tried. Now, the Unicode .__eq__() converts the string to Unicode, so the right hand side becomes u'Bar' in both cases. I guess a debugger session is due... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:55 Message: Logged In: YES user_id=38388 Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via Py_TPFLAGS_DEFAULT. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:39 Message: Logged In: YES user_id=38388 Armin, is it possible that the missing Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is causing this ? I just had a look at the code and it appears that the comparison code checks the flag rather than just looking at the slot itself (didn't even know there was such a type flag). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Tue Sep 26 13:33:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 04:33:20 -0700 Subject: [ python-Bugs-1565661 ] webbrowser on gnome runs wrong browser Message-ID: Bugs item #1565661, was opened at 2006-09-26 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&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 Submitted By: kangabroo (kangabroo) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser on gnome runs wrong browser Initial Comment: Epiphany is set as system default, but Firefox runs when webbrowser.open is called. in webbrowser.py - register_X_browsers(): 'gconftool-2 -g /desktop/gnome/url-handlers/http/command 2>/dev/null' returns 'epiphany %s' A BackgroundBrowser with a name of 'epiphany %s' is created. later on open(), subprocess.Popen(['epiphany %s', url], ....) is called. This throws an exception: OSError: [Errno 2] No such file or directory which is caught, and False is returned Solution: in webbrowser.py function register_X_browsers(), change: register("gnome", None, BackgroundBrowser(commd)) to register("gnome", None, BackgroundBrowser(commd.split())) System: Python 2.5, Linux 2.6.17, Gnome 2.14.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&group_id=5470 From noreply at sourceforge.net Tue Sep 26 17:21:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 08:21:58 -0700 Subject: [ python-Bugs-1565797 ] 'all' documentation missing online Message-ID: Bugs item #1565797, was opened at 2006-09-26 10: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=1565797&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 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470 From noreply at sourceforge.net Tue Sep 26 18:06:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 09:06:17 -0700 Subject: [ python-Bugs-1565797 ] 'all' documentation missing online Message-ID: Bugs item #1565797, was opened at 2006-09-26 17:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&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: Pending >Resolution: Invalid Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-26 18:06 Message: Logged In: YES user_id=21627 Could it be that you had been looking at an old version of the documentation (the new version wasn't online shortly after the release). I can clearly see 'all' documented as all( iterable) Return True if all elements of the iterable are true. Equivalent to: ... As for the separate note: what bugs page are you referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470 From noreply at sourceforge.net Tue Sep 26 19:01:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 10:01:44 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by dstrozzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: IDLE Group: Python 2.5 Status: Open Resolution: Fixed Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: David Strozzi (dstrozzi) Date: 2006-09-26 13:01 Message: Logged In: YES user_id=1056922 Great, thanks for sorting this out! I tried the edit you suggested in your first reply. Alas, I'm not root on my system - I am in the admin group, but I don't have total complete powers. The Python.Framework dir in /Library/Frameworks has owner admin and group wheel. I'm not in the wheel group, so can't edit files. I can wait for the patch, or maybe in the future the installer could make the group admin instead of wheel? This may be too esoteric to my system's setup... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-24 14:46 Message: Logged In: YES user_id=580910 It turns out to be a buglet in python2.5 after all. There is some code in distutils.sysconfig to strip out the -arch and -isysroot flags from the build flags when you ask for them through that way, but that doesn't fix all variables that need to be fixed. I'll apply a patch in the morning. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-24 12:15 Message: Logged In: YES user_id=580910 I'm seriously temped to call the problem you're having with numpy a bug in their system. What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) is build as a universal binary on OSX 10.4. This is why you see '-arch ppc - arch x86' in the compiler invocation. This works correctly on 10.4 but not on 10.3.9, which is why distutils strips those arguments from the command-line on 10.3 systems. That's all fine when you use the stock distutils, but numpy uses custom build commands and those don't work correctly with a universal build of python on 10.3. The easiest way for you to get going again is open /Library/Frameworks/ Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then try to build numpy again ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-22 18:35 Message: Logged In: YES user_id=1056922 Hi, Python 2.5 installs, and idle runs, perfectly on my 10.3.9 system! Kudos to our noble MacOS builder! Looks like the problem vanished. I'm going to risk bugging people here about my inability to compile numpy 1.0* (* = betas and current release candidate 1) on the same 10.3.9 system. The end of this post is a dump of trying to install as per numpy directions. One line is very suspicious: C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -arch pcc -arch i386?? Smells bad. 10.4u.sdk?? I have sys 10.3.9; /Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but not 10.4u. Right after this, I get the error: gcc: cannot specify -o with -c or -S and multiple compilations gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't replaced my 'main' gcc with it. Anyway, thoughts are greatly appreciated, both by me and presumably the numpy people (who haven't replied to any of my bug postings :) ) ********** The whole dump ************** > python setup.py install Running from numpy source directory. F2PY Version 2_3198 blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] running install running build running config_fc running build_src building py_modules sources building extension "numpy.core.multiarray" sources Generating build/src.macosx-10.3-fat-2.5/numpy/core/config.h customize NAGFCompiler customize AbsoftFCompiler customize IbmFCompiler Could not locate executable f95 customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using config C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' gcc: _configtest.c gcc: cannot specify -o with -c or -S and multiple compilations gcc: cannot specify -o with -c or -S and multiple compilations failure. removing: _configtest.c _configtest.o numpy/core/setup.py:50: DeprecationWarning: raising a string exception is deprecated raise "ERROR: Failed to test configuration" Traceback (most recent call last): File "setup.py", line 89, in setup_package() File "setup.py", line 82, in setup_package configuration=configuration ) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/install.py", line 16, in run r = old_install.run(self) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/install.py", line 506, in run self.run_command('build') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 87, in run self.build_sources() File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 106, in build_sources self.build_extension_sources(ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 212, in build_extension_sources sources = self.generate_sources(sources, ext) File "/Volumes/Data/strozzi2/downloads/numpy-1.0rc1/numpy/distutils/command/build_src.py", line 270, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 50, in generate_config_h raise "ERROR: Failed to test configuration" ERROR: Failed to test configuration strozzi2 at riata: ~/downloads/numpy-1.0rc1 > ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-14 17:10 Message: Logged In: YES user_id=580910 The scary bit is that the bug was "fixed" due to unclear differences between the build environment used for 2.5c1 and 2.5c2. I'll be building 2.5final as well, so expect this will stay fixed but I'm not entirely happy due to not knowing what caused the failure in the first place. It looks like 2.5c1 was build with a slighly different version of GCC (although both machines has Xcode 2.3 installed). BTW. The issue still exists for 2.4.x, I hope to work on the 2.4 branch this weekend. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-09-14 17:03 Message: Logged In: YES user_id=1056922 I just installed python 2.5 rc 2, and IDLE works! On the same 10.3.9 laptop which prompted me to post this bug. I guess the other who had problems should try rc2, and may this bug had been laid to rest. Thanks to whomever fixed it. ---------------------------------------------------------------------- Comment By: diggableme (diggableme) Date: 2006-09-09 13:18 Message: Logged In: YES user_id=1594326 I am a new user that is experiencing the same exact problem. I have OSX.3.9 and everytime I start IDLE, it freezes and the colorwheel somes up. When I view the console output, there are no errors or alert messages. I have also tried uninstalling and re-installing from the beginning with the same result. I have been using the instructions given at this site: http://www.python.org/download/mac/ desp I'm very interested to see if there is in fact a resolution to this problem. I'm at my wit's end. -dig ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 12:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 11:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 11:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Tue Sep 26 20:51:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 11:51:41 -0700 Subject: [ python-Bugs-1565919 ] sets missing from standard types list in ref Message-ID: Bugs item #1565919, was opened at 2006-09-26 18:51 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=1565919&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: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: sets missing from standard types list in ref Initial Comment: Sets (and frozensets) are missing from http://docs.python.org/ref/types.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470 From noreply at sourceforge.net Tue Sep 26 22:34:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 13:34:21 -0700 Subject: [ python-Bugs-1565967 ] pyexpat produces fals parsing results in CharacterDataHandle Message-ID: Bugs item #1565967, was opened at 2006-09-26 20:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat produces fals parsing results in CharacterDataHandle Initial Comment: hi, with bigger files pyexpat begins to split up some things parsed through CharacterDataHandler. c: "root-menu" pyexpat: "root-me" "nu" c: "TopLeft" pyexpat: "TopL" "eft" that strange results are also reproduseable on python2.4 greets ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&group_id=5470 From noreply at sourceforge.net Wed Sep 27 03:23:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 18:23:22 -0700 Subject: [ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop Message-ID: Bugs item #1566086, was opened at 2006-09-27 01:23 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=1566086&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 Submitted By: Fabien Devaux (fabinator) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE (regular expression) matching stuck in loop Initial Comment: See the code: http://pastebin.ca/183613 the "finditer()" call don't seems to return. Playing with the re can bypass the problem but it looks like a bug. (I'm really sorry if I did something wrong and didn't notice) note: I can reproduce it with python2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 From noreply at sourceforge.net Wed Sep 27 05:20:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 20:20:26 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 06:58 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2006-09-27 03:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 10:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Wed Sep 27 06:45:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 21:45:21 -0700 Subject: [ python-Bugs-1565514 ] does not raise SystemError on too many nested blocks Message-ID: Bugs item #1565514, was opened at 2006-09-25 23:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: does not raise SystemError on too many nested blocks Initial Comment: Simple script attached, in python 2.4.3 I get reasonable results: C:\>.\python24\python.exe nested.py File "nested.py", line 22 while 22: SystemError: too many statically nested blocks C:\> However in python 2.5 I get nothing: C:\>.\python25\python.exe nested.py C:\> Shouldn't the same error be raised? (Note that it's not executing the file, or the prints would occur). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-26 21:45 Message: Logged In: YES user_id=33168 The attached patch fixes the problem. I'm not so sure that the error should be a SystemError, but some exception should definitely be produced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 From noreply at sourceforge.net Wed Sep 27 07:23:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 22:23:51 -0700 Subject: [ python-Bugs-1566140 ] T_ULONG -> double rounding in PyMember_GetOne() Message-ID: Bugs item #1566140, was opened at 2006-09-27 07:23 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=1566140&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: T_ULONG -> double rounding in PyMember_GetOne() Initial Comment: Problem: Python/structmember.c's PyMember_GetOne currently handles getting T_ULONG members as follows: case T_ULONG: v = PyLong_FromDouble((double) *(unsigned long*)addr); break; On platforms with 64-bit longs, the double won't have enough precision to hold big values without rounding. The fix should be simple: v = PyLong_FromUnsignedLong(*(unsigned long*)addr); -- Piet Delport ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 From noreply at sourceforge.net Wed Sep 27 09:49:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 00:49:08 -0700 Subject: [ python-Bugs-1565967 ] pyexpat produces fals parsing results in CharacterDataHandle Message-ID: Bugs item #1565967, was opened at 2006-09-26 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&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: XML Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat produces fals parsing results in CharacterDataHandle Initial Comment: hi, with bigger files pyexpat begins to split up some things parsed through CharacterDataHandler. c: "root-menu" pyexpat: "root-me" "nu" c: "TopLeft" pyexpat: "TopL" "eft" that strange results are also reproduseable on python2.4 greets ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 This is not a bug. Instead, applications are expected to be aware of it, and deal with it accordingly. In general, it is not possible to provide all character data in a single callback, since that may exhaust the available address space. The actual splitting of character data depends on the internal buffering that Expat performs. If the buffer is exhausted in the middle of character data, those data are sent to the application before reading more input. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&group_id=5470 From noreply at sourceforge.net Wed Sep 27 09:49:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 00:49:54 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 08:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 05:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 12:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Wed Sep 27 10:56:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 01:56:17 -0700 Subject: [ python-Bugs-1566140 ] T_ULONG -> double rounding in PyMember_GetOne() Message-ID: Bugs item #1566140, was opened at 2006-09-27 07:23 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: T_ULONG -> double rounding in PyMember_GetOne() Initial Comment: Problem: Python/structmember.c's PyMember_GetOne currently handles getting T_ULONG members as follows: case T_ULONG: v = PyLong_FromDouble((double) *(unsigned long*)addr); break; On platforms with 64-bit longs, the double won't have enough precision to hold big values without rounding. The fix should be simple: v = PyLong_FromUnsignedLong(*(unsigned long*)addr); -- Piet Delport ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-09-27 10:56 Message: Logged In: YES user_id=1326842 Patch #1549049: http://www.python.org/sf/1549049 has a fix for this and some other bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 From noreply at sourceforge.net Wed Sep 27 10:58:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 01:58:51 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-24 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-09-27 08:58 Message: Logged In: YES user_id=4771 Well, yes, that's what I tried to explain. I also tried to explain how the 2.5 behavior is the "right" one, and the previous 2.4 behavior is a mere accident of convoluted __eq__-vs-__cmp__ code paths in the comparison code. In other words, there is no chance to get the 2.4 behavior in, say, Python 3000, because the __cmp__-related convolutions will be gone and we will only have the "right" behavior left. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 11:13 Message: Logged In: YES user_id=38388 In any case, the introduction of the Unicode tp_richcompare slot is likely the cause for this behavior: $python2.5 lowerstr.py u'baR' == l'Bar'? False $ python2.4 lowerstr.py u'baR' == l'Bar'? True Note that in both Python 2.4 and 2.5, the lowerstr.__eq__() method is not even called. This is probably due to the fact that Unicode can compare itself to strings, so the w.__eq__(v) part of the rich comparison is never tried. Now, the Unicode .__eq__() converts the string to Unicode, so the right hand side becomes u'Bar' in both cases. I guess a debugger session is due... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 10:55 Message: Logged In: YES user_id=38388 Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via Py_TPFLAGS_DEFAULT. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 10:39 Message: Logged In: YES user_id=38388 Armin, is it possible that the missing Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is causing this ? I just had a look at the code and it appears that the comparison code checks the flag rather than just looking at the slot itself (didn't even know there was such a type flag). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 21:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Wed Sep 27 12:22:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 03:22:43 -0700 Subject: [ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5 Message-ID: Bugs item #1564763, was opened at 2006-09-25 01:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode comparison change in 2.4 vs. 2.5 Initial Comment: Python 2.5 changed the behavior of unicode comparisons in a significant way from Python 2.4, causing a test case failure in a module of mine. All tests passed with an earlier version of 2.5, though unfortunately I don't know what version in particular it started failing with. The following code prints out all True on Python 2.4; the strings are compared case-insensitively, whether they are my lowerstr class, real strs, or unicodes. On Python 2.5, the comparison between lowerstr and unicode is false, but only in one direction. If I make lowerstr inherit from unicode rather than str, all comparisons are true again. So at the very least, this is internally inconsistent. I also think changing the behavior between 2.4 and 2.5 constitutes a serious bug. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-27 12:22 Message: Logged In: YES user_id=38388 Agreed. In Python 2.4, doing the u'baR' == l'Bar' comparison does try l'Bar' == u'baR' due to the special case in default_3way_compare() I removed for Python 2.5. In Python 2.5 it doesn't due to the new rich comparison code for Unicode. I don't see any way to make Joe's code work with Python 2.5 other than using unicode as baseclass which is probably the right things to do anyway in preparation for Python 3k. Closing as won't fix. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-27 10:58 Message: Logged In: YES user_id=4771 Well, yes, that's what I tried to explain. I also tried to explain how the 2.5 behavior is the "right" one, and the previous 2.4 behavior is a mere accident of convoluted __eq__-vs-__cmp__ code paths in the comparison code. In other words, there is no chance to get the 2.4 behavior in, say, Python 3000, because the __cmp__-related convolutions will be gone and we will only have the "right" behavior left. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 13:13 Message: Logged In: YES user_id=38388 In any case, the introduction of the Unicode tp_richcompare slot is likely the cause for this behavior: $python2.5 lowerstr.py u'baR' == l'Bar'? False $ python2.4 lowerstr.py u'baR' == l'Bar'? True Note that in both Python 2.4 and 2.5, the lowerstr.__eq__() method is not even called. This is probably due to the fact that Unicode can compare itself to strings, so the w.__eq__(v) part of the rich comparison is never tried. Now, the Unicode .__eq__() converts the string to Unicode, so the right hand side becomes u'Bar' in both cases. I guess a debugger session is due... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:55 Message: Logged In: YES user_id=38388 Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via Py_TPFLAGS_DEFAULT. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-26 12:39 Message: Logged In: YES user_id=38388 Armin, is it possible that the missing Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is causing this ? I just had a look at the code and it appears that the comparison code checks the flag rather than just looking at the slot itself (didn't even know there was such a type flag). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:33 Message: Logged In: YES user_id=4771 Sorry, I missed your comment: if lowerstr inherits from unicode then it just works. The reason is that 'abc'.__eq__(u'abc') returns NotImplemented, but u'abc'.__eq__('abc') returns True. This is only inconsistent because of the asymmetry between strings and unicodes: strings can be transparently turned into unicodes but not the other way around -- so unicode.__eq__(x) can accept a string as the argument x and convert it to a unicode transparently, but str.__eq__(x) does not try to convert x to a string if it is a unicode. It's not a completely convincing explanation, but I think it shows at least why we got at the current situation of Python 2.5. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-09-25 23:11 Message: Logged In: YES user_id=4771 This is an artifact of the change in the unicode class, which now has the proper __eq__, __ne__, __lt__, etc. methods instead of the semi-deprecated __cmp__. The mixture of __cmp__ and the other methods is not very well-defined. This is why your code worked in 2.4: a bit by chance. Indeed, in theory it should not, according to the language reference. So what I am saying is that although it is a behavior change from 2.4 to 2.5, I would argue that it is not a bug but a bug fix... The reason is that if we ignore the __eq__ vs __cmp__ issues, the operation 'a == b' is defined as: Python tries a.__eq__(b); if this returns NotImplemented, then Python tries b.__eq__(a). As an exception, if type(b) is a strict subclass of type(a), then Python tries in the other order. This is why you get the 2.5 behavior: if lowerstr inherits from str, it is not a subclass of unicode, so u'abc' == lowerstr() tries u'abc'.__eq__(), which works immediately. On the other hand, if lowerstr inherits from unicode, then Python tries first lowerstr().__eq__(u'abc'). This part of the Python object model - when to reverse the order or not - is a bit obscure and not completely helpful... Subclassing built-in types generally only works a bit. In your situation you should use a regular class that behaves in a string-like fashion, with an __eq__() method doing the case-insensitive comparison... if you can at all - there are places where you need a real string, so this "solution" might not be one either, but I don't see a better one :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470 From noreply at sourceforge.net Wed Sep 27 12:46:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 03:46:37 -0700 Subject: [ python-Bugs-1563079 ] code.InteractiveConsole() and closed sys.stdout Message-ID: Bugs item #1563079, was opened at 2006-09-21 13:53 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563079&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: code.InteractiveConsole() and closed sys.stdout Initial Comment: This code raises a ValueError: import code c = code.InteractiveConsole() c.interact() import sys sys.stdout.close() because the InteractiveConsole uses raw_input() to display its prompt. I'm not sure where the correct place to fix this is. One possible way is to allow raw_input() to take optional arguments to use instead of sys.stdin and sys.stdout. Another (easier?) way to fix this problem might be to beef up InteractiveConsole.raw_input() a bit. I'm open to either option, but I think InteractiveConsole needs to continue working even if the user closes sys.stdout. This applies to the 2.4 and 2.5 branches as well as the trunk. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-09-27 05:46 Message: Logged In: YES user_id=44345 Here's a plausible (I think) patch for code.InteractiveConsole. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563079&group_id=5470 From noreply at sourceforge.net Wed Sep 27 13:07:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 04:07:25 -0700 Subject: [ python-Feature Requests-1566260 ] Better order in file type descriptions Message-ID: Feature Requests item #1566260, was opened at 2006-09-27 11:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1566260&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: None Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Better order in file type descriptions Initial Comment: Hello, just a little idea i apply each time i install a new Python version on Windows. When files extensions are registered, ".py" extension receives the description "Python File", while ".pyc", ".pyo" are described as "Compiled Python File". This means that, when files are shown into an Explorer window and sorted by file type, the compiled files appear above the source files, while usually an user wants to work with sources. I usually change the file description to "Python file - compiled", so that i can have the sources before the .pyc's and in alphabetical order. A bonus would be to have .pyw file appear before sources, because they are supposed to be double-clicked and having them at the top could be handy. They may be described as "No Console Python File", for example. my ? 0.02 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1566260&group_id=5470 From noreply at sourceforge.net Wed Sep 27 13:49:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 04:49:50 -0700 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 14:49 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=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Sep 27 14:01:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 05:01:32 -0700 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 14:49 Message generated for change (Comment added) made by pavel_krupets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 15:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Sep 27 14:08:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 05:08:44 -0700 Subject: [ python-Bugs-1565071 ] update Lib/plat-linux2/IN.py Message-ID: Bugs item #1565071, was opened at 2006-09-25 14:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: update Lib/plat-linux2/IN.py Initial Comment: there's a request to update this module to add missing IN.SIO* definitions. How should that be done? Just re-running h2py drops all SIO* definitions, because the linux/sockios.h header isn't included anymore. requested at http://launchpad.net/bugs/58081 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 14:08 Message: Logged In: YES user_id=21627 It's convention that plat-* mirrors the structure of the header files. So ISTM that we should add sockios.py; IN.py should perhaps be regenerated only a release later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&group_id=5470 From noreply at sourceforge.net Wed Sep 27 15:19:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 06:19:50 -0700 Subject: [ python-Bugs-1566331 ] Bad behaviour in .obuf* Message-ID: Bugs item #1566331, was opened at 2006-09-27 13:19 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=1566331&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Sam Dennis (samdennis) Assigned to: Nobody/Anonymous (nobody) Summary: Bad behaviour in .obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 From noreply at sourceforge.net Wed Sep 27 22:12:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 13:12:08 -0700 Subject: [ python-Bugs-1566602 ] test_posixpath failure Message-ID: Bugs item #1566602, was opened at 2006-09-27 16: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=1566602&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 Submitted By: WallsRSolid (wallsrsolid) Assigned to: Nobody/Anonymous (nobody) Summary: test_posixpath failure Initial Comment: On a compile from the Python 2.5 Final tarball in Linux on a 64-bit, dual Opteron system, "make test" reports one failure: test test_posixpath failed -- Traceback (most recent call last): File "/archive/home/nvf/temp/Python-2.5/Lib/test/test_posixpath.py", line 353, in test_expanduser posixpath.expanduser("~/") AssertionError: '/archive/home/nvf//' != '/archive/home/nvf/' In searching the bug database, I see that failures used to happen on Tru64 and MacOS9, but there was no mention of failure on a Linux system. Versions: python -V: Python 2.5 gcc -v: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=x86_64-redhat-linux Thread model: posix gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566602&group_id=5470 From noreply at sourceforge.net Wed Sep 27 22:24:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 13:24:23 -0700 Subject: [ python-Bugs-1566611 ] Idle 2.1 - Calltips Hotkey dies not work Message-ID: Bugs item #1566611, was opened at 2006-09-27 22:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) Summary: Idle 2.1 - Calltips Hotkey dies not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 From noreply at sourceforge.net Wed Sep 27 22:25:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 13:25:24 -0700 Subject: [ python-Bugs-1566611 ] Idle 2.1 - Calltips Hotkey does not work Message-ID: Bugs item #1566611, was opened at 2006-09-27 22:24 Message generated for change (Settings changed) made by fladd710 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) >Summary: Idle 2.1 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 From noreply at sourceforge.net Wed Sep 27 22:26:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 13:26:05 -0700 Subject: [ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work Message-ID: Bugs item #1566611, was opened at 2006-09-27 22:24 Message generated for change (Settings changed) made by fladd710 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) >Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 From noreply at sourceforge.net Wed Sep 27 23:07:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 14:07:33 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 06:58 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2006-09-27 21:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 07:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 03:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 10:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Wed Sep 27 23:52:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 14:52:22 -0700 Subject: [ python-Bugs-1566663 ] Library Reference Section 5.1.8.1 is wrong. Message-ID: Bugs item #1566663, was opened at 2006-09-27 17:52 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=1566663&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Chris Connett (cconnett) Assigned to: Nobody/Anonymous (nobody) Summary: Library Reference Section 5.1.8.1 is wrong. Initial Comment: The examples section of the datetime doc is out of date. The example says that the datetime class doesn't support strptime directly, but as of Python 2.5, it does. I think the whole example is obsolete, and should probably be deleted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566663&group_id=5470 From noreply at sourceforge.net Thu Sep 28 02:34:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 17:34:24 -0700 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-27 21:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&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 Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Thu Sep 28 05:03:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 20:03:26 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 08:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 23:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 05:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 12:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Thu Sep 28 05:26:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 20:26:30 -0700 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-28 02:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&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 Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Thu Sep 28 05:29:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 20:29:07 -0700 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Thu Sep 28 05:48:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 20:48:43 -0700 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 02:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-27 23:48 Message: Logged In: YES user_id=31435 [Martin] > tim_one: Why do you think your proposed modification of > introducing get_traceback would help? The frame foo still > refers to s (which is an O), and s.e will still refer > to the traceback that includes foo. Sorry about that! It was an illusion, of course. I wanted to suggest a quick fix, and "tested it" too hastily in a program that didn't actually bloat with /or/ without it. For the OP, I had need last year of capturing a traceback and (possibly) displaying it later in ZODB. It never would have occurred to me to try saving away exc_info(), though. Instead I used the `traceback` module to capture the traceback output (a string), which was (possibly) displayed later, with annotations, by a different thread. No cycles, no problems. BTW, I must repeat that there is no simple-minded way to 'repair' this. That isn't based on general principle, but on knowledge of how Python is implemented. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 23:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 17:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 03:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-26 23:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 06:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Thu Sep 28 07:47:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 22:47:23 -0700 Subject: [ python-Bugs-1566800 ] urllib doesn't raise IOError correctly with new IOError Message-ID: Bugs item #1566800, was opened at 2006-09-28 07:47 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=1566800&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 Submitted By: Arthibus Gissehel (gissehel) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't raise IOError correctly with new IOError Initial Comment: The version I used is : >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' On Windows XP SP2. While I think every python 2.5 releases are concerned. On line 357 of urllib.py from 2.5 release, there is a raise of an IOError with 4 arguments. It look like it was fine with python 2.4 but it hang up with a "TypeError: EnvironmentError expected at most 3 arguments, got 4" Concretly, when you hit a page with a "redirect" using error 302 for exemple, instead of raising an IOError, it raise a TypeError, so it break code which expect an IOError here (as a "normal" behavior for 302 codes) It look like IOError is totally different between Python 2.4 and Python 2.5 (it was a class, it's now a type) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566800&group_id=5470 From noreply at sourceforge.net Thu Sep 28 20:48:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 11:48:16 -0700 Subject: [ python-Bugs-1567234 ] unchecked metaclass mro Message-ID: Bugs item #1567234, was opened at 2006-09-28 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: unchecked metaclass mro Initial Comment: this bug was fixed in python2.5, but it's worth adding to 2.4.4. metaclasses can return an "insane" mro, which confuses the PyXXX_Check checks, and causes memory corruption. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): ... class __metaclass__(type): ... def mro(self): ... return (str, int, list) ... >>> c = crasher("hello") >>> c # a very strange object '' >>> dir(c) [] >>> c.append(5) # ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 From noreply at sourceforge.net Thu Sep 28 20:49:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 11:49:22 -0700 Subject: [ python-Bugs-1567234 ] unchecked metaclass mro Message-ID: Bugs item #1567234, was opened at 2006-09-28 21:48 Message generated for change (Settings changed) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) >Assigned to: A.M. Kuchling (akuchling) Summary: unchecked metaclass mro Initial Comment: this bug was fixed in python2.5, but it's worth adding to 2.4.4. metaclasses can return an "insane" mro, which confuses the PyXXX_Check checks, and causes memory corruption. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): ... class __metaclass__(type): ... def mro(self): ... return (str, int, list) ... >>> c = crasher("hello") >>> c # a very strange object '' >>> dir(c) [] >>> c.append(5) # ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 From noreply at sourceforge.net Thu Sep 28 23:36:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 14:36:40 -0700 Subject: [ python-Bugs-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount Message-ID: Bugs item #1567331, was opened at 2006-09-28 16:36 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=1567331&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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567331&group_id=5470 From noreply at sourceforge.net Fri Sep 29 01:15:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 16:15:05 -0700 Subject: [ python-Bugs-1567375 ] False sentence about formatted print in tutorial section 7.1 Message-ID: Bugs item #1567375, was opened at 2006-09-28 19:15 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=1567375&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 Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: False sentence about formatted print in tutorial section 7.1 Initial Comment: The line: (Note that one space between each column was added by the way print works: it always adds spaces between its arguments.) in section 7.1 of the tutorial (http://docs.python.org/dev/tut/node9.html), is false. It refers to the command print '%2d %3d %4d' % (x, x*x, x*x*x) which produces (if x == 10) 10 100 1000 The two spaces in that output are NOT "added by the way print works". Instead, they come from the format string itself. If you use print '%2d%3d%4d' % (x, x*x, x*x*x) you get 101001000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567375&group_id=5470 From noreply at sourceforge.net Fri Sep 29 05:34:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 20:34:06 -0700 Subject: [ python-Bugs-1567450 ] tabs missing in idle options configure Message-ID: Bugs item #1567450, was opened at 2006-09-28 23:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jrgutierrez (jrgutierrez) Assigned to: Nobody/Anonymous (nobody) Summary: tabs missing in idle options configure Initial Comment: 1)The option to select indentation type (insert spaces or tabs) is missing 2) The indented width is ignored As a result IDLE 2.5 always indents inserting tabs, width 8 Sources edited in IDLE 2.4 cannot be corrected with IDLE 2.5: The tabbing errors cannot be corrected with IDLE 2.5. You must revert to IDLE 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567450&group_id=5470 From noreply at sourceforge.net Fri Sep 29 14:12:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 05:12:13 -0700 Subject: [ python-Bugs-1567666 ] GetFileAttributesExA and Win95 Message-ID: Bugs item #1567666, was opened at 2006-09-29 12: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=1567666&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: giomach (giomach) Assigned to: Nobody/Anonymous (nobody) Summary: GetFileAttributesExA and Win95 Initial Comment: When Python 2.5 is run under Win95 (Windows 4.00.950B), it immediately fails with "The PYTHON25.DLL file is linked to missing export KERNEL32.DLL.GetFileAttributesExA". Python 2.4.3 is fine. Ciar?n ? Duibh?n. My e-mail: ciaran at oduibhin.freeserve.co.uk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567666&group_id=5470 From noreply at sourceforge.net Fri Sep 29 14:32:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 05:32:28 -0700 Subject: [ python-Bugs-1567234 ] unchecked metaclass mro Message-ID: Bugs item #1567234, was opened at 2006-09-28 14:48 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: A.M. Kuchling (akuchling) Summary: unchecked metaclass mro Initial Comment: this bug was fixed in python2.5, but it's worth adding to 2.4.4. metaclasses can return an "insane" mro, which confuses the PyXXX_Check checks, and causes memory corruption. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): ... class __metaclass__(type): ... def mro(self): ... return (str, int, list) ... >>> c = crasher("hello") >>> c # a very strange object '' >>> dir(c) [] >>> c.append(5) # ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-29 08:32 Message: Logged In: YES user_id=11375 Can you please provide a reference to the original bug, or to the revision that fixes the bug in 2.5? + ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 From noreply at sourceforge.net Fri Sep 29 15:12:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 06:12:01 -0700 Subject: [ python-Bugs-1567234 ] unchecked metaclass mro Message-ID: Bugs item #1567234, was opened at 2006-09-28 21:48 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: A.M. Kuchling (akuchling) Summary: unchecked metaclass mro Initial Comment: this bug was fixed in python2.5, but it's worth adding to 2.4.4. metaclasses can return an "insane" mro, which confuses the PyXXX_Check checks, and causes memory corruption. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): ... class __metaclass__(type): ... def mro(self): ... return (str, int, list) ... >>> c = crasher("hello") >>> c # a very strange object '' >>> dir(c) [] >>> c.append(5) # ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-09-29 16:12 Message: Logged In: YES user_id=1406776 i never managed working with svn's or cvs's... i can point you to the official source distribution of 2.4.2: file: typeobject.c function: static int mro_internal(PyTypeObject *type) +-+-+-+-+-+-+-+- mro = lookup_method((PyObject *)type, "mro", &mro_str); if (mro == NULL) return -1; result = PyObject_CallObject(mro, NULL); Py_DECREF(mro); } if (result == NULL) return -1; tuple = PySequence_Tuple(result); +-+-+-+-+-+-+-+-+- python 2.5 (release) added the following check: +-+-+-+-+-+-+-+-+- if (!PyType_IsSubtype(solid, solid_base(t))) { PyErr_Format(PyExc_TypeError, "mro() returned base with unsuitable layout ('%.500s')", t->tp_name); +-+-+-+-+-+-+-+-+- that's the best i can do, sorry ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-29 15:32 Message: Logged In: YES user_id=11375 Can you please provide a reference to the original bug, or to the revision that fixes the bug in 2.5? + ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 From noreply at sourceforge.net Fri Sep 29 15:52:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 06:52:20 -0700 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 14:49 Message generated for change (Comment added) made by pavel_krupets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 16:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 06:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 15:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Fri Sep 29 19:47:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 10:47:57 -0700 Subject: [ python-Bugs-1567910 ] missing _typesmodule.c, Visual Studio 2005 pythoncore.vcproj Message-ID: Bugs item #1567910, was opened at 2006-09-29 10:47 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=1567910&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 Submitted By: everbruin (everbruin) Assigned to: Nobody/Anonymous (nobody) Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj Initial Comment: Python 2.5's Visual Studio 2005 pythoncore.vcproj (in PCBuild8 folder) is missing Modules/_typesmodule.c (note the VS 2003 pythoncore.vcproj in PCBuild correctly has it). The bug is that binaries built w/o the file will give a SystemError when "import _types" is done (eg by types.py). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470 From noreply at sourceforge.net Fri Sep 29 20:51:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 11:51:44 -0700 Subject: [ python-Feature Requests-1567948 ] poplib.py list interface Message-ID: Feature Requests item #1567948, was opened at 2006-09-29 11:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.py list interface Initial Comment: Adds a list-like interface to poplib.py, poplib_as_list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470 From noreply at sourceforge.net Fri Sep 29 21:27:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 12:27:23 -0700 Subject: [ python-Bugs-1567976 ] http://docs.python.org/tut/node10.html typo Message-ID: Bugs item #1567976, was opened at 2006-09-29 19: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=1567976&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 Submitted By: Simon Morgan (simonmorgan) Assigned to: Nobody/Anonymous (nobody) Summary: http://docs.python.org/tut/node10.html typo Initial Comment: "One my also instantiate an exception first" should be "One may also instantiate an exception first". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567976&group_id=5470 From noreply at sourceforge.net Sat Sep 30 01:00:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 16:00:04 -0700 Subject: [ python-Bugs-1568075 ] GUI scripts always return to an interpreter Message-ID: Bugs item #1568075, was opened at 2006-09-29 16:00 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=1568075&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470 From noreply at sourceforge.net Sat Sep 30 02:12:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 17:12:58 -0700 Subject: [ python-Bugs-1568120 ] Encoding bug Message-ID: Bugs item #1568120, was opened at 2006-09-30 03: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=1568120&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?mer FADIL USTA (usta) Assigned to: M.-A. Lemburg (lemburg) Summary: Encoding bug Initial Comment: The problem easily shown in photo which have been attached with this bug and also at http://img147.imageshack.us/img147/3717/pythonte4.jpg thx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568120&group_id=5470 From noreply at sourceforge.net Sat Sep 30 07:26:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 22:26:33 -0700 Subject: [ python-Bugs-1567976 ] http://docs.python.org/tut/node10.html typo Message-ID: Bugs item #1567976, was opened at 2006-09-30 04:27 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567976&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: None Priority: 5 Submitted By: Simon Morgan (simonmorgan) >Assigned to: George Yoshida (quiver) Summary: http://docs.python.org/tut/node10.html typo Initial Comment: "One my also instantiate an exception first" should be "One may also instantiate an exception first". ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-09-30 14:26 Message: Logged In: YES user_id=671362 Fixed in r52048(svn-trunk) and r52049(2.5). Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567976&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:18:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:18:53 -0700 Subject: [ python-Bugs-1568120 ] Encoding bug Message-ID: Bugs item #1568120, was opened at 2006-09-30 00:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568120&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: ?mer FADIL USTA (usta) Assigned to: M.-A. Lemburg (lemburg) Summary: Encoding bug Initial Comment: The problem easily shown in photo which have been attached with this bug and also at http://img147.imageshack.us/img147/3717/pythonte4.jpg thx ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:18 Message: Logged In: YES user_id=849994 This is the same issue as #1193061. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568120&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:19:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:19:00 -0700 Subject: [ python-Bugs-1193061 ] Python and Turkish Locale Message-ID: Bugs item #1193061, was opened at 2005-04-30 17:37 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&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: 6 Submitted By: S.?ağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. ---------------------------------------------------------------------- Comment By: Eray Ozkural (exa) Date: 2005-10-11 21:36 Message: Logged In: YES user_id=1454 The better solution is to use an optional locale argument for upper/lower functions and other language-dependent text processing functions. ---------------------------------------------------------------------- Comment By: S.?ağlar Onur (caglar) Date: 2005-05-02 08:45 Message: Logged In: YES user_id=858447 No, im not. These rules defined in http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt. Note that there is a comments says; # T: special case for uppercase I and dotted uppercase I # - For non-Turkic languages, this mapping is normally not used. # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. # See the discussions of case mapping in the Unicode Standard for more information. So without wctype functions support, python can't convert these. This _is_ the problem. As a side effect of this, another huge problem occurs, keywords can't be locale dependent. If Python compiled with wctype support functions, all "i".upper() turns into "İ" which is wrong for keyword comparision ( like quit v.s QUİT ) So i suggest implement two new functions like localeAwareLower()/localeAwareUpper() for python and let lower()/upper() locale independent. And as you wrote locale module may be a perfect home for these :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 08:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:25:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:25:21 -0700 Subject: [ python-Bugs-1567375 ] False sentence about formatted print in tutorial section 7.1 Message-ID: Bugs item #1567375, was opened at 2006-09-28 23:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567375&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: Fixed Priority: 5 Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: False sentence about formatted print in tutorial section 7.1 Initial Comment: The line: (Note that one space between each column was added by the way print works: it always adds spaces between its arguments.) in section 7.1 of the tutorial (http://docs.python.org/dev/tut/node9.html), is false. It refers to the command print '%2d %3d %4d' % (x, x*x, x*x*x) which produces (if x == 10) 10 100 1000 The two spaces in that output are NOT "added by the way print works". Instead, they come from the format string itself. If you use print '%2d%3d%4d' % (x, x*x, x*x*x) you get 101001000 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:25 Message: Logged In: YES user_id=849994 The sentence refers to the example above the one you quoted, which uses the print statement. I made that clear in rev 52053, 52054 (2.4), 52055 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567375&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:32:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:32:15 -0700 Subject: [ python-Bugs-1565661 ] webbrowser on gnome runs wrong browser Message-ID: Bugs item #1565661, was opened at 2006-09-26 11:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&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: Closed >Resolution: Fixed Priority: 5 Submitted By: kangabroo (kangabroo) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser on gnome runs wrong browser Initial Comment: Epiphany is set as system default, but Firefox runs when webbrowser.open is called. in webbrowser.py - register_X_browsers(): 'gconftool-2 -g /desktop/gnome/url-handlers/http/command 2>/dev/null' returns 'epiphany %s' A BackgroundBrowser with a name of 'epiphany %s' is created. later on open(), subprocess.Popen(['epiphany %s', url], ....) is called. This throws an exception: OSError: [Errno 2] No such file or directory which is caught, and False is returned Solution: in webbrowser.py function register_X_browsers(), change: register("gnome", None, BackgroundBrowser(commd)) to register("gnome", None, BackgroundBrowser(commd.split())) System: Python 2.5, Linux 2.6.17, Gnome 2.14.2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:32 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52056, 52057 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:40:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:40:04 -0700 Subject: [ python-Bugs-1565087 ] Misbehaviour in zipfile Message-ID: Bugs item #1565087, was opened at 2006-09-25 13:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565087&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Philips (rphilips) Assigned to: Nobody/Anonymous (nobody) Summary: Misbehaviour in zipfile Initial Comment: Python 2.5 In library module zipfile, a ZipFile object has method write( filename[, arcname[, compress_type]]) If arcname is not specified, it defaults to the pathname of filename without a drive letter and with leading path separators removed. That is OK. But if arcname is explicitely specified, the drive letter and leading path separators are also removed. I think that is not OK. thanks, Richard Philips ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:40 Message: Logged In: YES user_id=849994 It is, since the Zip specification doesn't allow paths with drive letters or absolute paths for files inside the zip. See bug #1413790. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565087&group_id=5470 From noreply at sourceforge.net Sat Sep 30 09:47:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 00:47:14 -0700 Subject: [ python-Bugs-1568075 ] GUI scripts always return to an interpreter Message-ID: Bugs item #1568075, was opened at 2006-09-29 23:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: Macintosh Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:47 Message: Logged In: YES user_id=849994 Did you (or someone else) perhaps set the PYTHONINSPECT environment variable? I can't imagine another cause for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470 From noreply at sourceforge.net Sat Sep 30 11:04:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 02:04:09 -0700 Subject: [ python-Bugs-1566800 ] urllib doesn't raise IOError correctly with new IOError Message-ID: Bugs item #1566800, was opened at 2006-09-28 05:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566800&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Arthibus Gissehel (gissehel) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't raise IOError correctly with new IOError Initial Comment: The version I used is : >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' On Windows XP SP2. While I think every python 2.5 releases are concerned. On line 357 of urllib.py from 2.5 release, there is a raise of an IOError with 4 arguments. It look like it was fine with python 2.4 but it hang up with a "TypeError: EnvironmentError expected at most 3 arguments, got 4" Concretly, when you hit a page with a "redirect" using error 302 for exemple, instead of raising an IOError, it raise a TypeError, so it break code which expect an IOError here (as a "normal" behavior for 302 codes) It look like IOError is totally different between Python 2.4 and Python 2.5 (it was a class, it's now a type) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 09:04 Message: Logged In: YES user_id=849994 Thanks for the report, IOError can now again take any number of arguments. rev. 52061, 52062 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566800&group_id=5470 From noreply at sourceforge.net Sat Sep 30 11:07:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 02:07:01 -0700 Subject: [ python-Bugs-1566663 ] Library Reference Section 5.1.8.1 is wrong. Message-ID: Bugs item #1566663, was opened at 2006-09-27 21:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566663&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Connett (cconnett) Assigned to: Nobody/Anonymous (nobody) Summary: Library Reference Section 5.1.8.1 is wrong. Initial Comment: The examples section of the datetime doc is out of date. The example says that the datetime class doesn't support strptime directly, but as of Python 2.5, it does. I think the whole example is obsolete, and should probably be deleted. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 09:07 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52063, 52064 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566663&group_id=5470 From noreply at sourceforge.net Sat Sep 30 11:13:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 02:13:47 -0700 Subject: [ python-Bugs-1566602 ] test_posixpath failure Message-ID: Bugs item #1566602, was opened at 2006-09-27 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=1566602&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: Closed >Resolution: Fixed Priority: 5 Submitted By: WallsRSolid (wallsrsolid) Assigned to: Nobody/Anonymous (nobody) Summary: test_posixpath failure Initial Comment: On a compile from the Python 2.5 Final tarball in Linux on a 64-bit, dual Opteron system, "make test" reports one failure: test test_posixpath failed -- Traceback (most recent call last): File "/archive/home/nvf/temp/Python-2.5/Lib/test/test_posixpath.py", line 353, in test_expanduser posixpath.expanduser("~/") AssertionError: '/archive/home/nvf//' != '/archive/home/nvf/' In searching the bug database, I see that failures used to happen on Tru64 and MacOS9, but there was no mention of failure on a Linux system. Versions: python -V: Python 2.5 gcc -v: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=x86_64-redhat-linux Thread model: posix gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 09:13 Message: Logged In: YES user_id=849994 Thanks for the report, that is now fixed in rev. 52065, 52066 (2.4), 52067 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566602&group_id=5470 From noreply at sourceforge.net Sat Sep 30 11:19:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 02:19:26 -0700 Subject: [ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows Message-ID: Bugs item #1568240, was opened at 2006-09-30 12:19 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=1568240&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 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 From noreply at sourceforge.net Sat Sep 30 11:34:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 02:34:24 -0700 Subject: [ python-Bugs-1568243 ] init_types Message-ID: Bugs item #1568243, was opened at 2006-09-30 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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 Submitted By: Bosko Vukov (bvukov) Assigned to: Nobody/Anonymous (nobody) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) .... but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 From noreply at sourceforge.net Sat Sep 30 12:27:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 03:27:11 -0700 Subject: [ python-Bugs-1412580 ] locale.format gives wrong exception on some erroneous input Message-ID: Bugs item #1412580, was opened at 2006-01-23 07:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Tim Diggins (tdiggins) Assigned to: Nobody/Anonymous (nobody) Summary: locale.format gives wrong exception on some erroneous input Initial Comment: using '2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]' on WinXpPro SP2 locale.format(formatString, val, grouping) when passed a formatString of the wrong type, ought to raise a TypeError (as some erroneous input does) Example: locale.format(2.3, 2.3) passes through AttributeError ("float has no attribute 'split'"). I thought perhaps the body of the method should be wrapped in a try:except block, and if any error is caught, then the arguments should be rigorously tested for type and lucid exceptions raised. See attachment for suggestion (with tests). I'm not clear whether if the format string is erroneous (bad syntax, or has too many/no %-s, the raised error should be ValueError (contractually correct) or conceivably whatever StringInterpolation raises (parallelism). I've put tests for both in - currently ValueError wins. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 10:27 Message: Logged In: YES user_id=849994 format() has been overhauled in 2.5. This doesn't apply anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412580&group_id=5470 From noreply at sourceforge.net Sat Sep 30 12:49:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 03:49:53 -0700 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-28 00:34 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&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: Pending Resolution: None Priority: 5 Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 03:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Sat Sep 30 12:58:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 03:58:17 -0700 Subject: [ python-Bugs-1457823 ] cgi.FormContentDict constructor should support parse options Message-ID: Bugs item #1457823, was opened at 2006-03-24 16:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&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: Closed >Resolution: Accepted Priority: 5 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FormContentDict constructor should support parse options Initial Comment: cgi.FormContentDict (and cgi.SvFormContentDict) should take optional keep_blank_values and strict_parsing args and pass them on to cgi.parse(). In my use case neither of the parse defaults is what I want, so I'm faced with having to hack or re-implement SvFormContentDict. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 10:58 Message: Logged In: YES user_id=849994 Added in rev. 52068 for Python 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457823&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:00:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:00:27 -0700 Subject: [ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)): Message-ID: Bugs item #1459159, was opened at 2006-03-27 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:00 Message: Logged In: YES user_id=849994 Yes, it seems so. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-02 02:02 Message: Logged In: YES user_id=1326842 Can this bug be closed? It seems that the only problem was test_inspect relying on the old behavior. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 11:39 Message: Logged In: YES user_id=849994 This at least explains why test_inspect didn't fail for 2.5 after you had fixed the bug and modified the test. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 11:38 Message: Logged In: YES user_id=849994 That's a bit odd. Following defs: def bar((x)): pass def foo(x): pass In 2.4: >>> dis.dis(bar) 1 0 LOAD_FAST 0 (.0) 3 STORE_FAST 1 (x) 6 LOAD_CONST 0 (None) 9 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE In 2.5: >>> dis.dis(bar) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:01:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:01:58 -0700 Subject: [ python-Bugs-1156179 ] Calls from VBScript clobber passed args Message-ID: Bugs item #1156179, was opened at 2005-03-03 20:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Erik Rose (grincheroo) Assigned to: Nobody/Anonymous (nobody) Summary: Calls from VBScript clobber passed args Initial Comment: I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a Python function from VBScript AND pass a local var as the first parameter AND don't use the return value, then the local var I passed in is, upon the function's return, set to Null. If I store the return value (even if there isn't one) OR pass the return value to another function, this doesn't happen. I'm attaching some snippets that demonstrate and work around the bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:01 Message: Logged In: YES user_id=849994 Agreed. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-09-01 21:08 Message: Logged In: YES user_id=771074 I think this is actually a vbscript behaviour. If not, it's a bug in Pywin32's Active Scripting implementation. Either way, this shoud probably be closed as third-party. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 15:41 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 15:39 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- Comment By: Erik Rose (grincheroo) Date: 2005-03-08 15:39 Message: Logged In: YES user_id=888812 Let me refine the description a bit: the bug doesn't clobber only a local var passed as the *first* param; it clobbers the first local var passed, whether it's the first param or not. For example, call go(x) clobbers x, as I've said before, but... call aTwoParamFunction("somethingStatic", x, y) clobbers x as well! y is not clobbered. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156179&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:18:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:18:03 -0700 Subject: [ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars Message-ID: Bugs item #1556784, was opened at 2006-09-12 02:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: [I'm putting this in category Python Library, because I assume Extensions Modules is for problems in the Extensions Module plumbing.] datetime.date and datetime.time's strftime() methods call wrap_strftime(), which limits the length of the format string to 127 chars before calling time.strftime(). This can be seen in the examples below. Note that in the third example, time.strftime() does not have a problem with a 128 character format string. >>> import datetime >>> datetime.date.today().strftime('x'*128) Traceback (most recent call last): File "", line 1, in MemoryError >>> import datetime >>> datetime.date.today().strftime('x'*256) Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:18 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52072, 52073 (2.4), 52074 (2.5). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2006-09-12 22:12 Message: Logged In: YES user_id=411198 See patch http://python.org/sf/1557390 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:22:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:22:45 -0700 Subject: [ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError Message-ID: Bugs item #1446043, was opened at 2006-03-09 00:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: osvenskan (osvenskan) Assigned to: Neal Norwitz (nnorwitz) Summary: unicode('foo', '.utf99') does not raise LookupError Initial Comment: A very minor inconsistency -- when I call unicode() with an encoding that Python doesn't know about, it usually returns a lookup error (e.g LookupError: unknown encoding: utf99). But when the encoding begins with a dot (ASCII 0x2e), Python instead gives a ValueError: Empty module name. It is certainly correct in raising an error, but it should raise a lookup error, not a value error. I've recreated this under Python 2.4.1/FreeBSD 6.0 and 2.3/OS X. See attachment for recreation steps. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:22 Message: Logged In: YES user_id=849994 Fixed in rev. 52075, 52076 (2.4), 52077 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 19:17 Message: Logged In: YES user_id=849994 I'd say that this should be fixed before 2.5 final. Attached patch (the modname that's used for import may not contain a dot anymore...) ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-04-06 14:45 Message: Logged In: YES user_id=1119995 I noticed that the documentation for unicode() says, "if the encoding is not known, LookupError is raised". Regarding the 3rd parameter ("errors") to unicode(), the docs say, "Error handling is done according to errors; this specifies the treatment of characters which are invalid in the input encoding. If errors is 'strict' (the default), a ValueError is raised on errors..." ref: http://docs.python.org/lib/built-in-funcs.html That makes the code's current behavior doubly confusing because a the documentation says that a ValueError is reserved for indicating an undecodable byte sequence, not an unknown encoding name. ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-03-09 15:04 Message: Logged In: YES user_id=1119995 There are encoding names that contain dots, such as ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as reported by iconv). There are none in iconv's list that begin with a dot. Please note that the behavior of this function has been discussed before in Python bugs 513666 and 960874. Apologies for not referencing them in my original report. Having stepped through the code, I understand how the ValueError is getting generated. My frustration with this as a programmer is that I want to write specific except clauses for each possible exception that a method can raise, but that's impractical if any exception is fair game on any method. So I'm forced to use a catch-all except clause about which the Python documentation says (wisely, IMHO), "Use this with extreme caution, since it is easy to mask a real programming error in this way!" While it is helpful to document errors that a method is *likely* to raise, my code needs to handle all possibilities, not just likely ones. Perhaps the answer is just, "This is how Python works" and if I feel it is a weakness in the language I need to take it up on a different level. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 08:16 Message: Logged In: YES user_id=849994 Is it possible for an encoding name to contain dots at all? If not, this would do too: if '.' in modname: continue ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-09 08:12 Message: Logged In: YES user_id=89016 The problem is that after normalizing the encoding name a module with this name is imported. Maybe encodings/__init__.py:search_function should do: if ".".join(filter(None, modname.split("."))) != modname: return None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:27:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:27:19 -0700 Subject: [ python-Bugs-1568243 ] init_types Message-ID: Bugs item #1568243, was opened at 2006-09-30 09:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) >Assigned to: Martin v. L?wis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) .... but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:27 Message: Logged In: YES user_id=849994 The problem is another one: The config.c init_types function belongs to the _types module, while the Python-ast.c init_types is an internal function. They shouldn't clash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:28:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:28:05 -0700 Subject: [ python-Bugs-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount Message-ID: Bugs item #1567331, was opened at 2006-09-28 21:36 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567331&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 Submitted By: Skip Montanaro (montanaro) >Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567331&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:33:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:33:29 -0700 Subject: [ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers Message-ID: Bugs item #1483963, was opened at 2006-05-08 17:05 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Christian Hudon (chrish42) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack problem with @, =, < specifiers Initial Comment: When using struct to unpack floats, I'm getting inconsistent results when using the '>> sys.byteorder 'little' # This is correct... >>> struct.unpack('@d', s) (nan,) # These should be equivalent for unpacking a single # double on little-endian arch... but they're not. >>> struct.unpack('>> struct.unpack('=d', s) (inf,) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-05-10 14:30 Message: Logged In: YES user_id=6656 I'm glad my fix worked. I'm not personally inclined to port the fixes to the 2.4 branch, as they are indeed fairly involved. ---------------------------------------------------------------------- Comment By: Christian Hudon (chrish42) Date: 2006-05-10 14:24 Message: Logged In: YES user_id=980271 I had tried with 2.3.5 and 2.4.1 and the bug was present in both versions. I just tried with svn HEAD, and the bug is fixed there (at least in the revision that I tried). It'd be nice if this bug fix could be included in the next 2.4 point release, assuming the fix is not too complicated. Is there a process for nominating bugfixes for the main-2.4 branch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-05-10 12:17 Message: Logged In: YES user_id=6656 Can you try Python from svn HEAD? Or did you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:34:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:34:04 -0700 Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources Message-ID: Bugs item #1484556, was opened at 2006-05-09 10:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Neal Norwitz (nnorwitz) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:34 Message: Logged In: YES user_id=849994 Have all KlocWork issues been fixed now, Neal? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-06-04 09:53 Message: Logged In: YES user_id=358087 I'll try to see if I can sneak it in, can't promise anything though ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 14:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-05-10 04:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:46:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:46:20 -0700 Subject: [ python-Feature Requests-1518621 ] optparse.parse_args() ret value seems to be a dict but isn't Message-ID: Feature Requests item #1518621, was opened at 2006-07-07 09:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1518621&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: Closed Resolution: Rejected Priority: 5 Submitted By: rhunger (rhunger) Assigned to: Greg Ward (gward) Summary: optparse.parse_args() ret value seems to be a dict but isn't Initial Comment: ... from optparse import OptionParser parser = OptionParser() ... (options, args) = parser.parse_args() print options ... options seems to be a dict but isn't. So it's not possible to use e.g. print "Option 1: %(firstOption)s" % options Here it's easy to use "options.firstOption" but with a larger number of program options it would be nice to be able to use "options" as a dict directly. (patch attached) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:46 Message: Logged In: YES user_id=849994 In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-07-26 02:38 Message: Logged In: YES user_id=14422 Don't believe __str__(): believe the docs. In particular, section 6.21.3.7 of the Python Library Reference is pretty clear that options is not a dict. See http://www.python.org/doc/2.4.3/lib/optparse-parsing-arguments.html If you want a dict, no need to modify optparse: just use vars(options). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 04:06 Message: Logged In: YES user_id=33168 Greg, are you using the Python tracker or only optik tracker? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1518621&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:59:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:59:03 -0700 Subject: [ python-Bugs-1545836 ] Incomplete info in 7.18.1 ZipFile Objects Message-ID: Bugs item #1545836, was opened at 2006-08-24 09:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545836&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: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Taco (tacotortilla) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete info in 7.18.1 ZipFile Objects Initial Comment: Documentation: Python Library Reference 2.4.3 7.18.1 ZipFile Objects The description for class ZipFile(file[, mode[, compression]]) states the possible values for the parameter "compression", but does not give any details on what they do. A nice table like this one would be prudent: ZIP_STORED Files stored with no compression ZIP_DEFLATED Files stored with zlib "deflate" compression Cheers ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:59 Message: Logged In: YES user_id=849994 ZIP_STORED and ZIP_DEFLATED are explained on the zipfile overview page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545836&group_id=5470 From noreply at sourceforge.net Sat Sep 30 14:04:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 05:04:05 -0700 Subject: [ python-Bugs-1546052 ] PyString_FromString() clarification Message-ID: Bugs item #1546052, was opened at 2006-08-24 15:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546052&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: Fixed Priority: 5 Submitted By: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString() clarification Initial Comment: The documentation for PyObject* PyString_FromString( const char *v) in the "Python/C API Reference Manual, 29 March 2006, Release 2.4.3", section 7.3.1 "String Objects" , does not mention whether this function makes a copy of the passed C string or just keeps the pointer. Google provides some posts on various mailing lists and forums that seem to indicate that it indeed does copy the string (which is the right thing to do, of course). Could something like to following be added to the documentation? "This function makes a copy of the string pointed to by v, so you may modify or deallocate it afterwards without affecting the Python object created by this function." ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 12:04 Message: Logged In: YES user_id=849994 Thanks for the suggestion! Added clarification in rev. 52078, 52079 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546052&group_id=5470 From noreply at sourceforge.net Sat Sep 30 14:10:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 05:10:19 -0700 Subject: [ python-Bugs-1559142 ] some section links (previous, up, next) missing last word Message-ID: Bugs item #1559142, was opened at 2006-09-15 08:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&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 Submitted By: Tim Smith (thimsmith) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some section links (previous, up, next) missing last word Initial Comment: The Previous, Up and Next links in the Library Reference are often missing the last word. Examples: http://www.python.org/doc/current/lib/module-operator.html """Previous: 3.9 UserString Up: 3. Python Runtime Services Next: 3.10.1 Mapping Operators to """ (Next link missing last word "Functions".) http://www.python.org/doc/current/lib/weakref-example.html """Previous: 3.3.1 Weak Reference Objects Up: 3.3 weakref Next: 3.3.3 Weak References in """ (Next link missing last two words "Extension Types".) There are *many* examples of this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 12:10 Message: Logged In: YES user_id=849994 This seems to be a "feature" of LaTeX2html. It limits the links to three words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 From noreply at sourceforge.net Sat Sep 30 17:58:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 08:58:02 -0700 Subject: [ python-Bugs-1193061 ] Python and Turkish Locale Message-ID: Bugs item #1193061, was opened at 2005-04-30 20:37 Message generated for change (Comment added) made by usta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&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: 6 Submitted By: S.?ağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. ---------------------------------------------------------------------- Comment By: ?mer FADIL USTA (usta) Date: 2006-09-30 18:58 Message: Logged In: YES user_id=278064 http://img147.imageshack.us/img147/3717/pythonte4.jpg I think this photo summarize the bug which is related to upper() in Turkish encoding. ---------------------------------------------------------------------- Comment By: Eray Ozkural (exa) Date: 2005-10-12 00:36 Message: Logged In: YES user_id=1454 The better solution is to use an optional locale argument for upper/lower functions and other language-dependent text processing functions. ---------------------------------------------------------------------- Comment By: S.?ağlar Onur (caglar) Date: 2005-05-02 11:45 Message: Logged In: YES user_id=858447 No, im not. These rules defined in http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt. Note that there is a comments says; # T: special case for uppercase I and dotted uppercase I # - For non-Turkic languages, this mapping is normally not used. # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. # See the discussions of case mapping in the Unicode Standard for more information. So without wctype functions support, python can't convert these. This _is_ the problem. As a side effect of this, another huge problem occurs, keywords can't be locale dependent. If Python compiled with wctype support functions, all "i".upper() turns into "İ" which is wrong for keyword comparision ( like quit v.s QUİT ) So i suggest implement two new functions like localeAwareLower()/localeAwareUpper() for python and let lower()/upper() locale independent. And as you wrote locale module may be a perfect home for these :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 11:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 From noreply at sourceforge.net Sat Sep 30 19:50:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 10:50:22 -0700 Subject: [ python-Bugs-1568243 ] init_types Message-ID: Bugs item #1568243, was opened at 2006-09-30 11:34 Message generated for change (Comment added) made by bvukov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) Assigned to: Martin v. L?wis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) .... but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko ---------------------------------------------------------------------- >Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 19:50 Message: Logged In: YES user_id=1292849 I opened solution file from folder PCbuild8, and inside project file pythoncore.vcproj there is no reference to _typesmodule.c. It exists in pythoncore.vcproj in the PBbuild folder ( for older version's ). I added the missing _typesmodule.c inside, and returned back the changes I made, and aft er that linker reported 'Python-ast.obj : error LNK2005: _init_types already defined in _typesmodule.obj' ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 13:27 Message: Logged In: YES user_id=849994 The problem is another one: The config.c init_types function belongs to the _types module, while the Python-ast.c init_types is an internal function. They shouldn't clash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 From noreply at sourceforge.net Sat Sep 30 19:55:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 10:55:57 -0700 Subject: [ python-Bugs-1568075 ] GUI scripts always return to an interpreter Message-ID: Bugs item #1568075, was opened at 2006-09-29 16:00 Message generated for change (Comment added) made by jejackson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: Macintosh Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. ---------------------------------------------------------------------- >Comment By: jjackson (jejackson) Date: 2006-09-30 10:55 Message: Logged In: YES user_id=1497873 No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by something else. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 00:47 Message: Logged In: YES user_id=849994 Did you (or someone else) perhaps set the PYTHONINSPECT environment variable? I can't imagine another cause for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470 From noreply at sourceforge.net Sat Sep 30 20:24:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 11:24:12 -0700 Subject: [ python-Bugs-1568075 ] GUI scripts always return to an interpreter Message-ID: Bugs item #1568075, was opened at 2006-09-29 23:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 18:24 Message: Logged In: YES user_id=849994 Could you check if it is set? (using echo $PYTHONINSPECT in a console?) ---------------------------------------------------------------------- Comment By: jjackson (jejackson) Date: 2006-09-30 17:55 Message: Logged In: YES user_id=1497873 No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by something else. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 07:47 Message: Logged In: YES user_id=849994 Did you (or someone else) perhaps set the PYTHONINSPECT environment variable? I can't imagine another cause for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470 From noreply at sourceforge.net Sat Sep 30 20:49:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 11:49:19 -0700 Subject: [ python-Bugs-1568429 ] broken info files generation Message-ID: Bugs item #1568429, was opened at 2006-09-30 20:49 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=1568429&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: broken info files generation Initial Comment: Hi, Currently make -C Doc/info will not work. There are bugs in *.tex files which prevent py2texinfo from working. Also even after fixing these there are some weird constructs which later make makeinfo go mad. Take a look at http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python- info.patch which has some fixes for that. This one is important: - level=1\optional{, parent\optional\{, directory\optional{, - attributes=0}}}} + level=1\optional{, parent\optional{, directory\optional{, + attributes=0}}}}} - unmatched {} + one wrongly quoted { The other thing is using quote enviroment which is unknown to py2texinfo - change it to quotation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&group_id=5470 From noreply at sourceforge.net Sat Sep 30 23:48:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 14:48:24 -0700 Subject: [ python-Bugs-1568075 ] GUI scripts always return to an interpreter Message-ID: Bugs item #1568075, was opened at 2006-09-29 16:00 Message generated for change (Comment added) made by jejackson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: GUI scripts always return to an interpreter Initial Comment: I installed the latest version of 2.5 from the web last night: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin When I run a wxPython script, using something like pythonw myScript.py from the Terminal, I find myself in an interpreter after I use the quit menu. The menubar becomes a single, hung python menu, and a shell window pops up with an interpreter prompt. Cntrl-D kills the interpreter. It's as if python was stuck in "-i" mode: pythonw -i myScript.py gives the same results. (python and pythonw give the same results. It appears from comments on the web that they are now the same. They appear so from a diff. If so, why not a symlink?) Running the lastest wxPython demo gives this warning in the console, 2006-09-29 15:40:06.681 wxPython Demo[942] WARNING: _wrapRunLoopWithAutoreleasePoolHandler got kCFRunLoopExit, but there are no autorelease pools in the stack. which may or may not be related. ---------------------------------------------------------------------- >Comment By: jjackson (jejackson) Date: 2006-09-30 14:48 Message: Logged In: YES user_id=1497873 I tried: Olivos:~ jj$ echo $PYTHONINSPECT Olivos:~ jj$ Looks like it isn't set. However, this might be a wxPython bug. I tried a tcl/tk app from the demos: Applications/MacPython 2.5/Extras/Demo/tkinter/guido/solitaire.py. Quitting it worked fine. I'll post something on the wxPython mac list. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:24 Message: Logged In: YES user_id=849994 Could you check if it is set? (using echo $PYTHONINSPECT in a console?) ---------------------------------------------------------------------- Comment By: jjackson (jejackson) Date: 2006-09-30 10:55 Message: Logged In: YES user_id=1497873 No, I didn't set the PYTHONINSPECT env variable. If it was set, it was by something else. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 00:47 Message: Logged In: YES user_id=849994 Did you (or someone else) perhaps set the PYTHONINSPECT environment variable? I can't imagine another cause for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568075&group_id=5470