From noreply at sourceforge.net Fri Jun 1 00:49:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 15:49:01 -0700 Subject: [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Please note that this 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.3 Status: Open Resolution: Later Priority: 4 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-05-31 15:49 Message: Logged In: YES user_id=357491 Originator: YES This is still failing in the trunk (r55677). Any chance this is going to be addressed soon? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-12-18 16:21 Message: Logged In: YES user_id=45365 I'd like to keep this bug open, because the underlying problem is serious: the Python interfaces to the MacOSX APIs assume that the binary representation of "python unicode" is identical to the binary representation of "macosx unicode". This needs to be fixed at some point, but such a fix requires major surgery (especially if we want things to be efficient for the normal case, where the assumption indeed holds). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 13:40 Message: Logged In: YES user_id=357491 This test still fails in 2.4 and so far in 2.5 . Does this still deserve a "later" resolution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 14:27 Message: Logged In: YES user_id=357491 Sorry, Jack. I didn't know that this was a Unicode issue. Oh well, at least the cause has been narrowed down. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 12:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 11:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 08:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-21 23:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-19 17:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply at sourceforge.net Fri Jun 1 03:19:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 18:19:29 -0700 Subject: [ python-Bugs-1729170 ] os.stat producing incorrect / invalid results Message-ID: Bugs item #1729170, was opened at 2007-05-31 17:24 Message generated for change (Comment added) made by joesalmeri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe (joesalmeri) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat producing incorrect / invalid results Initial Comment: Python 2.51 Windows XP SP2 + all updates *** NOTE all code has worked on previous python versions I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some unexpected behavior that appears to be a bug in the os.stat module. My OS is Windows XP SP2 + all updates. I have several programs that have worked flawlessly on all previous Python versions for years and they are now producing incorrect results in the code that uses os.stat. Searching through the 2.5.1 release notes I found the following: Use Win32 API to implement os.stat/fstat. As a result, subsecond timestamps are reported, the limit on path name lengths is removed, and stat reports WindowsError now (instead of OSError). ********************* * Overview of the problem: ********************* Reviewing my code it seems that it should still work with the 2.5.1 os.stat changes however that does not appear to be the case. Timestamps reported by os.stat() are no longer correct and the results are not even consistent. In my first test case ALL 3 timestamps reported by Python are 1 hour less than the actual timestamp on the file. In my second test case the created and last accessed timestamps reported by Python are correct but the last write timestamp is 1 hour less than the actual timestamp on the file. As a third test I looked at the last write timestamps on approximately 21,000 files. Python determined wrong last write timestamp on approximately 1581 files. Assuming there is no error in the following code that prints out the timestamps using the new return value from os.stat() then it would appear that the 2.5.1 os.stat changes have a bug. print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) ********************* * Detailed test results ********************* To demonstrate the problem I have created the following test. Here are the files that will be used in my test and their associated timestamps as reported the the dir command. 01/02/2003 12:34 PM 0 broke_test 03/06/2007 05:24 PM 3,497,177 broke_test2 05/31/2007 04:35 PM 254 runtest.cmd 05/31/2007 04:31 PM 513 broke.py The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does not show seconds). The runtest.cmd script shows the created, last accessed, and last write timestamps as reported by the dir command (and also verified via right clicking on the file and selecting properties in Explorer. ------ >>> START runtest.cmd script <<<< @Echo Off echo Create TimeStamp reported by dir command dir /tc %1 echo Last Access TimeStamp reported by dir command dir /ta %1 echo Last Write TimeStamp reported by dir command dir /tw %1 echo Python 2.5.1 timestamp info broke.py %1 ------ >>> END runtest.cmd script <<<< The broke.py script prints out the created, last accessed, last write timestamps as Python sees them. ------ >>> START broke.py script <<<< import sys import os import stat import time file_name = sys.argv[1] file_stats = os.stat(file_name) print print 'File Name : %s' % (file_name) print print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) print ------ >>> END broke.py script <<<< # # Test 1 on file broke_test # runtest broke_test Create TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Access TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Write TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Python 2.5.1 timestamp info File Name : broke_test Creation Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Access Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Write Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short # # Test 2 on file broke_test2 # runtest broke_test2 Create TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Access TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Write TimeStamp reported by dir command 03/06/2007 05:24 PM 3,497,177 broke_test2 Python 2.5.1 timestamp info File Name : broke_test2 Creation Time: 05/31/2007 16:26:36 -- Python results are correct Last Access Time: 05/31/2007 16:26:38 -- Python results are correct Last Write Time: 03/06/2007 16:24:21 -- Python results are WRONG hours reported are 1 hour short ---------------------------------------------------------------------- >Comment By: Joe (joesalmeri) Date: 2007-05-31 21:19 Message: Logged In: YES user_id=1235002 Originator: YES More details and a program that demonstrates the problem I created a file and specifically set the created date, last accessed date and last write date to 01/02/2003 12:34:56 After setting the date and time on the file I verified the following: The dir /tc command shows the correct Create date of 01/02/2003 12:34 The dir /ta command shows the correct Access date of 01/02/2003 12:34 The dir /tw command shows the correct Write date of 01/02/2003 12:34 Looking at the properties of the file in Windows Explorer also shows that all 3 dates match. When Python 2.4.2 os.stat is used to get those timestamps all 3 are CORRECT When Python 2.5.1 os.stat is used to get those timestamps all 3 are WRONG and they are off by exact 1 hour 01/02/2003 11:34:56 instead of 01/02/2003 12:34:56 In the case of my above test I know exactly what the timestamp on the file is because I manually set it so that all 3 timestamps are the same. Since Python 2.5.1 does not return the known values for that files timestamps how can it not be a Python 2.5.1 bug? Further testing shows that the results are somewhat inconsistent, many times the create and access date are correct but the Last Write timestamp is wrong. It is generally off by one hour but I have seen situations where it was +1 hour and other situations where it was -1 hour. I even found situations where the python timestamp was 1 minute later. (I know about the 2 second timestamps on FAT, all my filesystems are NTFS). I just found a situation where the python timestamp was 02:51 PM and the windows timestamp was 02:12 PM. DST or timezone changes are not going to make the results be off by 39 minutes? (My timezone is GMT - 5:00). As an additional test I wrote the following Python program which takes a directory name as a paramater. It retrieves all 3 dates for all files in all directories and subdirectories for the specified directory name. First it gets the dates using Python and os.stat, then it runs the dir /tc, dir /ta, and dir /tw commands on the file. Finally it compares the dates and times returned by Python against the dates and times that the Windows dir command is reporting. If you run the program using Python 2.4.2 then ALL dates and times returned by Python 2.4.2 correctly match the dates and times that Windows reports. If you run the program using Python 2.5.1 against the same directory then you get intermittient results. As a quick test I ran it against a directory on my home directory. Python 2.4.2 all dates matched between what the Windows dir command reported and what Python 2.4.2 reported. Python 2.5.1 had the following differences (more than 50% of the time it was wrong) Total Files Processed : 149 Matched All 3 Dates : 70 Did NOT Match All 3 Dates: 79 Matched Create Date : 69 Did NOT Match Create Date: 10 Matched Access Date : 59 Did NOT Match Access Date: 20 Matched Write Date : 11 Did NOT Match Write Date : 68 Here's the source for the check_dates.py program. Run it for youself and see what your results are. import os import stat import sys import time if len(sys.argv) == 1: print print '%s path_to_check' % (sys.argv[0]) print raise SystemExit else: path_to_check = sys.argv[1] file_count = 0 file_match_count = 0 file_no_match_count = 0 create_match_count = 0 create_no_match_count = 0 access_match_count = 0 access_no_match_count = 0 write_match_count = 0 write_no_match_count = 0 for root, dirs, files in os.walk(r'%s' % path_to_check): for file in files: file_count = file_count + 1 file_name = os.path.join(root, file) create_ts_match = False access_ts_match = False write_ts_match = False file_stats = os.stat(file_name) python_create_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_CTIME])) python_access_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_ATIME])) python_write_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_MTIME])) win_create_ts = os.popen('dir /a /tc "%s"' % (file_name)).readlines()[5][0:20] win_access_ts = os.popen('dir /a /ta "%s"' % (file_name)).readlines()[5][0:20] win_write_ts = os.popen('dir /a /tw "%s"' % (file_name)).readlines()[5][0:20] if python_create_ts == win_create_ts: create_ts_match = True if python_access_ts == win_access_ts: access_ts_match = True if python_write_ts == win_write_ts: write_ts_match = True if create_ts_match and access_ts_match and write_ts_match: # All timestamps match file_match_count = file_match_count + 1 else: file_no_match_count = file_no_match_count + 1 print print 'File Name : %s' % (file_name) print if create_ts_match: create_match_count = create_match_count + 1 else: create_no_match_count = create_no_match_count + 1 print 'python_create_ts: %s' % (python_create_ts) print 'win_create_ts : %s' % (win_create_ts) print if access_ts_match: access_match_count = access_match_count + 1 else: access_no_match_count = access_no_match_count + 1 print 'python_access_ts: %s' % (python_access_ts) print 'win_access_ts : %s' % (win_access_ts) print if write_ts_match: write_match_count = write_match_count + 1 else: write_no_match_count = write_no_match_count + 1 print 'python_write_ts : %s' % (python_write_ts) print 'win_write_ts : %s' % (win_write_ts) print # # Show Count Results # print 'Total Files Processed : %s' % (file_count) print print 'Matched All 3 Dates : %s' % (file_match_count) print 'Did NOT Match All 3 Dates: %s' % (file_no_match_count) print print 'Matched Create Date : %s' % (create_match_count) print 'Did NOT Match Create Date: %s' % (create_no_match_count) print print 'Matched Access Date : %s' % (access_match_count) print 'Did NOT Match Access Date: %s' % (access_no_match_count) print print 'Matched Write Date : %s' % (write_match_count) print 'Did NOT Match Write Date : %s' % (write_no_match_count) print ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 From noreply at sourceforge.net Fri Jun 1 04:28:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 19:28:24 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-05-31 19: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=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Fri Jun 1 05:08:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 20:08:28 -0700 Subject: [ python-Bugs-1729280 ] Error in example Message-ID: Bugs item #1729280, was opened at 2007-05-31 22: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=1729280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: accdak (accdak) Assigned to: Nobody/Anonymous (nobody) Summary: Error in example Initial Comment: On http://docs.python.org/tut/node5.html the example: There is full support for floating point; operators with mixed type operands convert the integer operand to floating point: >>> 3 * 3.75 / 1.5 7.5 is incorrect. The resulting value is 5.5 not 7.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729280&group_id=5470 From noreply at sourceforge.net Fri Jun 1 07:16:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 22:16:47 -0700 Subject: [ python-Bugs-1729305 ] test_doctest fails when run in verbose mode Message-ID: Bugs item #1729305, was opened at 2007-05-31 22:16 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=1729305&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_doctest fails when run in verbose mode Initial Comment: This happens on trunk, p3yk branch and 2.5. Trying: doctest.testfile('test_doctest4.txt', encoding='utf-8') Expecting: (0, 4) test test_doctest crashed -- : 'ascii' codec can't encode characters in position 301-302: ordinal not in range(128) Traceback (most recent call last): File "./Lib/test/regrtest.py", line 557, in runtest_inner indirect_test() File "/home/neal/python/dev/r25/Lib/test/test_doctest.py", line 2402, in test_main test_support.run_doctest(test_doctest, verbosity=True) File "/home/neal/python/dev/r25/Lib/test/test_support.py", line 467, in run_doctest f, t = doctest.testmod(module, verbose=verbosity) File "/home/neal/python/dev/r25/Lib/doctest.py", line 1799, in testmod runner.run(test) File "/home/neal/python/dev/r25/Lib/doctest.py", line 1345, in run return self.__run(test, compileflags, out) File "/home/neal/python/dev/r25/Lib/doctest.py", line 1261, in __run self.report_failure(out, test, example, got) File "/home/neal/python/dev/r25/Lib/doctest.py", line 1125, in report_failure self._checker.output_difference(example, got, self.optionflags)) UnicodeEncodeError: 'ascii' codec can't encode characters in position 301-302: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729305&group_id=5470 From noreply at sourceforge.net Fri Jun 1 07:35:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 22:35:02 -0700 Subject: [ python-Bugs-1729280 ] Error in example Message-ID: Bugs item #1729280, was opened at 2007-05-31 20:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729280&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: accdak (accdak) Assigned to: Nobody/Anonymous (nobody) Summary: Error in example Initial Comment: On http://docs.python.org/tut/node5.html the example: There is full support for floating point; operators with mixed type operands convert the integer operand to floating point: >>> 3 * 3.75 / 1.5 7.5 is incorrect. The resulting value is 5.5 not 7.5 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 22:35 Message: Logged In: YES user_id=33168 Originator: NO Perhaps you misread the star (*) as a plus (+)? >>> 3 * 3.75 / 1.5 7.5 >>> 3 + 3.75 / 1.5 5.5 For multiplication (*), 7.5 is correct. For addition (+), 5.5 is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729280&group_id=5470 From noreply at sourceforge.net Fri Jun 1 07:39:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 22:39:20 -0700 Subject: [ python-Bugs-1729170 ] os.stat producing incorrect / invalid results Message-ID: Bugs item #1729170, was opened at 2007-05-31 14:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe (joesalmeri) >Assigned to: Martin v. L?wis (loewis) Summary: os.stat producing incorrect / invalid results Initial Comment: Python 2.51 Windows XP SP2 + all updates *** NOTE all code has worked on previous python versions I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some unexpected behavior that appears to be a bug in the os.stat module. My OS is Windows XP SP2 + all updates. I have several programs that have worked flawlessly on all previous Python versions for years and they are now producing incorrect results in the code that uses os.stat. Searching through the 2.5.1 release notes I found the following: Use Win32 API to implement os.stat/fstat. As a result, subsecond timestamps are reported, the limit on path name lengths is removed, and stat reports WindowsError now (instead of OSError). ********************* * Overview of the problem: ********************* Reviewing my code it seems that it should still work with the 2.5.1 os.stat changes however that does not appear to be the case. Timestamps reported by os.stat() are no longer correct and the results are not even consistent. In my first test case ALL 3 timestamps reported by Python are 1 hour less than the actual timestamp on the file. In my second test case the created and last accessed timestamps reported by Python are correct but the last write timestamp is 1 hour less than the actual timestamp on the file. As a third test I looked at the last write timestamps on approximately 21,000 files. Python determined wrong last write timestamp on approximately 1581 files. Assuming there is no error in the following code that prints out the timestamps using the new return value from os.stat() then it would appear that the 2.5.1 os.stat changes have a bug. print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) ********************* * Detailed test results ********************* To demonstrate the problem I have created the following test. Here are the files that will be used in my test and their associated timestamps as reported the the dir command. 01/02/2003 12:34 PM 0 broke_test 03/06/2007 05:24 PM 3,497,177 broke_test2 05/31/2007 04:35 PM 254 runtest.cmd 05/31/2007 04:31 PM 513 broke.py The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does not show seconds). The runtest.cmd script shows the created, last accessed, and last write timestamps as reported by the dir command (and also verified via right clicking on the file and selecting properties in Explorer. ------ >>> START runtest.cmd script <<<< @Echo Off echo Create TimeStamp reported by dir command dir /tc %1 echo Last Access TimeStamp reported by dir command dir /ta %1 echo Last Write TimeStamp reported by dir command dir /tw %1 echo Python 2.5.1 timestamp info broke.py %1 ------ >>> END runtest.cmd script <<<< The broke.py script prints out the created, last accessed, last write timestamps as Python sees them. ------ >>> START broke.py script <<<< import sys import os import stat import time file_name = sys.argv[1] file_stats = os.stat(file_name) print print 'File Name : %s' % (file_name) print print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) print ------ >>> END broke.py script <<<< # # Test 1 on file broke_test # runtest broke_test Create TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Access TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Write TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Python 2.5.1 timestamp info File Name : broke_test Creation Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Access Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Write Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short # # Test 2 on file broke_test2 # runtest broke_test2 Create TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Access TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Write TimeStamp reported by dir command 03/06/2007 05:24 PM 3,497,177 broke_test2 Python 2.5.1 timestamp info File Name : broke_test2 Creation Time: 05/31/2007 16:26:36 -- Python results are correct Last Access Time: 05/31/2007 16:26:38 -- Python results are correct Last Write Time: 03/06/2007 16:24:21 -- Python results are WRONG hours reported are 1 hour short ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 22:39 Message: Logged In: YES user_id=33168 Originator: NO Martin, was there a similar problem to this one? I looked in the log for posixmodule.c and didn't see this fixed. ---------------------------------------------------------------------- Comment By: Joe (joesalmeri) Date: 2007-05-31 18:19 Message: Logged In: YES user_id=1235002 Originator: YES More details and a program that demonstrates the problem I created a file and specifically set the created date, last accessed date and last write date to 01/02/2003 12:34:56 After setting the date and time on the file I verified the following: The dir /tc command shows the correct Create date of 01/02/2003 12:34 The dir /ta command shows the correct Access date of 01/02/2003 12:34 The dir /tw command shows the correct Write date of 01/02/2003 12:34 Looking at the properties of the file in Windows Explorer also shows that all 3 dates match. When Python 2.4.2 os.stat is used to get those timestamps all 3 are CORRECT When Python 2.5.1 os.stat is used to get those timestamps all 3 are WRONG and they are off by exact 1 hour 01/02/2003 11:34:56 instead of 01/02/2003 12:34:56 In the case of my above test I know exactly what the timestamp on the file is because I manually set it so that all 3 timestamps are the same. Since Python 2.5.1 does not return the known values for that files timestamps how can it not be a Python 2.5.1 bug? Further testing shows that the results are somewhat inconsistent, many times the create and access date are correct but the Last Write timestamp is wrong. It is generally off by one hour but I have seen situations where it was +1 hour and other situations where it was -1 hour. I even found situations where the python timestamp was 1 minute later. (I know about the 2 second timestamps on FAT, all my filesystems are NTFS). I just found a situation where the python timestamp was 02:51 PM and the windows timestamp was 02:12 PM. DST or timezone changes are not going to make the results be off by 39 minutes? (My timezone is GMT - 5:00). As an additional test I wrote the following Python program which takes a directory name as a paramater. It retrieves all 3 dates for all files in all directories and subdirectories for the specified directory name. First it gets the dates using Python and os.stat, then it runs the dir /tc, dir /ta, and dir /tw commands on the file. Finally it compares the dates and times returned by Python against the dates and times that the Windows dir command is reporting. If you run the program using Python 2.4.2 then ALL dates and times returned by Python 2.4.2 correctly match the dates and times that Windows reports. If you run the program using Python 2.5.1 against the same directory then you get intermittient results. As a quick test I ran it against a directory on my home directory. Python 2.4.2 all dates matched between what the Windows dir command reported and what Python 2.4.2 reported. Python 2.5.1 had the following differences (more than 50% of the time it was wrong) Total Files Processed : 149 Matched All 3 Dates : 70 Did NOT Match All 3 Dates: 79 Matched Create Date : 69 Did NOT Match Create Date: 10 Matched Access Date : 59 Did NOT Match Access Date: 20 Matched Write Date : 11 Did NOT Match Write Date : 68 Here's the source for the check_dates.py program. Run it for youself and see what your results are. import os import stat import sys import time if len(sys.argv) == 1: print print '%s path_to_check' % (sys.argv[0]) print raise SystemExit else: path_to_check = sys.argv[1] file_count = 0 file_match_count = 0 file_no_match_count = 0 create_match_count = 0 create_no_match_count = 0 access_match_count = 0 access_no_match_count = 0 write_match_count = 0 write_no_match_count = 0 for root, dirs, files in os.walk(r'%s' % path_to_check): for file in files: file_count = file_count + 1 file_name = os.path.join(root, file) create_ts_match = False access_ts_match = False write_ts_match = False file_stats = os.stat(file_name) python_create_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_CTIME])) python_access_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_ATIME])) python_write_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_MTIME])) win_create_ts = os.popen('dir /a /tc "%s"' % (file_name)).readlines()[5][0:20] win_access_ts = os.popen('dir /a /ta "%s"' % (file_name)).readlines()[5][0:20] win_write_ts = os.popen('dir /a /tw "%s"' % (file_name)).readlines()[5][0:20] if python_create_ts == win_create_ts: create_ts_match = True if python_access_ts == win_access_ts: access_ts_match = True if python_write_ts == win_write_ts: write_ts_match = True if create_ts_match and access_ts_match and write_ts_match: # All timestamps match file_match_count = file_match_count + 1 else: file_no_match_count = file_no_match_count + 1 print print 'File Name : %s' % (file_name) print if create_ts_match: create_match_count = create_match_count + 1 else: create_no_match_count = create_no_match_count + 1 print 'python_create_ts: %s' % (python_create_ts) print 'win_create_ts : %s' % (win_create_ts) print if access_ts_match: access_match_count = access_match_count + 1 else: access_no_match_count = access_no_match_count + 1 print 'python_access_ts: %s' % (python_access_ts) print 'win_access_ts : %s' % (win_access_ts) print if write_ts_match: write_match_count = write_match_count + 1 else: write_no_match_count = write_no_match_count + 1 print 'python_write_ts : %s' % (python_write_ts) print 'win_write_ts : %s' % (win_write_ts) print # # Show Count Results # print 'Total Files Processed : %s' % (file_count) print print 'Matched All 3 Dates : %s' % (file_match_count) print 'Did NOT Match All 3 Dates: %s' % (file_no_match_count) print print 'Matched Create Date : %s' % (create_match_count) print 'Did NOT Match Create Date: %s' % (create_no_match_count) print print 'Matched Access Date : %s' % (access_match_count) print 'Did NOT Match Access Date: %s' % (access_no_match_count) print print 'Matched Write Date : %s' % (write_match_count) print 'Did NOT Match Write Date : %s' % (write_no_match_count) print ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 From noreply at sourceforge.net Fri Jun 1 07:49:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 22:49:52 -0700 Subject: [ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object Message-ID: Bugs item #1729014, was opened at 2007-05-31 08:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 22:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 From noreply at sourceforge.net Fri Jun 1 09:23:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 00:23:56 -0700 Subject: [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Please note that this 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.3 Status: Open Resolution: Later Priority: 4 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2007-06-01 09:23 Message: Logged In: YES user_id=45365 Originator: NO Hi Brett! This bug turns in to a once-a-year "how are you " conversation:-) I haven't checked whether unicode objects have grown the required method in the mean time. If they have this problem could be solved, otherwise it can't (at least, not without serious hacking). But: even if the APIs are available that woulnd't mean that I have time to look at the problem in the foreseeable future... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-01 00:49 Message: Logged In: YES user_id=357491 Originator: YES This is still failing in the trunk (r55677). Any chance this is going to be addressed soon? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-12-19 01:21 Message: Logged In: YES user_id=45365 I'd like to keep this bug open, because the underlying problem is serious: the Python interfaces to the MacOSX APIs assume that the binary representation of "python unicode" is identical to the binary representation of "macosx unicode". This needs to be fixed at some point, but such a fix requires major surgery (especially if we want things to be efficient for the normal case, where the assumption indeed holds). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 22:40 Message: Logged In: YES user_id=357491 This test still fails in 2.4 and so far in 2.5 . Does this still deserve a "later" resolution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 23:27 Message: Logged In: YES user_id=357491 Sorry, Jack. I didn't know that this was a Unicode issue. Oh well, at least the cause has been narrowed down. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 21:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 20:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 17:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 08:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-20 02:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 22:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply at sourceforge.net Fri Jun 1 09:32:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 00:32:13 -0700 Subject: [ python-Bugs-1668596 ] distutils chops the first character of filenames Message-ID: Bugs item #1668596, was opened at 2007-02-25 14:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Sam Pointon (freecondiments) >Assigned to: Neal Norwitz (nnorwitz) Summary: distutils chops the first character of filenames Initial Comment: Python 2.5c1, Windows XP SP2. distutils chops the first character from some filenames if the package_data key is ''. Minimal example: The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error. On my box, this fails with: running bdist running bdist_dumb running build running build_py error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error. On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:32 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 55731. (2.6) Still needs to be backported. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:21 Message: Logged In: YES user_id=984087 Originator: NO It appears that I misunderstood the problem. Also, the attached setup.py has a typo. Instead of package_data = {'': ['doc/*']} it should read package_data = {'foobar': ['doc/*']} Any way, I reproduced the problem and created a patch (1720897). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-16 08:47 Message: Logged In: YES user_id=984087 Originator: NO After reading the distutils example section today, I did find one example using null string as package_dir value. So there may be something to this bug after all. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-27 09:19 Message: Logged In: YES user_id=984087 Originator: NO Hi, I reproduced the problem with the latest build on linux. The "fix" may be trivial but I am not entirely sure if there is a problem in the first place. The distutils document does not mention about having null value for package_dir as is the case in your setup.py. I may be missing something here but can you please explain the conclusion that "" is a perfectly valid value for package_dir (as mentioned in one of the threads in mailing list)? I am assuming that you mean "distribution root" directory by "". If this is found to be valid usage, the document should be updated along with the code fix. Otherwise, a check can be put in to disallow null values. Raghu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 From noreply at sourceforge.net Fri Jun 1 13:34:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 04:34:40 -0700 Subject: [ python-Bugs-1722485 ] Option -OO doesn't remove docstrings Message-ID: Bugs item #1722485, was opened at 2007-05-21 08:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470 Please note that this 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: Fixed Priority: 7 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: Option -OO doesn't remove docstrings Initial Comment: I'm using Python 2.5.1 as said by the -V switch under Windows XP. I run one of my programs with -OO, which generates a good amount of .pyo files in the directory. According to -h the -OO parameter removes docstrings. However, when I open the .pyo files with vim I can see all the docstrings in plain text. Conclusion, docstrings are not being removed. I noticed this in 2.5, which prompted me to upgrade after this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=464D5A57.2060809%40rastertech.es&forum_name=py2exe-users ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-01 11:34 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 55732, 55733 (2.5). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-23 18:26 Message: Logged In: YES user_id=11105 Originator: NO I can confirm this bug (but have no time to work on a patch). This simple script prints 'the docs' when run with 'python2.5 -OO', but prints 'None' when run with Python2.4 (for example). IMO this should be fixed in the next maintainance release, so raising the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470 From noreply at sourceforge.net Sat Jun 2 00:42:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 15:42:02 -0700 Subject: [ python-Bugs-1723875 ] inspect.formatargspec last argument ignored Message-ID: Bugs item #1723875, was opened at 2007-05-23 00:46 Message generated for change (Comment added) made by patrickcd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470 Please note that this 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: 1 Private: No Submitted By: Patrick Dobbs (patrickcd) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.formatargspec last argument ignored Initial Comment: from: patrick at laculine.com The last argument of inspect.formatargspect() is a function to control the way the entire returned string is formatted: ...join=joinseq): joinseq being a function at line 757 in inspect.py However, this argument is ignored and joinseq is not called. The line in question is inspect.py 794 it was: return '(' + string.join(specs, ', ') + ')' The function seems to work as advertised if this line is replaced by: return join(specs) ---------------------------------------------------------------------- >Comment By: Patrick Dobbs (patrickcd) Date: 2007-06-01 22:42 Message: Logged In: YES user_id=314154 Originator: YES On writing a test case I realised that that this bug report is invalid. The ninth argument "join" is specified as determining how the arguments are formatted, not how the entire returned string is formatted. It works perfectly well. I can submit a lame test case which proves this bug report is bogus, but it seems better to retire gracefully.. "TAXI!!" ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-31 15:41 Message: Logged In: YES user_id=984087 Originator: NO A simple look at the source proves your point. BTW, the same problem exists for formatargvalues(). Do you think you can work up a patch? The code change itself would be simple but the patch would require a test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470 From noreply at sourceforge.net Sat Jun 2 01:28:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 16:28:05 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 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=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) >Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Sat Jun 2 01:51:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 16:51:25 -0700 Subject: [ python-Bugs-1729742 ] missing int->Py_ssize_t in documentation Message-ID: Bugs item #1729742, was opened at 2007-06-01 16: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=1729742&group_id=5470 Please note that this 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 Private: No Submitted By: Brian Wellington (bwelling) Assigned to: Nobody/Anonymous (nobody) Summary: missing int->Py_ssize_t in documentation Initial Comment: The "Parsing arguments and building values" section of the Python/C API Reference Manual describes the "s#" format unit as requiring a [const char *, int]. This should presumably be a Py_ssize_t, as that's what the code appears to expect. The same problem also occurs elsewhere in this page; pretty much everywhere the # format modifier is described. I'm seeing this in both the 2.5.1 and development versions of the docs on docs.python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729742&group_id=5470 From noreply at sourceforge.net Sat Jun 2 03:19:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 18:19:14 -0700 Subject: [ python-Bugs-1727418 ] xmlrpclib waits indefinately Message-ID: Bugs item #1727418, was opened at 2007-05-29 08:57 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727418&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arno Stienen (arnostienen) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib waits indefinately Initial Comment: I'm not sure if it is a Python bug, but I'm having problems using xmlrpclib to connect to a remote server. When using this code to connect to a remote XML-RPC server (C++, xmlrpc++0.7 library): import xmlrpclib server = xmlrpclib.Server("http://10.10.101.62:29500") print server.Connection_Request("roberto") the Python command line 'hangs' until I kill the server. Then, the correct output is suddenly displayed: {'state': 0, 'id_session': '2Z3EUSLJFA13', 'port': 29501, 'str': 'Connection accepted. Session attached.'} Yet a slightly simpler call works flawlessly: import xmlrpclib server = xmlrpclib.Server("http://10.10.101.62:29500") print server.Info_RT('Master') {'state': 0, 'str': 'Info_RT'} Looking at the TCP packages (using Wireshark), the first Connection_Request flow as follows (c=python client,s= xml-rpcserver): 1 c>s SYN 2 s>c SYN,ACK 3 c>s ACK 4 c>s PSH,ACK (setting content-type: text/xml) 5 s>c ACK 6 c>s PSH,ACK (xml-rpc request) 7 s>c ACK 8 s>c PSH,ACK (xml-rpc results, correct) 9 c>s ACK At this point, Python 'hangs' until I kill (-9) the server (28 seconds later), and then these last packages are send: 10 s>c FIN,ACK 11 c>s FIN,ACk 12 s>c ACK After which Python continues and prints the xml-rpc results on the screen. Strangely, before Python hangs, it has already received the package with the results, but doesn't do anything with it. For comparison, this is the package flow for the Info_RT method, which returns within a second with the correct result on the Python command line: 1 c>s SYN 2 s>c SYN,ACK 3 c>s ACK 4 c>s PSH,ACK (setting content-type: text/xml) 5 s>c ACK 6 c>s PSH,ACK (xml-rpc request) 7 s>c ACK 8 s>c PSH,ACK (xml-rpc results, correct) 9 s>c FIN,ACK 10 c>s ACK 11 c>s FIN,ACk 12 s>c ACK Notice the reverse order of packages 9 and 10. Could this be it? Is Python waiting until the server sends a FIN package? But if so, why? Looking at the Python trace, this might be it. A diff between the trace of the killed Connection_Request and the Info_RT resulted only in expected differences (due to different length of parameters). But when diffing the traces of the killed and non-killed Connection_Request, something else is visible. The killed Connection_Request ends with: [...] string:318: return sep.join(words) xmlrpclib:866: self._type = "params" xmlrpclib:769: try: xmlrpclib:770: f = self.dispatch[tag] xmlrpclib:771: except KeyError: xmlrpclib:772: pass # unknown tag ? xmlrpclib:1273: if sock: xmlrpclib:1274: response = sock.recv(1024) xmlrpclib:1277: if not response: xmlrpclib:1278: break xmlrpclib:1283: file.close() socket:218: try: socket:219: if self._sock: socket:220: self.flush() socket:232: if self._wbuf: socket:222: self._sock = None xmlrpclib:1284: p.close() xmlrpclib:530: self._parser.Parse("", 1) # end of data xmlrpclib:531: del self._target, self._parser # get rid of circular references xmlrpclib:1286: return u.close() xmlrpclib:741: if self._type is None or self._marks: xmlrpclib:743: if self._type == "fault": xmlrpclib:745: return tuple(self._stack) socket:225: try: socket:226: self.close() socket:218: try: socket:219: if self._sock: socket:222: self._sock = None xmlrpclib:1386: if len(response) == 1: xmlrpclib:1387: response = response[0] xmlrpclib:1389: return response __main__:26: print result {'state': 0, 'id_session': 'QDLY3GP9FBM5', 'port': 29501, 'str': 'Connection accepted. Session attached.'} But the non-killed Connection_Request looks like: [...] return sep.join(words) xmlrpclib:866: self._type = "params" xmlrpclib:769: try: xmlrpclib:770: f = self.dispatch[tag] xmlrpclib:771: except KeyError: xmlrpclib:772: pass # unknown tag ? xmlrpclib:1273: if sock: xmlrpclib:1274: response = sock.recv(1024) socket:225: try: socket:226: self.close() socket:218: try: socket:219: if self._sock: socket:220: self.flush() socket:232: if self._wbuf: socket:222: self._sock = None (In the diff there is a gap between the xmlrpclib:1274 and socket:225 lines, as compared to the killed Connection_Request; perhaps Ctrl+C still executes the "socket try close" lines?) If you want to do your own 'diff' on the Python traces, or look at the TCP packages in more details with Wireshark, here are the files for the correctly working Info_RT and faulty Connection_Request methods: http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-python.ws http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-python-ws.txt http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-infort-trace.txt http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-python.ws http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-python-ws.txt http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-trace.txt http://ctw-bw008.ctw.utwente.nl/~arno/rtaixml/roberto-conreq-trace-hardbreak.txt (The first three ConReq files all include killing the server after ~28 seconds, thus resulting in the correct output. In the fourth files, tracing is stopped before the server is killed. It is therefor the trace up to the 'hanging point'. Note that the first two Wireshark packages are not TCP, but ARP, thus the file has a total of 14 packages, not 12 as above.) Really, any help here is appreciated! ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-01 22:19 Message: Logged In: YES user_id=479790 Originator: NO Copying a reply from Tijs posted at c.l.p. : --- After having a quick look at your files, I conclude that the problem is in a combination of two problems: 1. Your server is crap. It answers an HTTP/1.0 request by an HTTP/1.1 response without specifying any Connection header and without closing the connection. Normally, a simple client that is not HTTP/1.1-aware expects the connection to close. HTTP/1.1 leaves the connection open by default. 2. The Python implementation of xmlrpc is not very robust. It just waits for the connection to close. A well-written client (like your Java client) would detect the presence of a Content-Length header and use that. The other request is OK because the server closes the connection after having sent the response. Why the difference? Don't know, but it is something server-side. Try to force the server to send HTTP/1.0 responses, or turn off keep-alive, or something like that. Otherwise, adapt xmlrpclib.py to robustly handle 1.1 responses. --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727418&group_id=5470 From noreply at sourceforge.net Sat Jun 2 09:27:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 00:27:54 -0700 Subject: [ python-Bugs-1729742 ] missing int->Py_ssize_t in documentation Message-ID: Bugs item #1729742, was opened at 2007-06-02 01:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729742&group_id=5470 Please note that this 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 Private: No Submitted By: Brian Wellington (bwelling) Assigned to: Nobody/Anonymous (nobody) Summary: missing int->Py_ssize_t in documentation Initial Comment: The "Parsing arguments and building values" section of the Python/C API Reference Manual describes the "s#" format unit as requiring a [const char *, int]. This should presumably be a Py_ssize_t, as that's what the code appears to expect. The same problem also occurs elsewhere in this page; pretty much everywhere the # format modifier is described. I'm seeing this in both the 2.5.1 and development versions of the docs on docs.python.org. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-02 09:27 Message: Logged In: YES user_id=21627 Originator: NO It's more complicated than that, see PEP 353: It's Py_ssize_t if the module defines PY_SSIZE_T_CLEAN, else it's int. Would you like to work on a patch fixing the documentation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729742&group_id=5470 From noreply at sourceforge.net Sat Jun 2 11:04:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 02:04:41 -0700 Subject: [ python-Bugs-1729170 ] os.stat producing incorrect / invalid results Message-ID: Bugs item #1729170, was opened at 2007-05-31 23:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe (joesalmeri) Assigned to: Martin v. L?wis (loewis) Summary: os.stat producing incorrect / invalid results Initial Comment: Python 2.51 Windows XP SP2 + all updates *** NOTE all code has worked on previous python versions I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some unexpected behavior that appears to be a bug in the os.stat module. My OS is Windows XP SP2 + all updates. I have several programs that have worked flawlessly on all previous Python versions for years and they are now producing incorrect results in the code that uses os.stat. Searching through the 2.5.1 release notes I found the following: Use Win32 API to implement os.stat/fstat. As a result, subsecond timestamps are reported, the limit on path name lengths is removed, and stat reports WindowsError now (instead of OSError). ********************* * Overview of the problem: ********************* Reviewing my code it seems that it should still work with the 2.5.1 os.stat changes however that does not appear to be the case. Timestamps reported by os.stat() are no longer correct and the results are not even consistent. In my first test case ALL 3 timestamps reported by Python are 1 hour less than the actual timestamp on the file. In my second test case the created and last accessed timestamps reported by Python are correct but the last write timestamp is 1 hour less than the actual timestamp on the file. As a third test I looked at the last write timestamps on approximately 21,000 files. Python determined wrong last write timestamp on approximately 1581 files. Assuming there is no error in the following code that prints out the timestamps using the new return value from os.stat() then it would appear that the 2.5.1 os.stat changes have a bug. print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) ********************* * Detailed test results ********************* To demonstrate the problem I have created the following test. Here are the files that will be used in my test and their associated timestamps as reported the the dir command. 01/02/2003 12:34 PM 0 broke_test 03/06/2007 05:24 PM 3,497,177 broke_test2 05/31/2007 04:35 PM 254 runtest.cmd 05/31/2007 04:31 PM 513 broke.py The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does not show seconds). The runtest.cmd script shows the created, last accessed, and last write timestamps as reported by the dir command (and also verified via right clicking on the file and selecting properties in Explorer. ------ >>> START runtest.cmd script <<<< @Echo Off echo Create TimeStamp reported by dir command dir /tc %1 echo Last Access TimeStamp reported by dir command dir /ta %1 echo Last Write TimeStamp reported by dir command dir /tw %1 echo Python 2.5.1 timestamp info broke.py %1 ------ >>> END runtest.cmd script <<<< The broke.py script prints out the created, last accessed, last write timestamps as Python sees them. ------ >>> START broke.py script <<<< import sys import os import stat import time file_name = sys.argv[1] file_stats = os.stat(file_name) print print 'File Name : %s' % (file_name) print print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) print ------ >>> END broke.py script <<<< # # Test 1 on file broke_test # runtest broke_test Create TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Access TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Write TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Python 2.5.1 timestamp info File Name : broke_test Creation Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Access Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Write Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short # # Test 2 on file broke_test2 # runtest broke_test2 Create TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Access TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Write TimeStamp reported by dir command 03/06/2007 05:24 PM 3,497,177 broke_test2 Python 2.5.1 timestamp info File Name : broke_test2 Creation Time: 05/31/2007 16:26:36 -- Python results are correct Last Access Time: 05/31/2007 16:26:38 -- Python results are correct Last Write Time: 03/06/2007 16:24:21 -- Python results are WRONG hours reported are 1 hour short ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-02 11:04 Message: Logged In: YES user_id=21627 Originator: NO I think there are several things going on here, and I believe that Python is behaving correctly. On Win32, there are two ways to find out the time stamps of a file: FindFirstFile reads it from the directory, and GetFileAttributesEx gets it directly from the file (i.e. on NTFS, from the MFT record). When a file is modified, NTFS normally modifies the file only, and updates the directory only occasionally (due to hard links, there might be multiple directories to update also). In particular, the last access time is rarely written back to the directory. You can easily see this for yourself with the following procedure: 1. Inspect the last-access time with dir /ta, or in Explorer. 2. Open the file in an editor, but don't edit it; close the editor. 3. Inspect the last-access time with dir /ta, and with broke.py 4. Wait 10 minutes. 5. Repeat steps 2 and 3. You should see that broke.py will report that the file was accessed, whereas Explorer and dir/ta will report an "old" last-acecssed time. I created a program that displays both the directory-stored and the file-stored last-acecss time (attached). This program may produce outputs such as C:\Pyinst\25\python>..\..\unstop\pa\Debug\pa.exe .svn\entries Last Access according to: FindFirstFile: 128252459235000000 2007-6-2 8:18:43 GetFileAttributesEx: 128252466734062500 2007-6-2 8:31:13 Please refer to http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true There, they explain that the access time (if it is stored at all, which can be turned off) gets updated on disk only if the actual last-access time and the stored last-access time differ by 1 hour. So if you perform steps 2 and 3 above after 1 hour again, you will indeed see that the last access time gets updated in explorer, too. Python 2.4 did use the same (incorrect) source that dir/ta and the explorer uses; Python 2.5 has fixed that bug. So I think we should remove the last-access time from our discussion. File Added: pa.zip ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 07:39 Message: Logged In: YES user_id=33168 Originator: NO Martin, was there a similar problem to this one? I looked in the log for posixmodule.c and didn't see this fixed. ---------------------------------------------------------------------- Comment By: Joe (joesalmeri) Date: 2007-06-01 03:19 Message: Logged In: YES user_id=1235002 Originator: YES More details and a program that demonstrates the problem I created a file and specifically set the created date, last accessed date and last write date to 01/02/2003 12:34:56 After setting the date and time on the file I verified the following: The dir /tc command shows the correct Create date of 01/02/2003 12:34 The dir /ta command shows the correct Access date of 01/02/2003 12:34 The dir /tw command shows the correct Write date of 01/02/2003 12:34 Looking at the properties of the file in Windows Explorer also shows that all 3 dates match. When Python 2.4.2 os.stat is used to get those timestamps all 3 are CORRECT When Python 2.5.1 os.stat is used to get those timestamps all 3 are WRONG and they are off by exact 1 hour 01/02/2003 11:34:56 instead of 01/02/2003 12:34:56 In the case of my above test I know exactly what the timestamp on the file is because I manually set it so that all 3 timestamps are the same. Since Python 2.5.1 does not return the known values for that files timestamps how can it not be a Python 2.5.1 bug? Further testing shows that the results are somewhat inconsistent, many times the create and access date are correct but the Last Write timestamp is wrong. It is generally off by one hour but I have seen situations where it was +1 hour and other situations where it was -1 hour. I even found situations where the python timestamp was 1 minute later. (I know about the 2 second timestamps on FAT, all my filesystems are NTFS). I just found a situation where the python timestamp was 02:51 PM and the windows timestamp was 02:12 PM. DST or timezone changes are not going to make the results be off by 39 minutes? (My timezone is GMT - 5:00). As an additional test I wrote the following Python program which takes a directory name as a paramater. It retrieves all 3 dates for all files in all directories and subdirectories for the specified directory name. First it gets the dates using Python and os.stat, then it runs the dir /tc, dir /ta, and dir /tw commands on the file. Finally it compares the dates and times returned by Python against the dates and times that the Windows dir command is reporting. If you run the program using Python 2.4.2 then ALL dates and times returned by Python 2.4.2 correctly match the dates and times that Windows reports. If you run the program using Python 2.5.1 against the same directory then you get intermittient results. As a quick test I ran it against a directory on my home directory. Python 2.4.2 all dates matched between what the Windows dir command reported and what Python 2.4.2 reported. Python 2.5.1 had the following differences (more than 50% of the time it was wrong) Total Files Processed : 149 Matched All 3 Dates : 70 Did NOT Match All 3 Dates: 79 Matched Create Date : 69 Did NOT Match Create Date: 10 Matched Access Date : 59 Did NOT Match Access Date: 20 Matched Write Date : 11 Did NOT Match Write Date : 68 Here's the source for the check_dates.py program. Run it for youself and see what your results are. import os import stat import sys import time if len(sys.argv) == 1: print print '%s path_to_check' % (sys.argv[0]) print raise SystemExit else: path_to_check = sys.argv[1] file_count = 0 file_match_count = 0 file_no_match_count = 0 create_match_count = 0 create_no_match_count = 0 access_match_count = 0 access_no_match_count = 0 write_match_count = 0 write_no_match_count = 0 for root, dirs, files in os.walk(r'%s' % path_to_check): for file in files: file_count = file_count + 1 file_name = os.path.join(root, file) create_ts_match = False access_ts_match = False write_ts_match = False file_stats = os.stat(file_name) python_create_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_CTIME])) python_access_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_ATIME])) python_write_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_MTIME])) win_create_ts = os.popen('dir /a /tc "%s"' % (file_name)).readlines()[5][0:20] win_access_ts = os.popen('dir /a /ta "%s"' % (file_name)).readlines()[5][0:20] win_write_ts = os.popen('dir /a /tw "%s"' % (file_name)).readlines()[5][0:20] if python_create_ts == win_create_ts: create_ts_match = True if python_access_ts == win_access_ts: access_ts_match = True if python_write_ts == win_write_ts: write_ts_match = True if create_ts_match and access_ts_match and write_ts_match: # All timestamps match file_match_count = file_match_count + 1 else: file_no_match_count = file_no_match_count + 1 print print 'File Name : %s' % (file_name) print if create_ts_match: create_match_count = create_match_count + 1 else: create_no_match_count = create_no_match_count + 1 print 'python_create_ts: %s' % (python_create_ts) print 'win_create_ts : %s' % (win_create_ts) print if access_ts_match: access_match_count = access_match_count + 1 else: access_no_match_count = access_no_match_count + 1 print 'python_access_ts: %s' % (python_access_ts) print 'win_access_ts : %s' % (win_access_ts) print if write_ts_match: write_match_count = write_match_count + 1 else: write_no_match_count = write_no_match_count + 1 print 'python_write_ts : %s' % (python_write_ts) print 'win_write_ts : %s' % (win_write_ts) print # # Show Count Results # print 'Total Files Processed : %s' % (file_count) print print 'Matched All 3 Dates : %s' % (file_match_count) print 'Did NOT Match All 3 Dates: %s' % (file_no_match_count) print print 'Matched Create Date : %s' % (create_match_count) print 'Did NOT Match Create Date: %s' % (create_no_match_count) print print 'Matched Access Date : %s' % (access_match_count) print 'Did NOT Match Access Date: %s' % (access_no_match_count) print print 'Matched Write Date : %s' % (write_match_count) print 'Did NOT Match Write Date : %s' % (write_no_match_count) print ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 From noreply at sourceforge.net Sat Jun 2 16:50:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 07:50:12 -0700 Subject: [ python-Bugs-1729929 ] test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Message-ID: Bugs item #1729929, was opened at 2007-06-02 09: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=1729929&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Initial Comment: Bug fix #1721309 should be rolled into 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729929&group_id=5470 From noreply at sourceforge.net Sat Jun 2 16:51:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 07:51:36 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09: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=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Sat Jun 2 16:53:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 07:53:35 -0700 Subject: [ python-Bugs-1720241 ] Compiler is not thread safe? Message-ID: Bugs item #1720241, was opened at 2007-05-16 14:38 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ??PC?? (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:53 Message: Logged In: YES user_id=370230 Originator: NO This works on Fedora 6 and Python 2.5.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:14 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP or on Gentoo Linux. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 04:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-18 01:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. ---------------------------------------------------------------------- Comment By: ??PC?? (zpcz) Date: 2007-05-17 10:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 18:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 From noreply at sourceforge.net Sat Jun 2 16:54:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 07:54:31 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Sat Jun 2 17:31:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 08:31:47 -0700 Subject: [ python-Bugs-1720241 ] Compiler is not thread safe? Message-ID: Bugs item #1720241, was opened at 2007-05-16 21:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: ??PC?? (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 16:53 Message: Logged In: YES user_id=370230 Originator: NO This works on Fedora 6 and Python 2.5.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 01:14 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP or on Gentoo Linux. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 11:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-18 08:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. ---------------------------------------------------------------------- Comment By: ??PC?? (zpcz) Date: 2007-05-17 17:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-17 01:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 From noreply at sourceforge.net Sat Jun 2 20:53:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 11:53:26 -0700 Subject: [ python-Bugs-1668596 ] distutils chops the first character of filenames Message-ID: Bugs item #1668596, was opened at 2007-02-25 14:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Sam Pointon (freecondiments) Assigned to: Neal Norwitz (nnorwitz) Summary: distutils chops the first character of filenames Initial Comment: Python 2.5c1, Windows XP SP2. distutils chops the first character from some filenames if the package_data key is ''. Minimal example: The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error. On my box, this fails with: running bdist running bdist_dumb running build running build_py error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error. On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-02 11:53 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 55747. (2.5) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:32 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 55731. (2.6) Still needs to be backported. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:21 Message: Logged In: YES user_id=984087 Originator: NO It appears that I misunderstood the problem. Also, the attached setup.py has a typo. Instead of package_data = {'': ['doc/*']} it should read package_data = {'foobar': ['doc/*']} Any way, I reproduced the problem and created a patch (1720897). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-16 08:47 Message: Logged In: YES user_id=984087 Originator: NO After reading the distutils example section today, I did find one example using null string as package_dir value. So there may be something to this bug after all. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-27 09:19 Message: Logged In: YES user_id=984087 Originator: NO Hi, I reproduced the problem with the latest build on linux. The "fix" may be trivial but I am not entirely sure if there is a problem in the first place. The distutils document does not mention about having null value for package_dir as is the case in your setup.py. I may be missing something here but can you please explain the conclusion that "" is a perfectly valid value for package_dir (as mentioned in one of the threads in mailing list)? I am assuming that you mean "distribution root" directory by "". If this is found to be valid usage, the document should be updated along with the code fix. Otherwise, a check can be put in to disallow null values. Raghu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 From noreply at sourceforge.net Sun Jun 3 03:01:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 18:01:32 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no loonger accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-02 20: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=1730114&group_id=5470 Please note that this 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 Private: No Submitted By: reedobrien (reedobrien) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO no loonger accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Sun Jun 3 03:02:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 18:02:46 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-02 20:01 Message generated for change (Settings changed) made by reedobrien You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 Please note that this 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 Private: No Submitted By: reedobrien (reedobrien) Assigned to: Nobody/Anonymous (nobody) >Summary: cStringIO no longer accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Sun Jun 3 07:16:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 22:16:46 -0700 Subject: [ python-Bugs-802310 ] tkFont may reuse font names Message-ID: Bugs item #802310, was opened at 2003-09-08 00:52 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802310&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: tkFont may reuse font names Initial Comment: (sent to me instead of to the bug manager; note that the tkFont naming approach is also used for widgets and callbacks /F) The class tkFont has a problem name it chooses if no name is given. The choosen method 'name = "font" + str(id (self))' isn't safe because the name may exists longer than the Font object and so another Font object may be created with a different font but the same id() and so the same name. id() says Return the identity of an object. This is guaranteed to be unique among simultaneously existing objects. ^^^^^^^^^^^^^^^^^^^^^^^ Note that this bug doesn't strike if you hold a reference to the Font object and so the GC can't reclaim the space. To reproduce run the attached program. It produces something like: previously: ('Times', 15, 'bold') now: ('Times', 18, 'bold') iterations: 8 mapping: {'font136494612': ('Times', 14, 'bold'), 'font136499772': ('Times', 15, 'bold'), 'font136545468': ('Times', 17, 'bold'), 'font136483156': ('Times', 11, 'bold'), 'font136502700': ('Times', 12, 'bold'), 'font136510460': ('Times', 13, 'bold'), 'font136515228': ('Times', 16, 'bold'), 'font136365348': ('Times', 10, 'bold')} Traceback (most recent call last): File "tkfont_bug.py", line 20, in ? assert 0 AssertionError Raimar ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2007-06-02 22:16 Message: Logged In: YES user_id=8861 Originator: NO This bug has bitten me too, in a real program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802310&group_id=5470 From noreply at sourceforge.net Sun Jun 3 07:20:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 22:20:25 -0700 Subject: [ python-Bugs-1730136 ] tkFont.__eq__ gives type error Message-ID: Bugs item #1730136, was opened at 2007-06-02 22:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730136&group_id=5470 Please note that this 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 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Martin v. L?wis (loewis) Summary: tkFont.__eq__ gives type error Initial Comment: The current definition is: def __eq__(self, other): return self.name == other.name and isinstance(other, Font) This can get an AttributeError if other isn't a Font. The code should be: def __eq__(self, other): return isinstance(other, Font) and self.name == other.name ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730136&group_id=5470 From noreply at sourceforge.net Sun Jun 3 07:49:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 22:49:22 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-02 20:01 Message generated for change (Comment added) made by reedobrien You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 Please note that this 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 Private: No Submitted By: reedobrien (reedobrien) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO no longer accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- >Comment By: reedobrien (reedobrien) Date: 2007-06-03 00:49 Message: Logged In: YES user_id=995094 Originator: YES It appears this is the change that broke it. http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302 This is the log entry from that changeset: Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode arguments with the system default encoding just like the write() method does, instead of converting it to a raw buffer. (backport from rev. 52301) Perhaps the cPickle module should be used instead... BUT at first glance the following seems to make both work: if (PyUnicode_Check(s)) { if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0) { PyErr_Format(PyExc_TypeError, "expected character buffer, %.200s found", s->ob_type->tp_name); return NULL; } } else { if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0) return NULL; } But the more I think about it the more I think cPickle is more appropriate for this purpose. In that case I should make a blurb for the docs about not storing arbitrary data in cStringIO. Either way I am attaching the cStringIO.c file that worked for me... File Added: cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Sun Jun 3 08:40:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 23:40:23 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-02 20:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 Please note that this 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 Private: No Submitted By: reedobrien (reedobrien) >Assigned to: Georg Brandl (gbrandl) Summary: cStringIO no longer accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 01:40 Message: Logged In: YES user_id=80475 Originator: NO Georgbot, I believe this was your checkin. ---------------------------------------------------------------------- Comment By: reedobrien (reedobrien) Date: 2007-06-03 00:49 Message: Logged In: YES user_id=995094 Originator: YES It appears this is the change that broke it. http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302 This is the log entry from that changeset: Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode arguments with the system default encoding just like the write() method does, instead of converting it to a raw buffer. (backport from rev. 52301) Perhaps the cPickle module should be used instead... BUT at first glance the following seems to make both work: if (PyUnicode_Check(s)) { if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0) { PyErr_Format(PyExc_TypeError, "expected character buffer, %.200s found", s->ob_type->tp_name); return NULL; } } else { if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0) return NULL; } But the more I think about it the more I think cPickle is more appropriate for this purpose. In that case I should make a blurb for the docs about not storing arbitrary data in cStringIO. Either way I am attaching the cStringIO.c file that worked for me... File Added: cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Sun Jun 3 08:50:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 23:50:13 -0700 Subject: [ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object Message-ID: Bugs item #1729014, was opened at 2007-05-31 10:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 01:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 From noreply at sourceforge.net Sun Jun 3 10:02:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 01:02:08 -0700 Subject: [ python-Bugs-1729170 ] os.stat producing incorrect / invalid results Message-ID: Bugs item #1729170, was opened at 2007-05-31 23:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 Please note that this 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 Private: No Submitted By: Joe (joesalmeri) Assigned to: Martin v. L?wis (loewis) Summary: os.stat producing incorrect / invalid results Initial Comment: Python 2.51 Windows XP SP2 + all updates *** NOTE all code has worked on previous python versions I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some unexpected behavior that appears to be a bug in the os.stat module. My OS is Windows XP SP2 + all updates. I have several programs that have worked flawlessly on all previous Python versions for years and they are now producing incorrect results in the code that uses os.stat. Searching through the 2.5.1 release notes I found the following: Use Win32 API to implement os.stat/fstat. As a result, subsecond timestamps are reported, the limit on path name lengths is removed, and stat reports WindowsError now (instead of OSError). ********************* * Overview of the problem: ********************* Reviewing my code it seems that it should still work with the 2.5.1 os.stat changes however that does not appear to be the case. Timestamps reported by os.stat() are no longer correct and the results are not even consistent. In my first test case ALL 3 timestamps reported by Python are 1 hour less than the actual timestamp on the file. In my second test case the created and last accessed timestamps reported by Python are correct but the last write timestamp is 1 hour less than the actual timestamp on the file. As a third test I looked at the last write timestamps on approximately 21,000 files. Python determined wrong last write timestamp on approximately 1581 files. Assuming there is no error in the following code that prints out the timestamps using the new return value from os.stat() then it would appear that the 2.5.1 os.stat changes have a bug. print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) ********************* * Detailed test results ********************* To demonstrate the problem I have created the following test. Here are the files that will be used in my test and their associated timestamps as reported the the dir command. 01/02/2003 12:34 PM 0 broke_test 03/06/2007 05:24 PM 3,497,177 broke_test2 05/31/2007 04:35 PM 254 runtest.cmd 05/31/2007 04:31 PM 513 broke.py The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does not show seconds). The runtest.cmd script shows the created, last accessed, and last write timestamps as reported by the dir command (and also verified via right clicking on the file and selecting properties in Explorer. ------ >>> START runtest.cmd script <<<< @Echo Off echo Create TimeStamp reported by dir command dir /tc %1 echo Last Access TimeStamp reported by dir command dir /ta %1 echo Last Write TimeStamp reported by dir command dir /tw %1 echo Python 2.5.1 timestamp info broke.py %1 ------ >>> END runtest.cmd script <<<< The broke.py script prints out the created, last accessed, last write timestamps as Python sees them. ------ >>> START broke.py script <<<< import sys import os import stat import time file_name = sys.argv[1] file_stats = os.stat(file_name) print print 'File Name : %s' % (file_name) print print 'Creation Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_CTIME])) print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_ATIME])) print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(file_stats[stat.ST_MTIME])) print ------ >>> END broke.py script <<<< # # Test 1 on file broke_test # runtest broke_test Create TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Access TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Last Write TimeStamp reported by dir command 01/02/2003 12:34 PM 0 broke_test Python 2.5.1 timestamp info File Name : broke_test Creation Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Access Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short Last Write Time: 01/02/2003 11:34:56 -- Python results are WRONG hours reported are 1 hour short # # Test 2 on file broke_test2 # runtest broke_test2 Create TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Access TimeStamp reported by dir command 05/31/2007 04:26 PM 3,497,177 broke_test2 Last Write TimeStamp reported by dir command 03/06/2007 05:24 PM 3,497,177 broke_test2 Python 2.5.1 timestamp info File Name : broke_test2 Creation Time: 05/31/2007 16:26:36 -- Python results are correct Last Access Time: 05/31/2007 16:26:38 -- Python results are correct Last Write Time: 03/06/2007 16:24:21 -- Python results are WRONG hours reported are 1 hour short ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-03 10:02 Message: Logged In: YES user_id=21627 Originator: NO As discussed on comp.lang.python, the 1hour difference is just a display issue resulting from daylight-saving time, not an issue with the os.stat result. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-02 11:04 Message: Logged In: YES user_id=21627 Originator: NO I think there are several things going on here, and I believe that Python is behaving correctly. On Win32, there are two ways to find out the time stamps of a file: FindFirstFile reads it from the directory, and GetFileAttributesEx gets it directly from the file (i.e. on NTFS, from the MFT record). When a file is modified, NTFS normally modifies the file only, and updates the directory only occasionally (due to hard links, there might be multiple directories to update also). In particular, the last access time is rarely written back to the directory. You can easily see this for yourself with the following procedure: 1. Inspect the last-access time with dir /ta, or in Explorer. 2. Open the file in an editor, but don't edit it; close the editor. 3. Inspect the last-access time with dir /ta, and with broke.py 4. Wait 10 minutes. 5. Repeat steps 2 and 3. You should see that broke.py will report that the file was accessed, whereas Explorer and dir/ta will report an "old" last-acecssed time. I created a program that displays both the directory-stored and the file-stored last-acecss time (attached). This program may produce outputs such as C:\Pyinst\25\python>..\..\unstop\pa\Debug\pa.exe .svn\entries Last Access according to: FindFirstFile: 128252459235000000 2007-6-2 8:18:43 GetFileAttributesEx: 128252466734062500 2007-6-2 8:31:13 Please refer to http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true There, they explain that the access time (if it is stored at all, which can be turned off) gets updated on disk only if the actual last-access time and the stored last-access time differ by 1 hour. So if you perform steps 2 and 3 above after 1 hour again, you will indeed see that the last access time gets updated in explorer, too. Python 2.4 did use the same (incorrect) source that dir/ta and the explorer uses; Python 2.5 has fixed that bug. So I think we should remove the last-access time from our discussion. File Added: pa.zip ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 07:39 Message: Logged In: YES user_id=33168 Originator: NO Martin, was there a similar problem to this one? I looked in the log for posixmodule.c and didn't see this fixed. ---------------------------------------------------------------------- Comment By: Joe (joesalmeri) Date: 2007-06-01 03:19 Message: Logged In: YES user_id=1235002 Originator: YES More details and a program that demonstrates the problem I created a file and specifically set the created date, last accessed date and last write date to 01/02/2003 12:34:56 After setting the date and time on the file I verified the following: The dir /tc command shows the correct Create date of 01/02/2003 12:34 The dir /ta command shows the correct Access date of 01/02/2003 12:34 The dir /tw command shows the correct Write date of 01/02/2003 12:34 Looking at the properties of the file in Windows Explorer also shows that all 3 dates match. When Python 2.4.2 os.stat is used to get those timestamps all 3 are CORRECT When Python 2.5.1 os.stat is used to get those timestamps all 3 are WRONG and they are off by exact 1 hour 01/02/2003 11:34:56 instead of 01/02/2003 12:34:56 In the case of my above test I know exactly what the timestamp on the file is because I manually set it so that all 3 timestamps are the same. Since Python 2.5.1 does not return the known values for that files timestamps how can it not be a Python 2.5.1 bug? Further testing shows that the results are somewhat inconsistent, many times the create and access date are correct but the Last Write timestamp is wrong. It is generally off by one hour but I have seen situations where it was +1 hour and other situations where it was -1 hour. I even found situations where the python timestamp was 1 minute later. (I know about the 2 second timestamps on FAT, all my filesystems are NTFS). I just found a situation where the python timestamp was 02:51 PM and the windows timestamp was 02:12 PM. DST or timezone changes are not going to make the results be off by 39 minutes? (My timezone is GMT - 5:00). As an additional test I wrote the following Python program which takes a directory name as a paramater. It retrieves all 3 dates for all files in all directories and subdirectories for the specified directory name. First it gets the dates using Python and os.stat, then it runs the dir /tc, dir /ta, and dir /tw commands on the file. Finally it compares the dates and times returned by Python against the dates and times that the Windows dir command is reporting. If you run the program using Python 2.4.2 then ALL dates and times returned by Python 2.4.2 correctly match the dates and times that Windows reports. If you run the program using Python 2.5.1 against the same directory then you get intermittient results. As a quick test I ran it against a directory on my home directory. Python 2.4.2 all dates matched between what the Windows dir command reported and what Python 2.4.2 reported. Python 2.5.1 had the following differences (more than 50% of the time it was wrong) Total Files Processed : 149 Matched All 3 Dates : 70 Did NOT Match All 3 Dates: 79 Matched Create Date : 69 Did NOT Match Create Date: 10 Matched Access Date : 59 Did NOT Match Access Date: 20 Matched Write Date : 11 Did NOT Match Write Date : 68 Here's the source for the check_dates.py program. Run it for youself and see what your results are. import os import stat import sys import time if len(sys.argv) == 1: print print '%s path_to_check' % (sys.argv[0]) print raise SystemExit else: path_to_check = sys.argv[1] file_count = 0 file_match_count = 0 file_no_match_count = 0 create_match_count = 0 create_no_match_count = 0 access_match_count = 0 access_no_match_count = 0 write_match_count = 0 write_no_match_count = 0 for root, dirs, files in os.walk(r'%s' % path_to_check): for file in files: file_count = file_count + 1 file_name = os.path.join(root, file) create_ts_match = False access_ts_match = False write_ts_match = False file_stats = os.stat(file_name) python_create_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_CTIME])) python_access_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_ATIME])) python_write_ts = time.strftime('%m/%d/%Y %I:%M %p', time.localtime(file_stats[stat.ST_MTIME])) win_create_ts = os.popen('dir /a /tc "%s"' % (file_name)).readlines()[5][0:20] win_access_ts = os.popen('dir /a /ta "%s"' % (file_name)).readlines()[5][0:20] win_write_ts = os.popen('dir /a /tw "%s"' % (file_name)).readlines()[5][0:20] if python_create_ts == win_create_ts: create_ts_match = True if python_access_ts == win_access_ts: access_ts_match = True if python_write_ts == win_write_ts: write_ts_match = True if create_ts_match and access_ts_match and write_ts_match: # All timestamps match file_match_count = file_match_count + 1 else: file_no_match_count = file_no_match_count + 1 print print 'File Name : %s' % (file_name) print if create_ts_match: create_match_count = create_match_count + 1 else: create_no_match_count = create_no_match_count + 1 print 'python_create_ts: %s' % (python_create_ts) print 'win_create_ts : %s' % (win_create_ts) print if access_ts_match: access_match_count = access_match_count + 1 else: access_no_match_count = access_no_match_count + 1 print 'python_access_ts: %s' % (python_access_ts) print 'win_access_ts : %s' % (win_access_ts) print if write_ts_match: write_match_count = write_match_count + 1 else: write_no_match_count = write_no_match_count + 1 print 'python_write_ts : %s' % (python_write_ts) print 'win_write_ts : %s' % (win_write_ts) print # # Show Count Results # print 'Total Files Processed : %s' % (file_count) print print 'Matched All 3 Dates : %s' % (file_match_count) print 'Did NOT Match All 3 Dates: %s' % (file_no_match_count) print print 'Matched Create Date : %s' % (create_match_count) print 'Did NOT Match Create Date: %s' % (create_no_match_count) print print 'Matched Access Date : %s' % (access_match_count) print 'Did NOT Match Access Date: %s' % (access_no_match_count) print print 'Matched Write Date : %s' % (write_match_count) print 'Did NOT Match Write Date : %s' % (write_no_match_count) print ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&group_id=5470 From noreply at sourceforge.net Sun Jun 3 19:10:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 10:10:25 -0700 Subject: [ python-Bugs-1730322 ] getattr([], '__eq__')(some-object) is NotImplemented Message-ID: Bugs item #1730322, was opened at 2007-06-03 10:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: getattr([], '__eq__')(some-object) is NotImplemented Initial Comment: Consider: a = [] class B: pass class C(object): pass print a == B() print a == C() m = getattr(a, '__eq__') print m(B()) print m(C()) I think this should print 'False' 4 times, but it actually prints: False False NotImplemented NotImplemented If this isn't a bug, please explain why. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 From noreply at sourceforge.net Sun Jun 3 22:33:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 13:33:11 -0700 Subject: [ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions Message-ID: Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 13:33 Message: Logged In: YES user_id=33168 Originator: NO Seems to be really fixed now. 55457 (2.5) Committed revision 55751. (2.6) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:19 Message: Logged In: YES user_id=33168 Originator: NO File Added: test_get_both.py ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:18 Message: Logged In: YES user_id=33168 Originator: NO Sigh, 4.4.20 and 4.5.20 behave differently. I tested on both, but botched it. :-( It seemed like a good idea to have at least one of the buildbots to use 4.5.20. I upgraded the g4 bot to 4.5.20, since that didn't have any version of bsddb on it. I also installed 4.4.20 on the amd64 buildbot. The x86 gentoo bot probably has 4.1, but it's down right now. Martin's machine has 4.2. Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns an error 22 otherwise). However only 4.4 actually allocates memory. 4.5 doesn't. I checked in revs 55457 (2.5) which should handle this better. Could someone please test and verify I really fixed the problem this time. If it's really fixed, close this bug report. The real change is to conditionally free data if it is a different pointer than we pass in (orig_data). Don't free if they are the same pointer. Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind. File Added: db.c ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-05-19 08:05 Message: Logged In: YES user_id=370230 Originator: YES Just built with latest http://svn.python.org/projects/python/branches/release25-maint pull and problem still remains. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-05-19 08:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 03:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-19 00:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-19 00:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 21:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 20:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-05-18 14:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 14:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1] 17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-18 10:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 From noreply at sourceforge.net Sun Jun 3 22:35:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 13:35:41 -0700 Subject: [ python-Bugs-1730372 ] When Mesa is built with NPTL support, Python extensions link Message-ID: Bugs item #1730372, was opened at 2007-06-03 15: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=1730372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gazi Alankus (alanic7) Assigned to: Nobody/Anonymous (nobody) Summary: When Mesa is built with NPTL support, Python extensions link Initial Comment: When Mesa is built with NPTL support, Python extensions linked to libGL segfault when std::cerr is used. Please see the following thread for descriptions, details and sample programs: http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 From noreply at sourceforge.net Sun Jun 3 22:36:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 13:36:30 -0700 Subject: [ python-Bugs-1730372 ] Mesa with NPTL makes Python extensions crash with std::cerr Message-ID: Bugs item #1730372, was opened at 2007-06-03 15:35 Message generated for change (Settings changed) made by alanic7 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gazi Alankus (alanic7) Assigned to: Nobody/Anonymous (nobody) >Summary: Mesa with NPTL makes Python extensions crash with std::cerr Initial Comment: When Mesa is built with NPTL support, Python extensions linked to libGL segfault when std::cerr is used. Please see the following thread for descriptions, details and sample programs: http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 From noreply at sourceforge.net Sun Jun 3 23:18:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 14:18:33 -0700 Subject: [ python-Bugs-1729929 ] test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Message-ID: Bugs item #1729929, was opened at 2007-06-02 07:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729929&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Initial Comment: Bug fix #1721309 should be rolled into 2.6 tree. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 14:18 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the reminder. I've applied the correct fix this time, the OS X g4 buildbot doesn't display the error message any longer. Committed revision 55751. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729929&group_id=5470 From noreply at sourceforge.net Sun Jun 3 23:27:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 14:27:05 -0700 Subject: [ python-Bugs-1730389 ] strptime bug in time module Message-ID: Bugs item #1730389, was opened at 2007-06-03 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Emma (embirath) Assigned to: Nobody/Anonymous (nobody) Summary: strptime bug in time module Initial Comment: The strptime function takes 2 arguments: (1) a time string (like "2007 Jan 17, 10:00"), and (2) a time format string (like "%Y %b %d, %H:%M") Normally, a ValueError will be raised when the time string does not match the format string. The bug I have found is that NO ValueError is raised in the case below. Instead, and incorrect date is returned (Jan 18th is returned, when really June 29th should be returned). > from time import * > print strptime('2007-180', '%Y-%j %H') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 From noreply at sourceforge.net Sun Jun 3 23:33:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 14:33:55 -0700 Subject: [ python-Bugs-1730389 ] strptime bug in time module Message-ID: Bugs item #1730389, was opened at 2007-06-03 14:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 Please note that this 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 Private: No Submitted By: Emma (embirath) >Assigned to: Brett Cannon (bcannon) Summary: strptime bug in time module Initial Comment: The strptime function takes 2 arguments: (1) a time string (like "2007 Jan 17, 10:00"), and (2) a time format string (like "%Y %b %d, %H:%M") Normally, a ValueError will be raised when the time string does not match the format string. The bug I have found is that NO ValueError is raised in the case below. Instead, and incorrect date is returned (Jan 18th is returned, when really June 29th should be returned). > from time import * > print strptime('2007-180', '%Y-%j %H') ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 14:33 Message: Logged In: YES user_id=33168 Originator: NO Brett, could you take a look? I think this is your code. I verified this on head, but assume 2.5 has the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 From noreply at sourceforge.net Mon Jun 4 00:04:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 15:04:36 -0700 Subject: [ python-Bugs-1730401 ] __cmp__ present in type but not instance?? Message-ID: Bugs item #1730401, was opened at 2007-06-03 15: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=1730401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: __cmp__ present in type but not instance?? Initial Comment: hasattr(list, '__cmp__') is True, but hasattr([], '__cmp__') is False. Doesn't the Python story about instances and classes forbid this!? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 From noreply at sourceforge.net Mon Jun 4 00:17:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 15:17:12 -0700 Subject: [ python-Bugs-1730372 ] Mesa with NPTL makes Python extensions crash with std::cerr Message-ID: Bugs item #1730372, was opened at 2007-06-03 13:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 Please note that this 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: Works For Me Priority: 5 Private: No Submitted By: Gazi Alankus (alanic7) Assigned to: Nobody/Anonymous (nobody) Summary: Mesa with NPTL makes Python extensions crash with std::cerr Initial Comment: When Mesa is built with NPTL support, Python extensions linked to libGL segfault when std::cerr is used. Please see the following thread for descriptions, details and sample programs: http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 15:17 Message: Logged In: YES user_id=33168 Originator: NO I can't reproduce this error on head with Ubuntu Linux/amd64 gcc 4.1.2. What are the platform details? OS, compiler, etc. $ gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -I/usr/include -I/usr/local/include -I./Include -I. -c ../spam.cc -o spam.o $ gcc -pthread -shared spam.o -L/usr/lib64 -L/usr/local/lib -Wl,-R/usr/lib64 -ldb-4.4 -o build/lib.linux-x86_64-2.6/spam.so -lstdc++ $ ./python >>> import spam >>> spam.system('ls') this be cerr big5.py __db.003 libpython2.6.a Objects python-clean build __db.004 LICENSE Parser python-fast config.log __db.005 log.0000000001 PC README config.status Demo Mac PCbuild RISCOS config.status.lineno Doc Makefile PCbuild8 setup.py configure Grammar Makefile.pre pyconfig.h Tools configure.in Include Makefile.pre.in pyconfig.h.in __db.001 install-sh Misc python __db.002 Lib Modules Python 0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 From noreply at sourceforge.net Mon Jun 4 00:19:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 15:19:27 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 07:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 15:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 07:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Mon Jun 4 00:43:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 15:43:46 -0700 Subject: [ python-Bugs-1730389 ] strptime bug in time module Message-ID: Bugs item #1730389, was opened at 2007-06-03 14:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Private: No Submitted By: Emma (embirath) Assigned to: Brett Cannon (bcannon) Summary: strptime bug in time module Initial Comment: The strptime function takes 2 arguments: (1) a time string (like "2007 Jan 17, 10:00"), and (2) a time format string (like "%Y %b %d, %H:%M") Normally, a ValueError will be raised when the time string does not match the format string. The bug I have found is that NO ValueError is raised in the case below. Instead, and incorrect date is returned (Jan 18th is returned, when really June 29th should be returned). > from time import * > print strptime('2007-180', '%Y-%j %H') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-06-03 15:43 Message: Logged In: YES user_id=357491 Originator: NO Found the problem. The regex being compiled is using ``\s*`` for the space separator. So when you match against '2007-180' it is matching %Y fine, but it matches %j to 18 and %H to 0 in order to make the regex match. Changing the regex creation algorithm to use ``\s+`` solved the problem. I am running the test suite now to make sure this doesn't break anything. Once its done (assuming it passes) I will commit and backport to 2.5. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 14:33 Message: Logged In: YES user_id=33168 Originator: NO Brett, could you take a look? I think this is your code. I verified this on head, but assume 2.5 has the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 From noreply at sourceforge.net Mon Jun 4 00:51:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 15:51:51 -0700 Subject: [ python-Bugs-1730401 ] __cmp__ present in type but not instance?? Message-ID: Bugs item #1730401, was opened at 2007-06-03 15:04 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: __cmp__ present in type but not instance?? Initial Comment: hasattr(list, '__cmp__') is True, but hasattr([], '__cmp__') is False. Doesn't the Python story about instances and classes forbid this!? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-06-03 15:51 Message: Logged In: YES user_id=357491 Originator: NO Do a dir() on list and on [] and you will notice that __cmp__ doesn't show up. The __cmp__ you are seeing is the type instance method of list as received from being a subclass of 'type'. It's more obvious if you print out list.__cmp__ and type.__cmp__. So it does make sense when viewed from the point-of-view of metaclasses; list is an instance of type and you are seeing a metaclass instance method on list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 From noreply at sourceforge.net Mon Jun 4 02:14:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 17:14:20 -0700 Subject: [ python-Bugs-1730389 ] strptime bug in time module Message-ID: Bugs item #1730389, was opened at 2007-06-03 14:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 Please note that this 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 Private: No Submitted By: Emma (embirath) Assigned to: Brett Cannon (bcannon) Summary: strptime bug in time module Initial Comment: The strptime function takes 2 arguments: (1) a time string (like "2007 Jan 17, 10:00"), and (2) a time format string (like "%Y %b %d, %H:%M") Normally, a ValueError will be raised when the time string does not match the format string. The bug I have found is that NO ValueError is raised in the case below. Instead, and incorrect date is returned (Jan 18th is returned, when really June 29th should be returned). > from time import * > print strptime('2007-180', '%Y-%j %H') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-06-03 17:14 Message: Logged In: YES user_id=357491 Originator: NO Committed in r55752 on the trunk and r55753 in 2.5. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-03 15:43 Message: Logged In: YES user_id=357491 Originator: NO Found the problem. The regex being compiled is using ``\s*`` for the space separator. So when you match against '2007-180' it is matching %Y fine, but it matches %j to 18 and %H to 0 in order to make the regex match. Changing the regex creation algorithm to use ``\s+`` solved the problem. I am running the test suite now to make sure this doesn't break anything. Once its done (assuming it passes) I will commit and backport to 2.5. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 14:33 Message: Logged In: YES user_id=33168 Originator: NO Brett, could you take a look? I think this is your code. I verified this on head, but assume 2.5 has the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470 From noreply at sourceforge.net Mon Jun 4 03:17:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 18:17:03 -0700 Subject: [ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn Message-ID: Bugs item #1730441, was opened at 2007-06-04 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=1730441&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 From noreply at sourceforge.net Mon Jun 4 03:17:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 18:17:41 -0700 Subject: [ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn Message-ID: Bugs item #1730441, was opened at 2007-06-04 01:17 Message generated for change (Settings changed) made by nifan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None >Priority: 3 Private: No Submitted By: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 From noreply at sourceforge.net Mon Jun 4 05:59:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 20:59:53 -0700 Subject: [ python-Bugs-1730480 ] dict constructor accesses internal items of dict derivative Message-ID: Bugs item #1730480, was opened at 2007-06-03 20: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=1730480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: dict constructor accesses internal items of dict derivative Initial Comment: >>> class MyDict(dict): ... def keys(self): print "keys" ... def __getitem__(self, n): print "__getitem__" ... >>> myDict = MyDict(a=1, b=2) >>> dict(myDict) {'a': 1, 'b': 2} PyDict_Merge accesses the items of the dict to be merged directly rather than going through the interface for any dict instance--even a dict derivative--by virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic needs to be: if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys: ...okay to access items directly... else: ...go through the methods... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470 From noreply at sourceforge.net Mon Jun 4 06:00:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 21:00:58 -0700 Subject: [ python-Bugs-1730480 ] dict init/update accesses internal items of dict derivative Message-ID: Bugs item #1730480, was opened at 2007-06-03 20:59 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) >Summary: dict init/update accesses internal items of dict derivative Initial Comment: >>> class MyDict(dict): ... def keys(self): print "keys" ... def __getitem__(self, n): print "__getitem__" ... >>> myDict = MyDict(a=1, b=2) >>> dict(myDict) {'a': 1, 'b': 2} PyDict_Merge accesses the items of the dict to be merged directly rather than going through the interface for any dict instance--even a dict derivative--by virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic needs to be: if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys: ...okay to access items directly... else: ...go through the methods... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470 From noreply at sourceforge.net Mon Jun 4 07:59:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 22:59:53 -0700 Subject: [ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn Message-ID: Bugs item #1730441, was opened at 2007-06-03 18:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 3 Private: No Submitted By: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. Can you test the attached patch? The semantics for try/except have changed and this code doesn't look like it was updated. File Added: os-execvpe.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 From noreply at sourceforge.net Mon Jun 4 08:24:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 23:24:38 -0700 Subject: [ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn Message-ID: Bugs item #1730441, was opened at 2007-06-03 18:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: nifan (nifan) >Assigned to: Neal Norwitz (nnorwitz) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 23:24 Message: Logged In: YES user_id=33168 Originator: NO Nevermind. I see in the link you have a test and can reproduce the problem. Committed revision 55754. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. Can you test the attached patch? The semantics for try/except have changed and this code doesn't look like it was updated. File Added: os-execvpe.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 From noreply at sourceforge.net Mon Jun 4 11:46:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 02:46:24 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-01 23:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Mon Jun 4 21:41:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 12:41:15 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-05-31 19:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-06-04 12:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 02:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-01 16:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Mon Jun 4 21:58:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 12:58:26 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 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=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Mon Jun 4 23:30:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 14:30:05 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-05-31 19:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-06-04 14:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 12:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 12:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 02:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-01 16:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:21:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:21:02 -0700 Subject: [ python-Bugs-1731068 ] Importing a submodule after unloading its parent Message-ID: Bugs item #1731068, was opened at 2007-06-04 16: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=1731068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: Importing a submodule after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:21:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:21:18 -0700 Subject: [ python-Bugs-1731068 ] Importing a submodule fails after unloading its parent Message-ID: Bugs item #1731068, was opened at 2007-06-04 16:21 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) >Summary: Importing a submodule fails after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:40:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:40:28 -0700 Subject: [ python-Bugs-1731068 ] Importing a submodule fails after unloading its parent Message-ID: Bugs item #1731068, was opened at 2007-06-04 16:21 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: Importing a submodule fails after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:40:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:40:50 -0700 Subject: [ python-Bugs-1730480 ] dict init/update accesses internal items of dict derivative Message-ID: Bugs item #1730480, was opened at 2007-06-03 20:59 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: dict init/update accesses internal items of dict derivative Initial Comment: >>> class MyDict(dict): ... def keys(self): print "keys" ... def __getitem__(self, n): print "__getitem__" ... >>> myDict = MyDict(a=1, b=2) >>> dict(myDict) {'a': 1, 'b': 2} PyDict_Merge accesses the items of the dict to be merged directly rather than going through the interface for any dict instance--even a dict derivative--by virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic needs to be: if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys: ...okay to access items directly... else: ...go through the methods... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470 From noreply at sourceforge.net Tue Jun 5 09:50:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 00:50:06 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 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=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 09:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 23:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Tue Jun 5 12:52:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 03:52:26 -0700 Subject: [ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object Message-ID: Bugs item #1729014, was opened at 2007-05-31 15:27 Message generated for change (Comment added) made by swfiua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. ---------------------------------------------------------------------- >Comment By: Johnnyg (swfiua) Date: 2007-06-05 10:52 Message: Logged In: YES user_id=1529783 Originator: YES I'm happy to flag this as undefined behaviour. I have worked around it in my code, the only issue is that the code is brittle, since I think it relies on the scope of constants -- I'm guessing that is what has changed between 2.4 and 2.5 and could well change in the future. John ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 05:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 From noreply at sourceforge.net Tue Jun 5 14:18:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 05:18:47 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-06-05 12:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 07:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 19:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 19:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-01 23:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Tue Jun 5 16:07:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 07:07:52 -0700 Subject: [ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object Message-ID: Bugs item #1729014, was opened at 2007-05-31 15:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=849994 Originator: NO See also patch #1678668. ---------------------------------------------------------------------- Comment By: Johnnyg (swfiua) Date: 2007-06-05 10:52 Message: Logged In: YES user_id=1529783 Originator: YES I'm happy to flag this as undefined behaviour. I have worked around it in my code, the only issue is that the code is brittle, since I think it relies on the scope of constants -- I'm guessing that is what has changed between 2.4 and 2.5 and could well change in the future. John ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 05:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 From noreply at sourceforge.net Tue Jun 5 19:23:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 10:23:54 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 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=1729277&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 19:23 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me, please apply. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-05 14:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 09:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 23:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Tue Jun 5 19:47:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 10:47:51 -0700 Subject: [ python-Bugs-1715581 ] Const(None) in compiler.ast.Return.value Message-ID: Bugs item #1715581, was opened at 2007-05-09 05:53 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715581&group_id=5470 Please note that this 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 Private: No Submitted By: Ali Gholami Rudi (aligrudi) >Assigned to: Collin Winter (collinwinter) Summary: Const(None) in compiler.ast.Return.value Initial Comment: The problem happens when:: import compiler class Visitor(object): def visitReturn(self, node): print node.value source = """ def f(): return """ compiler.walk(compiler.parse(source), Visitor()) I think the value of `node.value` should have been `None` instead of `Const(None)` as it is for most other nodes when an optional part is missing. The same problem (getting `Const(None)` instead of `None`) exists for `Sliceobj.nodes[i]` and `Discard.expr`. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:47 Message: Logged In: YES user_id=1344176 Originator: NO "return" is syntactic shorthand for "return None", so Const(None) is the right value; same thing for Sliceobj. This isn't a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1715581&group_id=5470 From noreply at sourceforge.net Tue Jun 5 19:56:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 10:56:07 -0700 Subject: [ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces Message-ID: Bugs item #1711608, was opened at 2007-05-02 20:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-08 15:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:00:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:00:12 -0700 Subject: [ python-Bugs-994023 ] threads duplicated on fork() prevent child from terminating Message-ID: Bugs item #994023, was opened at 2004-07-19 20:59 Message generated for change (Comment added) made by imbaczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470 Please note that this 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: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Nobody/Anonymous (nobody) Summary: threads duplicated on fork() prevent child from terminating Initial Comment: (This is a repost from an older c.l.py submission to prevent losing track of it) It looks as if fork() duplicates the entire threads info structure in the new process. This causes child processes to attempt to handle or wait for nonexistent threads and causes them to hang on exit. Perhaps clearing Python's internal thread info after the fork() is all that is needed to fix this (the fact that the threads themselves are not duplicated seems to suggest that this was indeed the intention - and also is POSIXly correct). Original post with sample code for the problem is here (also attached for your convenience): http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=e0bf36b5.0306191548.73b7383%40posting.google.com The "bug" manifests itself by the program not exiting voluntarily. The two processes created need to be terminated individually. Last tested on 2.3.3 (Fedora Core 2), but present since 2.1 I believe. ---------------------------------------------------------------------- Comment By: Marek Baczynski (imbaczek) Date: 2007-06-05 20:00 Message: Logged In: YES user_id=838849 Originator: NO Just ran into this in 2.5 on debian testing. Workaround is to setDaemon(True) on the offending threads; this is not documented anywhere, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:23:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:23:09 -0700 Subject: [ python-Bugs-1730322 ] getattr([], '__eq__')(some-object) is NotImplemented Message-ID: Bugs item #1730322, was opened at 2007-06-03 13:10 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: getattr([], '__eq__')(some-object) is NotImplemented Initial Comment: Consider: a = [] class B: pass class C(object): pass print a == B() print a == C() m = getattr(a, '__eq__') print m(B()) print m(C()) I think this should print 'False' 4 times, but it actually prints: False False NotImplemented NotImplemented If this isn't a bug, please explain why. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:23 Message: Logged In: YES user_id=1344176 Originator: NO This isn't a bug because a.__eq__() isn't the whole story on equivalence testing. NotImplemented is a perfectly valid return value for a comparison method; in this case, it signals the == operator to try a different approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:26:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:26:25 -0700 Subject: [ python-Bugs-1713252 ] character set in Japanese on Ubuntu distribution Message-ID: Bugs item #1713252, was opened at 2007-05-05 01:16 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 Please note that this 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 Private: No Submitted By: Christopher Grell (cgrell) Assigned to: Nobody/Anonymous (nobody) Summary: character set in Japanese on Ubuntu distribution Initial Comment: I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:26 Message: Logged In: YES user_id=1344176 Originator: NO Please post a legible screenshot. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-10 18:35 Message: Logged In: YES user_id=21627 Originator: NO Why do you think it is Japanese? It is fairly unreadable, but it looks like Latin to me. In particular, I can recognize the text "Personal firewall software may warn..." ---------------------------------------------------------------------- Comment By: Christopher Grell (cgrell) Date: 2007-05-10 16:11 Message: Logged In: YES user_id=1785859 Originator: YES File Added: Screenshot-Python Shell.png ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-08 15:05 Message: Logged In: YES user_id=21627 Originator: NO What do you mean by "opens with Japanese character set"? Can you provide a screenshot? Can you figure out what font it is using? ---------------------------------------------------------------------- Comment By: Christopher Grell (cgrell) Date: 2007-05-06 22:42 Message: Logged In: YES user_id=1785859 Originator: YES Changing default character size to 20 removes the issue ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-05 03:08 Message: Logged In: YES user_id=849994 Originator: NO As this is certainly not the case in other distributions, this is something you should file with the Ubuntu bug tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:32:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:32:25 -0700 Subject: [ python-Bugs-1712742 ] pprint handles depth argument incorrectly Message-ID: Bugs item #1712742, was opened at 2007-05-04 09:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitrii Tisnek (dimaq) >Assigned to: Neal Norwitz (nnorwitz) Summary: pprint handles depth argument incorrectly Initial Comment: pprint.pprint( [[[[[ ]]]]], depth=0) AssertionError: depth must be > 0 pprint.pprint( [[[[[ ]]]]], depth=0.5) [[...]] pprint.pprint( [[[[[ ]]]]], depth=1) [[[...]]] I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:32 Message: Logged In: YES user_id=1344176 Originator: NO The correct patch number is 1713041. Neal, assigning to you so you can close this at the same time as the patch. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:17 Message: Logged In: YES user_id=984087 Originator: NO I created patch 1712742 to fix this. BTW, I think that a depth of 1 should mean the top level object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:35:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:35:11 -0700 Subject: [ python-Bugs-1719423 ] Python package support not properly documented Message-ID: Bugs item #1719423, was opened at 2007-05-15 12:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 Please note that this 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 Private: No Submitted By: Michael Abbott (araneidae) Assigned to: Nobody/Anonymous (nobody) Summary: Python package support not properly documented Initial Comment: I can sum this report up most simply by quoting the message below: http://mail.python.org/pipermail/python-list/2001-October/107699.html Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current! (The chapter on "import" is now section 6.12: nothing else has changed.) The comment below that "presum[ably] nothing significant has changed" seems less than probable now! I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute? not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time. Body of original message follows Package support in Python 2 Michael Abbott michael at rcp.co.uk Wed Oct 3 10:58:08 CEST 2001 Is there up to date documentation for package support in Python 2? Section 6.11 of the "Python Reference Manual" has the following nice quote: [XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] and the referred URL documents Python 1.5. I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation! ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:35 Message: Logged In: YES user_id=1344176 Originator: NO Hi Michael, would you be interested in working on a docs patch for this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-15 16:41 Message: Logged In: YES user_id=849994 Originator: NO You are certainly right that this should be documented properly. BTW, after you import x.y, y is an attribute of module x. When you write "x.y.foo", Python knows nothing about modules any more, it just handles attribute access of arbitrary objects which happen to be modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:36:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:36:55 -0700 Subject: [ python-Bugs-1714451 ] subprocess.py problems errors when calling cmd.exe Message-ID: Bugs item #1714451, was opened at 2007-05-07 13:13 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: tzellman (tzellman) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py problems errors when calling cmd.exe Initial Comment: An example: >>> import subprocess >>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"', shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE) 'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or external command, operable program or batch file. This normally works from the cmd.exe prompt, so the command line is being passed incorrectly in the subprocess module. My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe), and add include directories that have spaces in the name. For example: "C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3 /nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault /I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj The fix for this problem is to modify line 765 in subprocess.py, replacing it with: args = comspec + " /s /c \"%s\"" % args.replace('""', '"') The /s tells cmd.exe not to re-format the command line. We then encase the entire command line in double quotes. I also replace occurrences of "" with " in the arg string, in case the user already encased the command in double quotes. With this fix, the commands execute correctly. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:36 Message: Logged In: YES user_id=1344176 Originator: NO tzellman, could you work up a real patch and a test case for this? Thanks. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-07 17:06 Message: Logged In: YES user_id=479790 Originator: NO Use a list of arguments instead, and please remember to use raw strings or double backslashes: proc = subprocess.Popen([r"c:\Windows\system\ping.exe","localhost"], shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE) ---------------------------------------------------------------------- Comment By: tzellman (tzellman) Date: 2007-05-07 13:20 Message: Logged In: YES user_id=1090960 Originator: YES This could likely be rejected. I realize a solution to this w/o modifying the Python source is to encase the expression yourself in double quotes. So, the example given would look like: >>> import subprocess >>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""', shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE) And that will work. Sorry for any confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:43:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:43:44 -0700 Subject: [ python-Bugs-1704287 ] must run "make" before "make install" Message-ID: Bugs item #1704287, was opened at 2007-04-20 09:01 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: must run "make" before "make install" Initial Comment: "make install" fails unless you've already run "make". Not a show-stopper, but specifying the correct dependencies for "make install" would force everything to be built before it was installed. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:43 Message: Logged In: YES user_id=1344176 Originator: NO What do you mean by "fails"? What platform are you using? What version of make are you using? I'm unable to reproduce this on Ubuntu Dapper Drake (using GNU Make 3.81beta4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 From noreply at sourceforge.net Tue Jun 5 21:12:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 12:12:43 -0700 Subject: [ python-Bugs-1712742 ] pprint handles depth argument incorrectly Message-ID: Bugs item #1712742, was opened at 2007-05-04 09:47 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitrii Tisnek (dimaq) Assigned to: Neal Norwitz (nnorwitz) Summary: pprint handles depth argument incorrectly Initial Comment: pprint.pprint( [[[[[ ]]]]], depth=0) AssertionError: depth must be > 0 pprint.pprint( [[[[[ ]]]]], depth=0.5) [[...]] pprint.pprint( [[[[[ ]]]]], depth=1) [[[...]]] I would like to see the root (that is [...]) with depth=0 (or depth=1 if you insist), either way, [[[...]]] for depth=1 is incorrect. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-06-05 15:12 Message: Logged In: YES user_id=984087 Originator: NO Of course. Thanks for the correction. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 14:32 Message: Logged In: YES user_id=1344176 Originator: NO The correct patch number is 1713041. Neal, assigning to you so you can close this at the same time as the patch. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:17 Message: Logged In: YES user_id=984087 Originator: NO I created patch 1712742 to fix this. BTW, I think that a depth of 1 should mean the top level object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712742&group_id=5470 From noreply at sourceforge.net Tue Jun 5 21:31:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 12:31:08 -0700 Subject: [ python-Bugs-1728403 ] reading from malformed big5 document hangs cpython Message-ID: Bugs item #1728403, was opened at 2007-05-31 00:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470 Please note that this 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: 7 Private: No Submitted By: tsuraan (tsuraan3) Assigned to: Hye-Shik Chang (perky) Summary: reading from malformed big5 document hangs cpython Initial Comment: Python enters some sort of infinite loop when attempting to read data from a malformed file that is big5 encoded (using the codecs library). This behaviour can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 . A really simple example illustrating the bug follows: Python 2.4.4 (#1, May 15 2007, 13:33:55) [GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> fname='out' >>> outfd=open(fname,'w') >>> outfd.write(chr(243)) >>> outfd.close() >>> >>> infd= codecs.open(fname, encoding='big5') >>> infd.read(1024) And then, it hangs forever. If I instead use the following code: Python 2.5 (r25:51908, Jan 8 2007, 19:09:28) [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs, signal >>> fname='out' >>> def handler(*args): ... raise Exception("boo!") ... >>> signal.signal(signal.SIGALRM, handler) 0 >>> outfd=open(fname, 'w') >>> outfd.write (chr(243)) >>> outfd.close() >>> >>> infd=codecs.open(fname, encoding='big5') >>> signal.alarm(5) 0 >>> infd.read(1024) The program still hangs forever. The program can be made to crash if I don't install a signal handler at all, but that's pretty lame. It looks like the entire interpreter is being locked up by this read, so I don't think there's likely to be a pure-python workaround, but I thought it would be a good but to have out there so a future version of python can (hopefully) fix this. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-06-06 04:31 Message: Logged In: YES user_id=55188 Originator: NO Thank you for the reporting, tsuraan, and thank you for the investigation, Neal. The bug is related to a logic that detects whether file reached end of file. I verified that any other part of CJKCodecs has such a logic. Fixed and committed in SVN. trunk 55770, release25-maint 55774, release24-maint 55772. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 13:51 Message: Logged In: YES user_id=33168 Originator: NO Bumping the priority since this is about as bad as a crash. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 13:49 Message: Logged In: YES user_id=33168 Originator: NO Hye-Shik, could you take a look at this. There's an infinite loop in Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread(). rsize == 1 each iteration. I don't know if there are more places that might have this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470 From noreply at sourceforge.net Tue Jun 5 21:34:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 12:34:17 -0700 Subject: [ python-Bugs-1728403 ] reading from malformed big5 document hangs cpython Message-ID: Bugs item #1728403, was opened at 2007-05-31 00:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470 Please note that this 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: 7 Private: No Submitted By: tsuraan (tsuraan3) Assigned to: Hye-Shik Chang (perky) Summary: reading from malformed big5 document hangs cpython Initial Comment: Python enters some sort of infinite loop when attempting to read data from a malformed file that is big5 encoded (using the codecs library). This behaviour can be observed under Linux and FreeBSD, using Python 2.4 and 2.5 . A really simple example illustrating the bug follows: Python 2.4.4 (#1, May 15 2007, 13:33:55) [GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> fname='out' >>> outfd=open(fname,'w') >>> outfd.write(chr(243)) >>> outfd.close() >>> >>> infd= codecs.open(fname, encoding='big5') >>> infd.read(1024) And then, it hangs forever. If I instead use the following code: Python 2.5 (r25:51908, Jan 8 2007, 19:09:28) [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs, signal >>> fname='out' >>> def handler(*args): ... raise Exception("boo!") ... >>> signal.signal(signal.SIGALRM, handler) 0 >>> outfd=open(fname, 'w') >>> outfd.write (chr(243)) >>> outfd.close() >>> >>> infd=codecs.open(fname, encoding='big5') >>> signal.alarm(5) 0 >>> infd.read(1024) The program still hangs forever. The program can be made to crash if I don't install a signal handler at all, but that's pretty lame. It looks like the entire interpreter is being locked up by this read, so I don't think there's likely to be a pure-python workaround, but I thought it would be a good but to have out there so a future version of python can (hopefully) fix this. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-06-06 04:34 Message: Logged In: YES user_id=55188 Originator: NO in my comment: > The bug is related to a logic that detects whether file reached end of file. I verified that any other part of CJKCodecs has such a logic. I meant "no part". sorry. :) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-06-06 04:31 Message: Logged In: YES user_id=55188 Originator: NO Thank you for the reporting, tsuraan, and thank you for the investigation, Neal. The bug is related to a logic that detects whether file reached end of file. I verified that any other part of CJKCodecs has such a logic. Fixed and committed in SVN. trunk 55770, release25-maint 55774, release24-maint 55772. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 13:51 Message: Logged In: YES user_id=33168 Originator: NO Bumping the priority since this is about as bad as a crash. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 13:49 Message: Logged In: YES user_id=33168 Originator: NO Hye-Shik, could you take a look at this. There's an infinite loop in Modules/cjkcodecs/multibytecodec.c mbstreamreader_iread(). rsize == 1 each iteration. I don't know if there are more places that might have this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1728403&group_id=5470 From noreply at sourceforge.net Tue Jun 5 23:46:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 14:46:41 -0700 Subject: [ python-Bugs-1719423 ] Python package support not properly documented Message-ID: Bugs item #1719423, was opened at 2007-05-15 17:39 Message generated for change (Comment added) made by araneidae You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 Please note that this 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 Private: No Submitted By: Michael Abbott (araneidae) Assigned to: Nobody/Anonymous (nobody) Summary: Python package support not properly documented Initial Comment: I can sum this report up most simply by quoting the message below: http://mail.python.org/pipermail/python-list/2001-October/107699.html Note that this message was posted 5 1/2 years ago (by myself, as it happens), had no follow up, and the problem referred to remains current! (The chapter on "import" is now section 6.12: nothing else has changed.) The comment below that "presum[ably] nothing significant has changed" seems less than probable now! I was looking to understand modules and packages a bit better: they don't behave like proper first class objects (is module.sub_module an attribute? not really), and so the lack of definitive documentation in this area is sad, particularly after such a long time. Body of original message follows Package support in Python 2 Michael Abbott michael at rcp.co.uk Wed Oct 3 10:58:08 CEST 2001 Is there up to date documentation for package support in Python 2? Section 6.11 of the "Python Reference Manual" has the following nice quote: [XXX Can't be bothered to spell this out right now; see the URL http://www.python.org/doc/essays/packages.html for more details, also about how the module search works from inside a package.] and the referred URL documents Python 1.5. I presume that nothing significant has changed recently, but it's certainly disconcerting for something as fundamental as module importing to not actually be part of the core language documentation! ---------------------------------------------------------------------- >Comment By: Michael Abbott (araneidae) Date: 2007-06-05 22:46 Message: Logged In: YES user_id=250634 Originator: YES Hi Collin, Well, that's not a terrible idea. I'll take a look and follow up later. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:35 Message: Logged In: YES user_id=1344176 Originator: NO Hi Michael, would you be interested in working on a docs patch for this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-15 21:41 Message: Logged In: YES user_id=849994 Originator: NO You are certainly right that this should be documented properly. BTW, after you import x.y, y is an attribute of module x. When you write "x.y.foo", Python knows nothing about modules any more, it just handles attribute access of arbitrary objects which happen to be modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1719423&group_id=5470 From noreply at sourceforge.net Tue Jun 5 23:47:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 14:47:50 -0700 Subject: [ python-Bugs-1731706 ] tkinter memory leak problem Message-ID: Bugs item #1731706, was opened at 2007-06-05 15: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=1731706&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Hancock (robhancock) Assigned to: Martin v. L?wis (loewis) Summary: tkinter memory leak problem Initial Comment: We have a Python application which displays a GUI using Tkinter and Pmw. We have seen that over time the memory usage of the app seems to continuously increase and eventually use up all of the system's RAM. I ran the app under Valgrind, and this leak seems to account for most of the memory that it detects as being leaked: ==31141== 2,630,208 (806,400 direct, 1,823,808 indirect) bytes in 21 blocks are definitely lost in loss record 156 of 159 ==31141== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31141== by 0x368268844A: TclThreadAllocObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682686BA0: Tcl_NewStringObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3B258: AsObj (_tkinter.c:902) ==31141== by 0x8B3BB1C: Tkapp_CallArgs (_tkinter.c:1149) ==31141== by 0x8B3BD67: Tkapp_CallProc (_tkinter.c:1224) ==31141== by 0x36826786D4: Tcl_ServiceEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682678A20: Tcl_DoOneEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3F55B: Tkapp_MainLoop (_tkinter.c:2532) ==31141== by 0x36900949D9: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x369009405E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690094485: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095951: PyEval_EvalCode (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B1EA8: (within /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B3357: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B979C: Py_Main (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x368161D8A3: (below main) (in /lib64/libc-2.5.so) Looking at the code in _tkinter.c, I am not sure how the Tkapp_CallDeallocArgs function is supposed to get called in the case where we push the request onto the Tcl interpreter thread in Tkapp_Call. That call is what would presumably release this allocated memory. This is using Python 2.4.3 and tcl/tk 8.4.13. Looking at Python SVN, there does not seem to be any relevant code changes in _tkinter.c in later versions.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731706&group_id=5470 From noreply at sourceforge.net Tue Jun 5 23:55:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 14:55:08 -0700 Subject: [ python-Bugs-1704287 ] must run "make" before "make install" Message-ID: Bugs item #1704287, was opened at 2007-04-20 07:01 Message generated for change (Comment added) made by vanandel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: must run "make" before "make install" Initial Comment: "make install" fails unless you've already run "make". Not a show-stopper, but specifying the correct dependencies for "make install" would force everything to be built before it was installed. ---------------------------------------------------------------------- >Comment By: Joseph VanAndel (vanandel) Date: 2007-06-05 15:55 Message: Logged In: YES user_id=6581 Originator: YES With CentOS 5 (clone of Redhat Enterprise 5), if you run "make install" before running "make", the make stops with the error: Compiling /opt/local/lib/python2.5/xml/sax/saxutils.py ... Compiling /opt/local/lib/python2.5/xml/sax/xmlreader.py ... Compiling /opt/local/lib/python2.5/xmllib.py ... Compiling /opt/local/lib/python2.5/xmlrpclib.py ... Compiling /opt/local/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 make version is 3.81 ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 12:43 Message: Logged In: YES user_id=1344176 Originator: NO What do you mean by "fails"? What platform are you using? What version of make are you using? I'm unable to reproduce this on Ubuntu Dapper Drake (using GNU Make 3.81beta4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704287&group_id=5470 From noreply at sourceforge.net Wed Jun 6 00:19:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 15:19:54 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-05 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=1731717&group_id=5470 Please note that this 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 Private: No Submitted By: dsagal (dsagal) Assigned to: Nobody/Anonymous (nobody) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: 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 "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:28:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:28:49 -0700 Subject: [ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces Message-ID: Bugs item #1711608, was opened at 2007-05-03 10:34 Message generated for change (Comment added) made by stevecassidy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve ---------------------------------------------------------------------- >Comment By: Steve Cassidy (stevecassidy) Date: 2007-06-06 09:28 Message: Logged In: YES user_id=105411 Originator: YES I understand that the default install location is non-standard becuase Python has trouble at times with spaces in filenames. However, if this is an engineering decision is there a trace of the bugs that are avoided because of it? The user isn't warned on installation not to choose a location with spaces to avoid problems x y and z. A regular windows user will find it odd that Python wants to be installed in C:\Python and I would imagine that in many managed environments this won't be possible. So the response to this bug shouldn't be just to close it, maybe it needs a patch to warn people of the issue when installing python at the least. In the longer term though it seems really odd that Python can't solve this relatively simple problem that other envionments have no trouble with. Steve ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-06 03:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-09 05:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:37:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:37:32 -0700 Subject: [ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces Message-ID: Bugs item #1711608, was opened at 2007-05-02 20:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:37 Message: Logged In: YES user_id=1344176 Originator: NO I did not close this bug because it's unimportant; I closed it because it's already on file (#1436206), and there's no sense in having multiple tracker entries for the same issue. That said, problems on Windows are less likely to get fixed or noticed because relatively few core developers have access to Windows platforms. We would greatly appreciate a patch that fixes this. ---------------------------------------------------------------------- Comment By: Steve Cassidy (stevecassidy) Date: 2007-06-05 19:28 Message: Logged In: YES user_id=105411 Originator: YES I understand that the default install location is non-standard becuase Python has trouble at times with spaces in filenames. However, if this is an engineering decision is there a trace of the bugs that are avoided because of it? The user isn't warned on installation not to choose a location with spaces to avoid problems x y and z. A regular windows user will find it odd that Python wants to be installed in C:\Python and I would imagine that in many managed environments this won't be possible. So the response to this bug shouldn't be just to close it, maybe it needs a patch to warn people of the issue when installing python at the least. In the longer term though it seems really odd that Python can't solve this relatively simple problem that other envionments have no trouble with. Steve ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 13:56 Message: Logged In: YES user_id=1344176 Originator: NO This issue is a duplicate of #1436206. Closing. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-08 15:11 Message: Logged In: YES user_id=21627 Originator: NO I don't find it odd that the bug persisted for so long: there is a reason that the default installation of Python does *not* go into "Program Files", as spaces in file names produce endless problems. Quoting the paths should work, though - don't forget to quote arguments as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:39:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:39:44 -0700 Subject: [ python-Bugs-1712522 ] urllib.quote throws exception on Unicode URL Message-ID: Bugs item #1712522, was opened at 2007-05-04 02:11 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote throws exception on Unicode URL Initial Comment: The code in urllib.quote fails on Unicode input, when called by robotparser with a Unicode URL. Traceback (most recent call last): File "./sitetruth/InfoSitePage.py", line 415, in run pagetree = self.httpfetch() # fetch page File "./sitetruth/InfoSitePage.py", line 368, in httpfetch if not self.owner().checkrobotaccess(self.requestedurl) : # if access disallowed by robots.txt file File "./sitetruth/InfoSiteContent.py", line 446, in checkrobotaccess return(self.robotcheck.can_fetch(config.kuseragent, url)) # return can fetch File "/usr/local/lib/python2.5/robotparser.py", line 159, in can_fetch url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/" File "/usr/local/lib/python2.5/urllib.py", line 1197, in quote res = map(safe_map.__getitem__, s) KeyError: u'\xe2' That bit of code needs some attention. - It still assumes ASCII goes up to 255, which hasn't been true in Python for a while now. - The initialization may not be thread-safe; a table is being initialized on first use. "robotparser" was trying to check if a URL with a Unicode character in it was allowed. Note the "KeyError: u'\xe2'" ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:39 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly provide a patch to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:40:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:40:45 -0700 Subject: [ python-Bugs-1711800 ] SequenceMatcher bug with insert/delete block after "replace" Message-ID: Bugs item #1711800, was opened at 2007-05-03 06:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711800&group_id=5470 Please note that this 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 Private: No Submitted By: Christian Hammond (chipx86) Assigned to: Nobody/Anonymous (nobody) Summary: SequenceMatcher bug with insert/delete block after "replace" Initial Comment: difflib.SequenceMatcher fails to distinguish between a "replace" block and an "insert" or "delete" block when the "insert/delete" immediately follows a "replace". It will lump both changes together as one big "replace" block. This happens due to how get_opcodes() works. get_opcodes() loops through the matching blocks, grouping them into tags and ranges. However, if a block of text is changed and then new text is immediately added, it can't see this. All it knows is that the next matching block is after the added text. As an example, consider these strings: "ABC" "ABCD EFG." Any diffing program will show that the first line was replaced and the second was inserted. SequenceMatcher, however, just shows that there was one replace, and includes both lines in the range. I've attached a testcase that reproduces this for both replace>insert and replace>delete blocks. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 19:40 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for the test case! Is there any chance you could also provide a patch to fix it? ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-07 01:40 Message: Logged In: YES user_id=479790 Originator: NO Maybe you are more interested on a Differ object. These are the results from your example using '\n'.join(difflib.Differ().compare(a,b)) - This is my old file, containing only one line. + This is my new file. + It contains multiple lines. + SequenceMatcher should see two blocks as a result. and + This is my new file, containing only one line. - This is my old file. - It contains multiple lines. - SequenceMatcher should see two blocks as a result. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711800&group_id=5470 From noreply at sourceforge.net Wed Jun 6 04:40:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 19:40:15 -0700 Subject: [ python-Bugs-886488 ] WinPython 2.3.3 crashes using popen2 to spawn lots of child Message-ID: Bugs item #886488, was opened at 2004-01-28 15:28 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886488&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Terhaar-Yonkers (frankty) Assigned to: Nobody/Anonymous (nobody) Summary: WinPython 2.3.3 crashes using popen2 to spawn lots of child Initial Comment: WinPython 2.3.3 crashes when using popen2 to spawn *lots* of children > 100. Running the test case on either W2k or Wxp causes Python 2.3.3 to crash. Looking at the drwatson file, it appears to be a race condition where the child is in the process of crashing, while the popen2 code in posixmodule.c is attempting to PyFile_SetBufSize() on one of the pipes. Evil juju in ntdll.dll .. I've no idea what system resource is being exhausted (heap memory?) causing the crash. If you look at the hacks in posixmodule.c, the Python crash can be eliminated by simply commenting out the calls to PyFile_SetBufSize. There is still the problem of resource exhaustion. To gain more child processes I included a hack such that with the setting of an env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run a child, but simply run the child command as passed (yeah, I know that is has to be an absolute path or in the CWD then ..). I'm sure there is a better way to eliminate the cmd.exe /c - like maybe a new method: popen2.popenXabspath .. In any case, it appears we have an NT kernel bug combined with an inefficient way of doing popen2 that is making a mess. I started doing some exploration of heap_chunk_size to attack to resource issue but haven't gotten very far. As for *why* I'm doing this, it's because we're using Pyton as a system simulator tool to emulate a large pile of PCs. The actual work *must* be done by external .exe code that cannot be changed. The attached zip contains a test case, the posixmodule hack, drwatson file and a sample program written in VisC++ which does basically the same as the Python test case. cheers, - Frank ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-06-05 21:40 Message: Logged In: YES user_id=771074 Originator: NO The code for the popen* functions doesn't check the return value of _fdopen, which will return null when the limit of open stdio streams is reached. A similar issue exists in the win32pipe module, which uses almost exactly the same code. See Pywin32 bug 1731778 ( http://sourceforge.net/tracker/?func=detail&atid=551954&aid=1731778&group_id=78018 ) for more details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886488&group_id=5470 From noreply at sourceforge.net Wed Jun 6 08:22:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 23:22:52 -0700 Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks Message-ID: Bugs item #1445210, was opened at 2006-03-08 04:50 Message generated for change (Comment added) made by suresh_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Andrew Trevorrow (andykt) Assigned to: Nobody/Anonymous (nobody) Summary: embedding Python causes memory leaks Initial Comment: [This bug has been submitted by others but for some reason it has been marked Closed. I consider it to be an extremely serious bug -- if I can't solve it I'm going to have to abandon Python as my app's scripting language, even though I've fallen in love!] I've added Python script support to my cross-platfom wxWidgets app so that users can run .py scripts from within the app to automate the GUI and do other fancy things. It all works very nicely, except for one nasty problem: *every* time a script is run there is a memory leak, usually small (about 10K) but sometimes massive (about 4MB in the case of one rather complicated script). The problem occurs on both Mac OS 10.3.9 and Windows 2000. I'm using Python 2.3 on the Mac and 2.4.2 on Windows. Every time the user runs a script, my app makes these calls: (I've removed a lot of irrelevant stuff.) Py_Initialize(); PyRun_SimpleString("execfile('foo.py')"); Py_Finalize(); It's definitely not a wxWidgets problem. In fact it's quite easy to see the memory leak using a simple command-line program: #include #include main(int argc, char *argv[]) { int i; for (i=0; i<1000; i++) { Py_Initialize(); Py_Finalize(); printf("."); if ((i+1) % 50 == 0) printf("\n"); } } Note that it doesn't even execute a script. If I run this program on my Mac and watch its memory usage with Activity Monitor, I see a leak of about 10K each time through the loop. Similar result on Windows. Curiously, on both machines, the Py_Finalize() call takes longer and longer to complete whatever it's doing. The above program takes a few *minutes* to complete on my 400MHz Mac. Andrew ---------------------------------------------------------------------- Comment By: suresh (suresh_sf) Date: 2007-06-06 11:52 Message: Logged In: YES user_id=1809507 Originator: NO I too am having the exact similar problem with embedded python. Is this a expected behaviour? if so how can we use python for long running tasks without running out of memory eventually? We even tried doing Py_Initialize once during startup and executing scripts before calling Py_Finalize. Even this runs out of memory after some time. BTW, I am running Python 2.5.1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-13 12:59 Message: Logged In: YES user_id=21627 That the documentation claims Py_Finalize releases all memory is a bug; I just fixed this in r45344. The original problem cannot be fixed (atleast not until Python 3000); closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-10 11:13 Message: Logged In: YES user_id=1281947 See http://evanjones.ca/python-memory.html for some useful info. Apparently the Python memory allocator never releases memory back to the OS! So if a complicated script happens to consume 100MB of interpreter memory then that amount is no longer available to the app in which Python is embedded. Even worse, if a script has a (Python) memory leak then there's nothing the app can do about it. It would be great if wrapping each script inside Py_Initialize/Py_Finalize could avoid all that. There should be some way to tell Python "release all the memory you've ever allocated and start again with a clean slate". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 15:20 Message: Logged In: YES user_id=1281947 Bloody hell -- sorry for the bad line breaks. One day I'll figure out how to use sf properly! ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 15:16 Message: Logged In: YES user_id=1281947 > Why do you call Py_Initialize/Py_Finalize more than once? How else do I tell Python to free up memory after each PyRun_SimpleString call? I want users to be able to run scripts many times from within my app. If I just keep calling PyRun_SimpleString then my app will leak more and more memory until it becomes unusable. >From http://docs.python.org/api/embedding.html: Sometimes, it is desirable to ``uninitialize'' Python. For instance, the application may want to start over (make another call to Py_Initialize()) or the application is simply done with its use of Python and wants to free all memory allocated by Python. This can be accomplished by calling Py_Finalize(). That's exactly what I want to do. I want the interpreter to run a script and then release all the resources used by that script. Unfortunately, Py_Finalize does *not* restore memory usage to what it was before the Py_Initialize call. I wouldn't mind if there was a one-off allocation cost (the 1st time Py_Initialize is called), but my app is leaking more memory *every* time a script is run! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-08 14:02 Message: Logged In: YES user_id=33168 Why do you call Py_Initialize/Py_Finalize more than once? Why not do something like this (I'm kinda mixing C and Python for convenience): /* startup */ Py_Initialize(); /* do whatever */ while (moreFiles()) { PyRun_SimpleString("execfile('%s')" % nextFile()); /* do whatever */ } /* shutdown */ Py_Finalize(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 From noreply at sourceforge.net Wed Jun 6 13:11:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 04:11:28 -0700 Subject: [ python-Bugs-1230540 ] sys.excepthook doesn't work in threads Message-ID: Bugs item #1230540, was opened at 2005-06-30 20:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook doesn't work in threads Initial Comment: simple script to reproduce: import sys, threading def log_exception(*args): print 'got exception %s' % (args,) sys.excepthook = log_exception def foo(): a = 1 / 0 threading.Thread(target=foo).start() Note that a normal traceback is printed instead of "got exception." ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2007-06-06 12:11 Message: Logged In: YES user_id=6656 Originator: NO I've just run into this, and it's very annoying. The stupid part is that threads started with the thread module don't have this problem, it's just a problem with threading.Thread()s trying to be too clever. I would vote for deleting all the code to do with exception printing in threading.py and letting the C machinery take care of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470 From noreply at sourceforge.net Wed Jun 6 15:32:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 06:32:23 -0700 Subject: [ python-Bugs-1722344 ] Thread shutdown exception in Thread.notify() Message-ID: Bugs item #1722344, was opened at 2007-05-21 00:24 Message generated for change (Comment added) made by thomasda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yang Zhang (yangzhang) Assigned to: Nobody/Anonymous (nobody) Summary: Thread shutdown exception in Thread.notify() Initial Comment: Hi, I sometimes see the following exceptions when shutting down my app (using Python 2.5.1): Unhandled exception in thread started by Error in sys.excepthook: Original exception was: Exception in thread Thread-3 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap File "/usr/local/lib/python2.5/threading.py", line 440, in run File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker File "/usr/local/lib/python2.5/Queue.py", line 176, in get File "/usr/local/lib/python2.5/threading.py", line 248, in notify : exceptions must be classes, instances, or strings (deprecated), not NoneType Unhandled exception in thread started by Error in sys.excepthook: Original exception was: Exception in thread Thread-6 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap File "/usr/local/lib/python2.5/threading.py", line 440, in run File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py", line 71, in worker File "/usr/local/lib/python2.5/Queue.py", line 176, in get File "/usr/local/lib/python2.5/threading.py", line 248, in notify : exceptions must be classes, instances, or strings (deprecated), not NoneType Unhandled exception in thread started by Error in sys.excepthook: Original exception was: Here is the code from my application: def worker(): debug( 'starting worker' ) while True: msg = i.get() # <-- THIS IS LINE 71 if msg is stop_msg: break resultbuf, func, args, kwargs = msg result, exc = None, None try: result = func( *args, **kwargs ) except: t, v, tb = exc_info() exc = t, v, tb.tb_next o.put( ( resultbuf, result, exc ) ) s.send( 'x' ) # assuming socket.send is thread-safe debug( 'stopping worker' ) Here is the origin of the exception (in threading.py): def notify(self, n=1): assert self._is_owned(), "notify() of un-acquire()d lock" # <-- THIS IS LINE 248 __waiters = self.__waiters waiters = __waiters[:n] if not waiters: if __debug__: self._note("%s.notify(): no waiters", self) return self._note("%s.notify(): notifying %d waiter%s", self, n, n!=1 and "s" or "") for waiter in waiters: waiter.release() try: __waiters.remove(waiter) except ValueError: pass I'm not sure why this is happening. The threads are not daemon threads; I terminate them cleanly. When I get a SIGINT (I usu. shut down my app with ctrl-C), I enqueue n stop_msg's to the 'i' Queue so that the n workers can all exit. Note I usually launch 5 workers, so I'm not consistently getting an exception per worker. Also, I've been unable to reproduce this at will. ---------------------------------------------------------------------- Comment By: Thomas Dybdahl Ahle (thomasda) Date: 2007-06-06 15:32 Message: Logged In: YES user_id=1304417 Originator: NO I'm getting the same kind of errors. I'm using a lot of threads, and one of them throws this thread nearly everytime I close my program (by gtk.main_quit) It seems that python sets every variable to None, and then wakeup sleeping threads, which then crash, as they try to work with the None variables Exception in thread Thread-3 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap File "/home/thomas/Programmering/python/skak/0.7/lib/pychess/System/ThreadPool.py", line 49, in run File "/usr/lib/python2.4/Queue.py", line 89, in put File "/usr/lib/python2.4/threading.py", line 237, in notify exceptions.TypeError: exceptions must be classes, instances, or strings (deprecated), not NoneType Unhandled exception in thread started by Error in sys.excepthook ---------------------------------------------------------------------- Comment By: Yang Zhang (yangzhang) Date: 2007-05-21 16:47 Message: Logged In: YES user_id=1207658 Originator: YES No, as they are not daemon threads. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-21 14:01 Message: Logged In: YES user_id=479790 Originator: NO Do you join() the worker threads, waiting until they finish, before exiting the main thread? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470 From noreply at sourceforge.net Wed Jun 6 17:36:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 08:36:42 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Wed Jun 6 17:37:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 08:37:44 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-06 10:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Wed Jun 6 17:39:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 08:39:50 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-06 10:39 Message: Logged In: YES user_id=370230 Originator: YES Latest 'svn up' shows both these tests still failing in both the 2.5.1 and 2.6 trees. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Wed Jun 6 17:41:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 08:41:33 -0700 Subject: [ python-Bugs-1732145 ] python 2.6 latest fails test_socketserver.py Message-ID: Bugs item #1732145, was opened at 2007-06-06 10:41 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=1732145&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.6 latest fails test_socketserver.py Initial Comment: test_socket_ssl test_socketserver test test_socketserver crashed -- : (104, 'Connection reset by peer') test_softspace test_sort Exception in thread Thread-63: Traceback (most recent call last): File "/build/work/python-2.6/Lib/threading.py", line 465, in __bootstrap self.run() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 93, in run svr.serve_a_few() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 35, in serve_a_few self.handle_request() File "/build/work/python-2.6/Lib/SocketServer.py", line 224, in handle_request self.handle_error(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 429, in process_request self.collect_children() File "/build/work/python-2.6/Lib/SocketServer.py", line 425, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732145&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:00:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:00:32 -0700 Subject: [ python-Bugs-1732160 ] Unable to Start IDLE Message-ID: Bugs item #1732160, was opened at 2007-06-06 21: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=1732160&group_id=5470 Please note that this 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 Private: No Submitted By: Kishore (kishore_durai) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Start IDLE Initial Comment: HI, I am not unable to start Python IDLE from Start menu.. THe hour glass appears once i clikc the icon and vanishes quickly. Can anyone tell me how to fix this problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:20:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:20:12 -0700 Subject: [ python-Bugs-1727024 ] subprocess: unreliability of returncode not clear from docs Message-ID: Bugs item #1727024, was opened at 2007-05-28 13:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470 Please note that this 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 Private: No Submitted By: Dan O'Huiginn (ohuiginn) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: unreliability of returncode not clear from docs Initial Comment: The docs for the subprocess module (http://docs.python.org/lib/node533.html) give the impression that you can reliably find the return code of a process by checking returncode: -------- returncode The child return code. A None value indicates that the process hasn't terminated yet. A negative value -N indicates that the child was terminated by signal N (Unix only). -------- But in fact, returncode is only updated when the poll() method is called, and therefore will often be out-of-date. For instance >>> process=subprocess.Popen('true') #*nix command to do nothing >>> process.returncode >>> process.returncode==None True >>> process.poll() 0 >>> process.returncode 0 As far as I can see, it is always better to use poll() to check the status or return code of a subprocess. It might be good to either remove returncode from the docs entirely, or at least to explain that it won't always be correct. [incidentally, having returncode/poll() give None for a running process, and 0 for a process that has exited successfully, seems like a recipe for generating bugs. But I guess it's too late to do anything about that now] ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-06 12:20 Message: Logged In: YES user_id=1344176 Originator: NO What wording would you rather see in the subprocess docs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:38:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:38:03 -0700 Subject: [ python-Bugs-1651995 ] sgmllib _convert_ref UnicodeDecodeError exception, new in 2. Message-ID: Bugs item #1651995, was opened at 2007-02-04 23:34 Message generated for change (Comment added) made by odormond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib _convert_ref UnicodeDecodeError exception, new in 2. Initial Comment: I'm running a website page through BeautifulSoup. It parses OK with Python 2.4, but Python 2.5 fails with an exception: Traceback (most recent call last): File "./sitetruth/InfoSitePage.py", line 268, in httpfetch self.pagetree = BeautifulSoup.BeautifulSoup(sitetext) # parse into tree form File "./sitetruth/BeautifulSoup.py", line 1326, in __init__ BeautifulStoneSoup.__init__(self, *args, **kwargs) File "./sitetruth/BeautifulSoup.py", line 973, in __init__ self._feed() File "./sitetruth/BeautifulSoup.py", line 998, in _feed SGMLParser.feed(self, markup or "") File "/usr/lib/python2.5/sgmllib.py", line 99, in feed self.goahead(0) File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead k = self.parse_starttag(i) File "/usr/lib/python2.5/sgmllib.py", line 291, in parse_starttag self.finish_starttag(tag, attrs) File "/usr/lib/python2.5/sgmllib.py", line 340, in finish_starttag self.handle_starttag(tag, method, attrs) File "/usr/lib/python2.5/sgmllib.py", line 376, in handle_starttag method(attrs) File "./sitetruth/BeautifulSoup.py", line 1416, in start_meta self._feed(self.declaredHTMLEncoding) File "./sitetruth/BeautifulSoup.py", line 998, in _feed SGMLParser.feed(self, markup or "") File "/usr/lib/python2.5/sgmllib.py", line 99, in feed self.goahead(0) File "/usr/lib/python2.5/sgmllib.py", line 133, in goahead k = self.parse_starttag(i) File "/usr/lib/python2.5/sgmllib.py", line 285, in parse_starttag self._convert_ref, attrvalue) UnicodeDecodeError: 'ascii' codec can't decode byte 0xa7 in position 0: ordinal not in range(128) The code that's failing is in "_convert_ref", which is new in Python 2.5. That function wasn't present in 2.4. I think the code is trying to handle single quotes inside of double quotes in HTML attributes, or something like that. To replicate, run http://www.bankofamerica.com or http://www.gm.com through BeautifulSoup. Something about this code doesn't like big companies. Web sites of smaller companies are going through OK. ---------------------------------------------------------------------- Comment By: Olivier Dormond (odormond) Date: 2007-06-06 18:38 Message: Logged In: YES user_id=512858 Originator: NO Hello, I've been able to fix this entity conversion bug with the following patch. Cheers, Odie --- /usr/lib/python2.5/sgmllib.py 2007-05-27 17:55:15.000000000 +0200 +++ modules/sgmllib.py 2007-06-06 18:29:13.000000000 +0200 @@ -396,7 +396,7 @@ return self.convert_codepoint(n) def convert_codepoint(self, codepoint): - return chr(codepoint) + return unichr(codepoint) def handle_charref(self, name): """Handle character reference, no need to override.""" ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2007-04-27 23:41 Message: Logged In: YES user_id=5571 Originator: YES We've been running this fix for several months now, and it seems to work. Would someone please check it and put it into the trunk? Thanks. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2007-02-07 08:57 Message: Logged In: YES user_id=5571 Originator: YES Found the problem. In sgmllib.py for Python 2.5, in convert_charref, the code for handling character escapes assumes that ASCII characters have values up to 255. But the correct limit is 127, of course. If a Unicode string is run through SGMLparser, and that string has a character in an attribute with a value between 128 and 255, which is valid in Unicode, the value is passed through as a character with "chr", creating a one-character invalid ASCII string. Then, when the bad string is later converted to Unicode as the output is assembled, the UnicodeDecodeError exception is raised. So the fix is to change 255 to 127 in convert_charref in sgmllib.py, as shown below. This forces characters above 127 to be expressed with escape sequences. Please patch accordingly. Thanks. def convert_charref(self, name): """Convert character reference, may be overridden.""" try: n = int(name) except ValueError: return if not 0 <= n <= 127 : # ASCII ends at 127, not 255 return return self.convert_codepoint(n) ---------------------------------------------------------------------- Comment By: wrstl prmpft (wrstlprmpft) Date: 2007-02-05 08:16 Message: Logged In: YES user_id=801589 Originator: NO I had a similar problem recently and did not have time to file a bug-report. Thanks for doing that. The problem is the code that handles entity and character references in SGMLParser.parse_starttag. Seems that it is not careful about unicode/str issues. (But maybe Beautifulsoup needs to tell it to?) My quick'n'dirty workaround was to remove the offending char-entity from the website before feeding it to Beautifulsoup:: text = text.replace('®', '') # remove rights reserved sign entity cheers, stefan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651995&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:38:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:38:48 -0700 Subject: [ python-Bugs-1717900 ] Destructor behavior faulty Message-ID: Bugs item #1717900, was opened at 2007-05-12 15:41 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Wolf Rogner (wrogner) Assigned to: Nobody/Anonymous (nobody) Summary: Destructor behavior faulty Initial Comment: I tried example 11.4. from bytesofpython (by C.H. Swaroop). Example works fine. Added a new Person instance 'wolf' -> Program terminated with: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in > ignored added print list(globals()) -> ['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__'] changed wolf to aaa: print list(globals()) -> ['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__'] Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'. If the destructing code removes items in this order, no wonder I get an error. Person should not get deleted if refcount is still > 0. Wolf Rogner ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-06-06 11:38 Message: Logged In: YES user_id=1115903 Originator: NO Brought this up on python-dev: http://mail.python.org/pipermail/python-dev/2007-May/073329.html Since there is some interest in making the change Armin suggested, I suggest re-opening this item so that it doesn't get overlooked/forgotten. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-05-27 21:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: 2007-05-17 03:15 Message: Logged In: YES user_id=849994 Originator: NO Alan: you should bring that up on python-dev. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-16 17:58 Message: Logged In: YES user_id=1115903 Originator: NO I tried out a simple change (to the trunk) in _PyModule_Clear to prevent this particular problem. Between the "remove everything beginning with an underscore" and the "remove everything except __builtins__" steps, I added a step to remove all instance objects in the module's dictionary. It appears to stop this problem and passes the regression test suite. I can post it as a patch if this seems like a reasonable change to make. Also, I noticed that earlier I posted the wrong link for the location of the example code; it should have been: http://www.dpawson.co.uk/bop/byteofpython_120.txt ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 17:06 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 06:19 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-15 13:44 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-14 10:38 Message: Logged In: YES user_id=1115903 Originator: NO I took the example mentioned from here: http://www.python.org/doc/essays/cleanup/ and added this line to the end: wolf = Person('wolf') and it gives the reported error. Here is a minimal snippet that produces the same error when executed as the top-level module: class Person: population = 0 def __del__(self): Person.population -= 1 wolf = Person() This appears to be consistent with the behavior described here: http://www.python.org/doc/essays/cleanup/ While I understand that cleaning up a module at exit time is probably not an easy thing to make arbitrarily smart, this behavior seems a little too not-smart to me. It seems like it's not all that hard to get bitten by it, and the error makes no sense unless you're familiar with the module cleanup algorithm. For what it's worth, I offer to help make module cleanup a little smarter, although I may not be able to spend much time on it until I finish some things I'm already committed to do. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-12 18:36 Message: Logged In: YES user_id=1115903 Originator: NO Could you post the code for your entire script? It makes it a lot easier to figure out what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:49:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:49:52 -0700 Subject: [ python-Bugs-1712522 ] urllib.quote throws exception on Unicode URL Message-ID: Bugs item #1712522, was opened at 2007-05-04 06:11 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote throws exception on Unicode URL Initial Comment: The code in urllib.quote fails on Unicode input, when called by robotparser with a Unicode URL. Traceback (most recent call last): File "./sitetruth/InfoSitePage.py", line 415, in run pagetree = self.httpfetch() # fetch page File "./sitetruth/InfoSitePage.py", line 368, in httpfetch if not self.owner().checkrobotaccess(self.requestedurl) : # if access disallowed by robots.txt file File "./sitetruth/InfoSiteContent.py", line 446, in checkrobotaccess return(self.robotcheck.can_fetch(config.kuseragent, url)) # return can fetch File "/usr/local/lib/python2.5/robotparser.py", line 159, in can_fetch url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/" File "/usr/local/lib/python2.5/urllib.py", line 1197, in quote res = map(safe_map.__getitem__, s) KeyError: u'\xe2' That bit of code needs some attention. - It still assumes ASCII goes up to 255, which hasn't been true in Python for a while now. - The initialization may not be thread-safe; a table is being initialized on first use. "robotparser" was trying to check if a URL with a Unicode character in it was allowed. Note the "KeyError: u'\xe2'" ---------------------------------------------------------------------- >Comment By: John Nagle (nagle) Date: 2007-06-06 16:49 Message: Logged In: YES user_id=5571 Originator: YES As a workaround, you can surround calls to "can_fetch" with an try-block and catch KeyError exceptions. That's what I'm doing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 23:39 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly provide a patch to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:50:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:50:03 -0700 Subject: [ python-Bugs-1732212 ] repr of 'nan' floats not parseable Message-ID: Bugs item #1732212, was opened at 2007-06-06 16: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=1732212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pete Shinners (shredwheat) Assigned to: Nobody/Anonymous (nobody) Summary: repr of 'nan' floats not parseable Initial Comment: The repr of float('nan') is not parsable as a literal in Python. If the repr of 'nan' became "float('nan')" then the result could be evaluated to produce the same results. A better possible solution would be to add "nan" and "inf" as attributes on float. These would be accessed as "float.nan" and "float.inf". This doesn't allow for "-inf" as cleanly, but "float.ninf" could be acceptable. Repr would be changed to return these. A patch can be provided if the solution sounds resonable. >>> repr((1.0, 2.0, 3.0)) '(1.0, 2.0, 3.0)' >>> eval(_) (1.0, 2.0, 3.0) >>> repr((1.0, float('nan'), 3.0)) '(1.0, nan, 3.0)' >>> eval(_) NameError: name 'nan' is not defined ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732212&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:53:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:53:16 -0700 Subject: [ python-Bugs-1731706 ] tkinter memory leak problem Message-ID: Bugs item #1731706, was opened at 2007-06-05 15:47 Message generated for change (Comment added) made by robhancock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731706&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Hancock (robhancock) Assigned to: Martin v. L?wis (loewis) Summary: tkinter memory leak problem Initial Comment: We have a Python application which displays a GUI using Tkinter and Pmw. We have seen that over time the memory usage of the app seems to continuously increase and eventually use up all of the system's RAM. I ran the app under Valgrind, and this leak seems to account for most of the memory that it detects as being leaked: ==31141== 2,630,208 (806,400 direct, 1,823,808 indirect) bytes in 21 blocks are definitely lost in loss record 156 of 159 ==31141== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31141== by 0x368268844A: TclThreadAllocObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682686BA0: Tcl_NewStringObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3B258: AsObj (_tkinter.c:902) ==31141== by 0x8B3BB1C: Tkapp_CallArgs (_tkinter.c:1149) ==31141== by 0x8B3BD67: Tkapp_CallProc (_tkinter.c:1224) ==31141== by 0x36826786D4: Tcl_ServiceEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682678A20: Tcl_DoOneEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3F55B: Tkapp_MainLoop (_tkinter.c:2532) ==31141== by 0x36900949D9: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x369009405E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690094485: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095951: PyEval_EvalCode (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B1EA8: (within /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B3357: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B979C: Py_Main (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x368161D8A3: (below main) (in /lib64/libc-2.5.so) Looking at the code in _tkinter.c, I am not sure how the Tkapp_CallDeallocArgs function is supposed to get called in the case where we push the request onto the Tcl interpreter thread in Tkapp_Call. That call is what would presumably release this allocated memory. This is using Python 2.4.3 and tcl/tk 8.4.13. Looking at Python SVN, there does not seem to be any relevant code changes in _tkinter.c in later versions.. ---------------------------------------------------------------------- >Comment By: Robert Hancock (robhancock) Date: 2007-06-06 10:53 Message: Logged In: YES user_id=1809277 Originator: YES Found a couple of issues in _tkinter.c that appear to have been causing this: -When calls were forwarded onto the Tcl interpreter thread, the Tkapp_CallDeallocArgs function was never called to clean up the converted arguments after the call. -Tcl_Condition variables were never finalized after being used. According to the Tcl documentation, if this is not done they are only cleaned up on program exit, resulting in them accumulating during runtime. I'm attaching a patch against Python 2.4.3 to fix this problem. It likely applies to later versions as well. File Added: python-2.4.3-memleak-fix.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731706&group_id=5470 From noreply at sourceforge.net Wed Jun 6 20:12:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 11:12:29 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-03 01:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 Please note that this 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 Private: No Submitted By: reedobrien (reedobrien) Assigned to: Georg Brandl (gbrandl) Summary: cStringIO no longer accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-06 18:12 Message: Logged In: YES user_id=849994 Originator: NO I'll look at it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:40 Message: Logged In: YES user_id=80475 Originator: NO Georgbot, I believe this was your checkin. ---------------------------------------------------------------------- Comment By: reedobrien (reedobrien) Date: 2007-06-03 05:49 Message: Logged In: YES user_id=995094 Originator: YES It appears this is the change that broke it. http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302 This is the log entry from that changeset: Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode arguments with the system default encoding just like the write() method does, instead of converting it to a raw buffer. (backport from rev. 52301) Perhaps the cPickle module should be used instead... BUT at first glance the following seems to make both work: if (PyUnicode_Check(s)) { if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0) { PyErr_Format(PyExc_TypeError, "expected character buffer, %.200s found", s->ob_type->tp_name); return NULL; } } else { if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0) return NULL; } But the more I think about it the more I think cPickle is more appropriate for this purpose. In that case I should make a blurb for the docs about not storing arbitrary data in cStringIO. Either way I am attaching the cStringIO.c file that worked for me... File Added: cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Wed Jun 6 20:12:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 11:12:35 -0700 Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks Message-ID: Bugs item #1445210, was opened at 2006-03-08 00:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Andrew Trevorrow (andykt) Assigned to: Nobody/Anonymous (nobody) Summary: embedding Python causes memory leaks Initial Comment: [This bug has been submitted by others but for some reason it has been marked Closed. I consider it to be an extremely serious bug -- if I can't solve it I'm going to have to abandon Python as my app's scripting language, even though I've fallen in love!] I've added Python script support to my cross-platfom wxWidgets app so that users can run .py scripts from within the app to automate the GUI and do other fancy things. It all works very nicely, except for one nasty problem: *every* time a script is run there is a memory leak, usually small (about 10K) but sometimes massive (about 4MB in the case of one rather complicated script). The problem occurs on both Mac OS 10.3.9 and Windows 2000. I'm using Python 2.3 on the Mac and 2.4.2 on Windows. Every time the user runs a script, my app makes these calls: (I've removed a lot of irrelevant stuff.) Py_Initialize(); PyRun_SimpleString("execfile('foo.py')"); Py_Finalize(); It's definitely not a wxWidgets problem. In fact it's quite easy to see the memory leak using a simple command-line program: #include #include main(int argc, char *argv[]) { int i; for (i=0; i<1000; i++) { Py_Initialize(); Py_Finalize(); printf("."); if ((i+1) % 50 == 0) printf("\n"); } } Note that it doesn't even execute a script. If I run this program on my Mac and watch its memory usage with Activity Monitor, I see a leak of about 10K each time through the loop. Similar result on Windows. Curiously, on both machines, the Py_Finalize() call takes longer and longer to complete whatever it's doing. The above program takes a few *minutes* to complete on my 400MHz Mac. Andrew ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-06 20:12 Message: Logged In: YES user_id=21627 Originator: NO If you are calling Py_Finalize multiple times, (small) memory leaks are expected. So don't call Py_Finalize until your program terminates. ---------------------------------------------------------------------- Comment By: suresh (suresh_sf) Date: 2007-06-06 08:22 Message: Logged In: YES user_id=1809507 Originator: NO I too am having the exact similar problem with embedded python. Is this a expected behaviour? if so how can we use python for long running tasks without running out of memory eventually? We even tried doing Py_Initialize once during startup and executing scripts before calling Py_Finalize. Even this runs out of memory after some time. BTW, I am running Python 2.5.1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-13 09:29 Message: Logged In: YES user_id=21627 That the documentation claims Py_Finalize releases all memory is a bug; I just fixed this in r45344. The original problem cannot be fixed (atleast not until Python 3000); closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-10 06:43 Message: Logged In: YES user_id=1281947 See http://evanjones.ca/python-memory.html for some useful info. Apparently the Python memory allocator never releases memory back to the OS! So if a complicated script happens to consume 100MB of interpreter memory then that amount is no longer available to the app in which Python is embedded. Even worse, if a script has a (Python) memory leak then there's nothing the app can do about it. It would be great if wrapping each script inside Py_Initialize/Py_Finalize could avoid all that. There should be some way to tell Python "release all the memory you've ever allocated and start again with a clean slate". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 10:50 Message: Logged In: YES user_id=1281947 Bloody hell -- sorry for the bad line breaks. One day I'll figure out how to use sf properly! ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 10:46 Message: Logged In: YES user_id=1281947 > Why do you call Py_Initialize/Py_Finalize more than once? How else do I tell Python to free up memory after each PyRun_SimpleString call? I want users to be able to run scripts many times from within my app. If I just keep calling PyRun_SimpleString then my app will leak more and more memory until it becomes unusable. >From http://docs.python.org/api/embedding.html: Sometimes, it is desirable to ``uninitialize'' Python. For instance, the application may want to start over (make another call to Py_Initialize()) or the application is simply done with its use of Python and wants to free all memory allocated by Python. This can be accomplished by calling Py_Finalize(). That's exactly what I want to do. I want the interpreter to run a script and then release all the resources used by that script. Unfortunately, Py_Finalize does *not* restore memory usage to what it was before the Py_Initialize call. I wouldn't mind if there was a one-off allocation cost (the 1st time Py_Initialize is called), but my app is leaking more memory *every* time a script is run! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-08 09:32 Message: Logged In: YES user_id=33168 Why do you call Py_Initialize/Py_Finalize more than once? Why not do something like this (I'm kinda mixing C and Python for convenience): /* startup */ Py_Initialize(); /* do whatever */ while (moreFiles()) { PyRun_SimpleString("execfile('%s')" % nextFile()); /* do whatever */ } /* shutdown */ Py_Finalize(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 From noreply at sourceforge.net Wed Jun 6 20:40:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 11:40:01 -0700 Subject: [ python-Bugs-1732212 ] repr of 'nan' floats not parseable Message-ID: Bugs item #1732212, was opened at 2007-06-06 18:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pete Shinners (shredwheat) Assigned to: Nobody/Anonymous (nobody) Summary: repr of 'nan' floats not parseable Initial Comment: The repr of float('nan') is not parsable as a literal in Python. If the repr of 'nan' became "float('nan')" then the result could be evaluated to produce the same results. A better possible solution would be to add "nan" and "inf" as attributes on float. These would be accessed as "float.nan" and "float.inf". This doesn't allow for "-inf" as cleanly, but "float.ninf" could be acceptable. Repr would be changed to return these. A patch can be provided if the solution sounds resonable. >>> repr((1.0, 2.0, 3.0)) '(1.0, 2.0, 3.0)' >>> eval(_) (1.0, 2.0, 3.0) >>> repr((1.0, float('nan'), 3.0)) '(1.0, nan, 3.0)' >>> eval(_) NameError: name 'nan' is not defined ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-06 20:40 Message: Logged In: YES user_id=21627 Originator: NO Please discuss this on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732212&group_id=5470 From noreply at sourceforge.net Wed Jun 6 20:41:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 11:41:03 -0700 Subject: [ python-Bugs-1727024 ] subprocess: unreliability of returncode not clear from docs Message-ID: Bugs item #1727024, was opened at 2007-05-28 17:41 Message generated for change (Comment added) made by ohuiginn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470 Please note that this 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 Private: No Submitted By: Dan O'Huiginn (ohuiginn) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: unreliability of returncode not clear from docs Initial Comment: The docs for the subprocess module (http://docs.python.org/lib/node533.html) give the impression that you can reliably find the return code of a process by checking returncode: -------- returncode The child return code. A None value indicates that the process hasn't terminated yet. A negative value -N indicates that the child was terminated by signal N (Unix only). -------- But in fact, returncode is only updated when the poll() method is called, and therefore will often be out-of-date. For instance >>> process=subprocess.Popen('true') #*nix command to do nothing >>> process.returncode >>> process.returncode==None True >>> process.poll() 0 >>> process.returncode 0 As far as I can see, it is always better to use poll() to check the status or return code of a subprocess. It might be good to either remove returncode from the docs entirely, or at least to explain that it won't always be correct. [incidentally, having returncode/poll() give None for a running process, and 0 for a process that has exited successfully, seems like a recipe for generating bugs. But I guess it's too late to do anything about that now] ---------------------------------------------------------------------- >Comment By: Dan O'Huiginn (ohuiginn) Date: 2007-06-06 18:41 Message: Logged In: YES user_id=1803299 Originator: YES Thanks for the reply, Collin. Perhaps something like: Note: The value stored in returncode may be out-of-date. Use poll() to reliably find the current return code. Alternatively, would it be possible to leave it out completely [and move the explanation of what return codes mean up into the description of poll()]? I can?t imagine many situations where it is a good idea to check returncode directly, and as I understand it the module documentation only covers variables that are useful to the outside world. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-06 16:20 Message: Logged In: YES user_id=1344176 Originator: NO What wording would you rather see in the subprocess docs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470 From noreply at sourceforge.net Wed Jun 6 21:00:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 12:00:01 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-06 14:00 Message: Logged In: YES user_id=370230 Originator: YES Answering platform request. Fedora 6 with latest patches. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:39 Message: Logged In: YES user_id=370230 Originator: YES Latest 'svn up' shows both these tests still failing in both the 2.5.1 and 2.6 trees. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Thu Jun 7 04:02:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 19:02:14 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 07:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 19:02 Message: Logged In: YES user_id=33168 Originator: NO David, I don't have access to a fedora 6 box. Could you either debug the problem or provide access to such a box? I think I have seen the curses problem somewhere else, so this may be an API issue that the python module doesn't handle it correctly. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 12:00 Message: Logged In: YES user_id=370230 Originator: YES Answering platform request. Fedora 6 with latest patches. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 08:39 Message: Logged In: YES user_id=370230 Originator: YES Latest 'svn up' shows both these tests still failing in both the 2.5.1 and 2.6 trees. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 08:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 08:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 15:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 07:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Thu Jun 7 04:19:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 19:19:06 -0700 Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks Message-ID: Bugs item #1445210, was opened at 2006-03-07 15:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Andrew Trevorrow (andykt) Assigned to: Nobody/Anonymous (nobody) Summary: embedding Python causes memory leaks Initial Comment: [This bug has been submitted by others but for some reason it has been marked Closed. I consider it to be an extremely serious bug -- if I can't solve it I'm going to have to abandon Python as my app's scripting language, even though I've fallen in love!] I've added Python script support to my cross-platfom wxWidgets app so that users can run .py scripts from within the app to automate the GUI and do other fancy things. It all works very nicely, except for one nasty problem: *every* time a script is run there is a memory leak, usually small (about 10K) but sometimes massive (about 4MB in the case of one rather complicated script). The problem occurs on both Mac OS 10.3.9 and Windows 2000. I'm using Python 2.3 on the Mac and 2.4.2 on Windows. Every time the user runs a script, my app makes these calls: (I've removed a lot of irrelevant stuff.) Py_Initialize(); PyRun_SimpleString("execfile('foo.py')"); Py_Finalize(); It's definitely not a wxWidgets problem. In fact it's quite easy to see the memory leak using a simple command-line program: #include #include main(int argc, char *argv[]) { int i; for (i=0; i<1000; i++) { Py_Initialize(); Py_Finalize(); printf("."); if ((i+1) % 50 == 0) printf("\n"); } } Note that it doesn't even execute a script. If I run this program on my Mac and watch its memory usage with Activity Monitor, I see a leak of about 10K each time through the loop. Similar result on Windows. Curiously, on both machines, the Py_Finalize() call takes longer and longer to complete whatever it's doing. The above program takes a few *minutes* to complete on my 400MHz Mac. Andrew ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 19:19 Message: Logged In: YES user_id=33168 Originator: NO Also, it is quite common for third party C extension modules (those not distributed with Python) to contain memory leaks. If you are using any third party extension, you should investigate it very carefully to verify it is not leaking memory. You can use various memory debuggers to help find this problem. Valrgind and purify come to mind. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-06 11:12 Message: Logged In: YES user_id=21627 Originator: NO If you are calling Py_Finalize multiple times, (small) memory leaks are expected. So don't call Py_Finalize until your program terminates. ---------------------------------------------------------------------- Comment By: suresh (suresh_sf) Date: 2007-06-05 23:22 Message: Logged In: YES user_id=1809507 Originator: NO I too am having the exact similar problem with embedded python. Is this a expected behaviour? if so how can we use python for long running tasks without running out of memory eventually? We even tried doing Py_Initialize once during startup and executing scripts before calling Py_Finalize. Even this runs out of memory after some time. BTW, I am running Python 2.5.1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-13 00:29 Message: Logged In: YES user_id=21627 That the documentation claims Py_Finalize releases all memory is a bug; I just fixed this in r45344. The original problem cannot be fixed (atleast not until Python 3000); closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-09 21:43 Message: Logged In: YES user_id=1281947 See http://evanjones.ca/python-memory.html for some useful info. Apparently the Python memory allocator never releases memory back to the OS! So if a complicated script happens to consume 100MB of interpreter memory then that amount is no longer available to the app in which Python is embedded. Even worse, if a script has a (Python) memory leak then there's nothing the app can do about it. It would be great if wrapping each script inside Py_Initialize/Py_Finalize could avoid all that. There should be some way to tell Python "release all the memory you've ever allocated and start again with a clean slate". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 01:50 Message: Logged In: YES user_id=1281947 Bloody hell -- sorry for the bad line breaks. One day I'll figure out how to use sf properly! ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 01:46 Message: Logged In: YES user_id=1281947 > Why do you call Py_Initialize/Py_Finalize more than once? How else do I tell Python to free up memory after each PyRun_SimpleString call? I want users to be able to run scripts many times from within my app. If I just keep calling PyRun_SimpleString then my app will leak more and more memory until it becomes unusable. >From http://docs.python.org/api/embedding.html: Sometimes, it is desirable to ``uninitialize'' Python. For instance, the application may want to start over (make another call to Py_Initialize()) or the application is simply done with its use of Python and wants to free all memory allocated by Python. This can be accomplished by calling Py_Finalize(). That's exactly what I want to do. I want the interpreter to run a script and then release all the resources used by that script. Unfortunately, Py_Finalize does *not* restore memory usage to what it was before the Py_Initialize call. I wouldn't mind if there was a one-off allocation cost (the 1st time Py_Initialize is called), but my app is leaking more memory *every* time a script is run! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-08 00:32 Message: Logged In: YES user_id=33168 Why do you call Py_Initialize/Py_Finalize more than once? Why not do something like this (I'm kinda mixing C and Python for convenience): /* startup */ Py_Initialize(); /* do whatever */ while (moreFiles()) { PyRun_SimpleString("execfile('%s')" % nextFile()); /* do whatever */ } /* shutdown */ Py_Finalize(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 From noreply at sourceforge.net Thu Jun 7 06:23:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 21:23:35 -0700 Subject: [ python-Bugs-1732557 ] T_LONGLONG chokes on ints Message-ID: Bugs item #1732557, was opened at 2007-06-06 23: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=1732557&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: T_LONGLONG chokes on ints Initial Comment: Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a plain int, and give a misleading error msg: TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 From noreply at sourceforge.net Thu Jun 7 07:26:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 22:26:08 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-05 15:19 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this 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 Private: No Submitted By: dsagal (dsagal) >Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: 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 "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 22:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Thu Jun 7 07:32:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 22:32:18 -0700 Subject: [ python-Bugs-1732160 ] Unable to Start IDLE Message-ID: Bugs item #1732160, was opened at 2007-06-06 09:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 Please note that this 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 Private: No Submitted By: Kishore (kishore_durai) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Start IDLE Initial Comment: HI, I am not unable to start Python IDLE from Start menu.. THe hour glass appears once i clikc the icon and vanishes quickly. Can anyone tell me how to fix this problem. Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 22:32 Message: Logged In: YES user_id=33168 Originator: NO Do you have any sort of firewall/anti-virus software installed? That can conflict with IDLE because it tries to open a port. You can try going to the software and allowing IDLE to access this port. You can also try to open a terminal window and start IDLE manually and see if that works or if that produces an error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 From noreply at sourceforge.net Thu Jun 7 07:39:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 22:39:41 -0700 Subject: [ python-Bugs-1732160 ] Unable to Start IDLE Message-ID: Bugs item #1732160, was opened at 2007-06-06 21:00 Message generated for change (Comment added) made by kishore_durai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 Please note that this 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 Private: No Submitted By: Kishore (kishore_durai) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Start IDLE Initial Comment: HI, I am not unable to start Python IDLE from Start menu.. THe hour glass appears once i clikc the icon and vanishes quickly. Can anyone tell me how to fix this problem. Thanks. ---------------------------------------------------------------------- >Comment By: Kishore (kishore_durai) Date: 2007-06-07 10:39 Message: Logged In: YES user_id=1810028 Originator: YES Hi..i checked my firewall also..tried opening it by disabling the firewall..Doesnt seem to help.How to let IDLE access thge port.Can someone give me more details. Terminal window in the sense starting IDLE from command ? I tried that too but didnt seem to help..Pls help. THanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 10:32 Message: Logged In: YES user_id=33168 Originator: NO Do you have any sort of firewall/anti-virus software installed? That can conflict with IDLE because it tries to open a port. You can try going to the software and allowing IDLE to access this port. You can also try to open a terminal window and start IDLE manually and see if that works or if that produces an error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 From noreply at sourceforge.net Thu Jun 7 08:10:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 23:10:10 -0700 Subject: [ python-Bugs-1732160 ] Unable to Start IDLE Message-ID: Bugs item #1732160, was opened at 2007-06-06 09:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 Please note that this 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 Private: No Submitted By: Kishore (kishore_durai) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Start IDLE Initial Comment: HI, I am not unable to start Python IDLE from Start menu.. THe hour glass appears once i clikc the icon and vanishes quickly. Can anyone tell me how to fix this problem. Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 23:10 Message: Logged In: YES user_id=33168 Originator: NO It looks like you can only change the port by changing code. (idlelib\PyShell.py) The port it uses is 8833. Try starting IDLE without a subprocess (and port IIRC): python.exe idle.py -n (ie, add -n option to the command line. You could probably find the answer by googling for something like "python idle startup port". ---------------------------------------------------------------------- Comment By: Kishore (kishore_durai) Date: 2007-06-06 22:39 Message: Logged In: YES user_id=1810028 Originator: YES Hi..i checked my firewall also..tried opening it by disabling the firewall..Doesnt seem to help.How to let IDLE access thge port.Can someone give me more details. Terminal window in the sense starting IDLE from command ? I tried that too but didnt seem to help..Pls help. THanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 22:32 Message: Logged In: YES user_id=33168 Originator: NO Do you have any sort of firewall/anti-virus software installed? That can conflict with IDLE because it tries to open a port. You can try going to the software and allowing IDLE to access this port. You can also try to open a terminal window and start IDLE manually and see if that works or if that produces an error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 From noreply at sourceforge.net Thu Jun 7 08:11:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 23:11:29 -0700 Subject: [ python-Bugs-1732160 ] Unable to Start IDLE Message-ID: Bugs item #1732160, was opened at 2007-06-06 09:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Kishore (kishore_durai) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to Start IDLE Initial Comment: HI, I am not unable to start Python IDLE from Start menu.. THe hour glass appears once i clikc the icon and vanishes quickly. Can anyone tell me how to fix this problem. Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 23:11 Message: Logged In: YES user_id=33168 Originator: NO BTW, for questions like these, it's better to ask on the Usenet group comp.lang.python. You can also reach it via python-list at python.org. Also #python on IRC (freenode.net) are good ways of asking for help for questions like these that aren't really bugs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 23:10 Message: Logged In: YES user_id=33168 Originator: NO It looks like you can only change the port by changing code. (idlelib\PyShell.py) The port it uses is 8833. Try starting IDLE without a subprocess (and port IIRC): python.exe idle.py -n (ie, add -n option to the command line. You could probably find the answer by googling for something like "python idle startup port". ---------------------------------------------------------------------- Comment By: Kishore (kishore_durai) Date: 2007-06-06 22:39 Message: Logged In: YES user_id=1810028 Originator: YES Hi..i checked my firewall also..tried opening it by disabling the firewall..Doesnt seem to help.How to let IDLE access thge port.Can someone give me more details. Terminal window in the sense starting IDLE from command ? I tried that too but didnt seem to help..Pls help. THanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 22:32 Message: Logged In: YES user_id=33168 Originator: NO Do you have any sort of firewall/anti-virus software installed? That can conflict with IDLE because it tries to open a port. You can try going to the software and allowing IDLE to access this port. You can also try to open a terminal window and start IDLE manually and see if that works or if that produces an error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732160&group_id=5470 From noreply at sourceforge.net Thu Jun 7 10:35:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 01:35:19 -0700 Subject: [ python-Bugs-1732629 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732629, was opened at 2007-06-07 16: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=1732629&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&group_id=5470 From noreply at sourceforge.net Thu Jun 7 11:50:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 02:50:47 -0700 Subject: [ python-Bugs-1732662 ] socket makefile objects are not independent Message-ID: Bugs item #1732662, was opened at 2007-06-07 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=1732662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Ondrej (ondrejj) Assigned to: Nobody/Anonymous (nobody) Summary: socket makefile objects are not independent Initial Comment: Running some python 2.4 code on python 2.5 does not work properly. Python documentation for socket library says: makefile( [mode[, bufsize]]) Return a file object associated with the socket. (File objects are described in 3.9, ``File Objects.'') The file object references a dup()ped version of the socket file descriptor, so the file object and socket object may be closed or garbage-collected independently. It is true for python 2.4, but not for python 2.5 (at least not one in Fedora 7). Closing socket and then using file descriptor does not work. Here is an example code: import socket s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(('salstar.sk', 25)) f=s.makefile('rw') s.shutdown(1) s.close() print f.readline() It writes "220 work.salstar.sk ESMTP Postfix" in python 2.4 but raises an exception for python 2.5: Traceback (most recent call last): File "socktest.py", line 9, in print f.readline() File "/usr/lib/python2.5/socket.py", line 345, in readline data = self._sock.recv(self._rbufsize) socket.error: (9, 'Bad file descriptor') Is it a bug of python 2.5 or a bug in documentation? Or is it Fedora specific? Can somebody test it on other systems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732662&group_id=5470 From noreply at sourceforge.net Thu Jun 7 12:20:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 03:20:14 -0700 Subject: [ python-Bugs-1732629 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732629, was opened at 2007-06-07 08:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&group_id=5470 Please note that this 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.3 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 10:20 Message: Logged In: YES user_id=849994 Originator: NO This is very likely not caused by a Python bug. Please discuss your script and the error in the comp.lang.python group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732629&group_id=5470 From noreply at sourceforge.net Thu Jun 7 12:28:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 03:28:52 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 18: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=1732686&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Thu Jun 7 15:08:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 06:08:17 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 10:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Thu Jun 7 15:41:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 06:41:15 -0700 Subject: [ python-Bugs-1430435 ] urllib2 has memory leaks Message-ID: Bugs item #1430435, was opened at 2006-02-13 04:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: halfik (halfik) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 has memory leaks Initial Comment: reg = urllib2.Request(url, data, headers) rl_handle = urllib2.urlopen(reg) urllib2 has hot memory leaks. gc: uncollectable <_fileobject memory_adres> gc: uncollectable ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:41 Message: Logged In: YES user_id=849994 Originator: NO Dupe of #1208304. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 12:36 Message: Logged In: YES user_id=752496 Originator: NO How did you produce those results? (how can I reproduce them?) In which Python version you did? Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470 From noreply at sourceforge.net Thu Jun 7 16:22:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 07:22:29 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 18:28 Message generated for change (Comment added) made by alexteo21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 Please note that this 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.3 >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Alex (alexteo21) Date: 2007-06-07 22:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 21:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Thu Jun 7 17:31:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 08:31:50 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 10:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 Please note that this 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.3 >Status: Pending Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 15:31 Message: Logged In: YES user_id=849994 Originator: NO We can't even remotely guess at the source of your exception with that info, even using our best crystal balls. But I see that you have posted on comp.lang.python, so let's see what comes out of it there. ---------------------------------------------------------------------- Comment By: Alex (alexteo21) Date: 2007-06-07 14:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Thu Jun 7 19:44:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 10:44:45 -0700 Subject: [ python-Bugs-799428 ] tk_focusNext() fails Message-ID: Bugs item #799428, was opened at 2003-09-02 16:58 Message generated for change (Comment added) made by lither You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Perry Greenfield (perrygreenfield) Assigned to: Nobody/Anonymous (nobody) Summary: tk_focusNext() fails Initial Comment: Calls to the widget method tk_focusNext() fail with "unsubscriptable object" error. Looking at the Tkinter.py code for the routine shows this statement: name = self.tk.call('tk_focusNext', self._w) (line 433) which used to return a string in 2.2 but now returns a "cmdName object". When this is passed to self._nametowidget(name), it fails when it tries to subscript name (line 1006) since the object does not support indexing. Perhaps str(name) or name.string is more appropriate now? (when that change is made, it works--well, I tested name.string and that worked) Perry Greenfield (perry at stsci.edu) ---------------------------------------------------------------------- Comment By: Rick Litherland (lither) Date: 2007-06-07 12:44 Message: Logged In: YES user_id=1797212 Originator: NO This problem still persists, at least in Python 2.4. As noted by Perry Greenfield, the same problem occurs in tk_focusPrev, and some other methods as well. Rather than track down all such calls it would be easier to add the line name = str(name) at the top of the nametowidget method. Rick Litherand. lither at math.lsu.edu ---------------------------------------------------------------------- Comment By: David Douard (douardda) Date: 2005-11-09 09:03 Message: Logged In: YES user_id=692511 The problem is still not resolved for now (AFAIK). Here is a very simple patch for Tkinter.py: *** 432,442 **** --- 432,446 ---- to 0.""" name = self.tk.call('tk_focusNext', self._w) if not name: return None + try: name=name.string + except: pass return self._nametowidget(name) def tk_focusPrev(self): """Return previous widget in the focus order. See tk_focusNext for details.""" name = self.tk.call('tk_focusPrev', self._w) if not name: return None + try: name=name.string + except: pass return self._nametowidget(name) def after(self, ms, func=None, *args): """Call function once after given time. Note: I have made this (try/except) cause I have encountered cases where "name" was still a string (well, at least with Python 2.3.1). David (david.douard*gmail.com) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-07 10:23 Message: Logged In: YES user_id=2772 Presumably, _nametowidget() should be modified to work properly with a "cmdName object", rather than modifying each site that gets a widget path from a tk command. ---------------------------------------------------------------------- Comment By: Perry Greenfield (perrygreenfield) Date: 2003-09-03 08:29 Message: Logged In: YES user_id=252130 Presumably the same problem exists with tk_focusPrev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470 From noreply at sourceforge.net Thu Jun 7 20:20:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 11:20:31 -0700 Subject: [ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout Message-ID: Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [root at net1 ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-07 13:20 Message: Logged In: YES user_id=370230 Originator: YES The test_timeout problem appears solved in latest svn. Neal, I'm new to Python. Let me know how to approach debugging this and I'll let you know what happens. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 21:02 Message: Logged In: YES user_id=33168 Originator: NO David, I don't have access to a fedora 6 box. Could you either debug the problem or provide access to such a box? I think I have seen the curses problem somewhere else, so this may be an API issue that the python module doesn't handle it correctly. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 14:00 Message: Logged In: YES user_id=370230 Originator: YES Answering platform request. Fedora 6 with latest patches. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:39 Message: Logged In: YES user_id=370230 Originator: YES Latest 'svn up' shows both these tests still failing in both the 2.5.1 and 2.6 trees. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:37 Message: Logged In: YES user_id=370230 Originator: YES test_curses ^[[?1049h^[[1;50r^[(B^[[m^[[4l^[[?7h^[[50;1H^[[?1049l^M^[[?1l^[>test test_curses crashed -- : endwin() returned ERR ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-06 10:36 Message: Logged In: YES user_id=370230 Originator: YES test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.00152) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 17:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. ---------------------------------------------------------------------- Comment By: David Favor (dfavor) Date: 2007-06-02 09:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 From noreply at sourceforge.net Thu Jun 7 23:36:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 14:36:53 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 23: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=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Thu Jun 7 23:57:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 14:57:00 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 23:36 Message generated for change (Comment added) made by oinopion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- >Comment By: Oinopion (oinopion) Date: 2007-06-07 23:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Fri Jun 8 01:15:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 16:15:11 -0700 Subject: [ python-Bugs-1733134 ] sqlite3.dll cannot be relocated Message-ID: Bugs item #1733134, was opened at 2007-06-08 09: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=1733134&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3.dll cannot be relocated Initial Comment: >From Josh Ritter: A number of our Windows customers have an issue with the sqlite3 module included with Python 2.5.1 We've tracked the problem down to the sqlite3.dll included with the Python 2.5.1 distribition. It is stripped and thus cannot be relocated. This causes the following exception on computers where something is already loaded into the address the sqlite3.dll wants to use: File "sqlite3\__init__.pyc", line 24, in File "sqlite3\dbapi2.pyc", line 27, in ImportError: DLL load failed: Invalid access to memory location. I downloaded the latest sqlite3.dll from http://www.sqlite.org and this fixes the problem. (This dll isn't stripped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 From noreply at sourceforge.net Fri Jun 8 01:58:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 16:58:36 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-06-07 23:58 Message: Logged In: YES user_id=1262199 Originator: NO Applied the patch in change 55821, and backported to 25-maint in 55822 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 17:23 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me, please apply. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-05 12:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 07:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 19:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 19:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-01 23:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Fri Jun 8 04:30:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 19:30:16 -0700 Subject: [ python-Bugs-1733184 ] slice type is unhashable Message-ID: Bugs item #1733184, was opened at 2007-06-07 19:30 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=1733184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 From noreply at sourceforge.net Fri Jun 8 06:05:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 21:05:28 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 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=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) >Assigned to: Gerhard H?ring (ghaering) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 21:05 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? I don't have windows. ---------------------------------------------------------------------- Comment By: Oinopion (oinopion) Date: 2007-06-07 14:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Fri Jun 8 07:24:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 22:24:42 -0700 Subject: [ python-Bugs-1733184 ] slice type is unhashable Message-ID: Bugs item #1733184, was opened at 2007-06-07 21:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-08 00:24 Message: Logged In: YES user_id=80475 Originator: NO FWIW, you have a easy work-around. Use repr(yourslice) as the dictionary key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 From noreply at sourceforge.net Fri Jun 8 07:36:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 22:36:09 -0700 Subject: [ python-Bugs-1733184 ] slice type is unhashable Message-ID: Bugs item #1733184, was opened at 2007-06-07 19:30 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: slice type is unhashable Initial Comment: Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable. I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality. Why shouldn't they be usable as dictionary keys? I have an application that really would like them to be usable as such. I know I can define a class Slice of my own .. but that seems so silly. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2007-06-07 22:36 Message: Logged In: YES user_id=8861 Originator: YES I could probably live with that. However, there are other kinds of objects being used as keys in the same dictionary, and I can't just repr() them all, because it is not true that a == b implies repr(a) == repr(b). (E.g., a = 3, b = 3.0.) Practicalities aside, it just seems silly to me that a simple type like slice should have all the prerequisites for being hashable and yet isn't, especially when much more complex types like methods are both comparable and hashable. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-07 22:24 Message: Logged In: YES user_id=80475 Originator: NO FWIW, you have a easy work-around. Use repr(yourslice) as the dictionary key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733184&group_id=5470 From noreply at sourceforge.net Fri Jun 8 09:54:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 00:54:56 -0700 Subject: [ python-Feature Requests-1733259 ] ZipFile CallBack Needed... Message-ID: Feature Requests item #1733259, was opened at 2007-06-08 09:54 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=1733259&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: durumdara (durumdara) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile CallBack Needed... Initial Comment: Hi! I wrote about this here: http://groups.google.com/group/comp.lang.python/browse_thread/thread/f08c37f30b654746/a0fe8ab504b3b702 And here: http://groups.google.com.kh/group/comp.lang.python/browse_thread/thread/c6069d12273025bf/18b9b1c286d9af7b?lnk=st&q=python+zip+callback&rnum=1#18b9b1c286d9af7b So need a little modification in ZipFile module to get more control on compression. A callback procedure needed to: - I show progress bar when I compress a file - I can abort the whole compression procedure When I compress little files, no problem. But when compress large files, I lost the control, and I don't know (I can't show) the compression progress, and the remaining bytes. I can change this in my app only, but if I installed a new Python I lost it everytime... :-( Thanks for your help: dd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1733259&group_id=5470 From noreply at sourceforge.net Fri Jun 8 10:13:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 01:13:51 -0700 Subject: [ python-Bugs-1733134 ] sqlite3.dll cannot be relocated Message-ID: Bugs item #1733134, was opened at 2007-06-08 01:15 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3.dll cannot be relocated Initial Comment: >From Josh Ritter: A number of our Windows customers have an issue with the sqlite3 module included with Python 2.5.1 We've tracked the problem down to the sqlite3.dll included with the Python 2.5.1 distribition. It is stripped and thus cannot be relocated. This causes the following exception on computers where something is already loaded into the address the sqlite3.dll wants to use: File "sqlite3\__init__.pyc", line 24, in File "sqlite3\dbapi2.pyc", line 27, in ImportError: DLL load failed: Invalid access to memory location. I downloaded the latest sqlite3.dll from http://www.sqlite.org and this fixes the problem. (This dll isn't stripped) ---------------------------------------------------------------------- >Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:13 Message: Logged In: YES user_id=163326 Originator: NO Unfortunately, I don't know where the problem originates. Either the SQLite 3.3.4 DLL that was originally imported into Python was stripped and current ones aren't. Or somewhere in the Python win32 build process DLLs are stripped. Maybe we should just update the SQLite3.DLL to a current one in the Python 2.5 branch. Due to their extensive regression tests new ones should generally be better than old ones. And the current SQLite DLL is too old for some cases (SQLAlchemy refuses to work with it because it's too old and buggy, for example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 From noreply at sourceforge.net Fri Jun 8 10:19:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 01:19:08 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 23:36 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) >Assigned to: Martin v. L?wis (loewis) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- >Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:19 Message: Logged In: YES user_id=163326 Originator: NO That's because the SQLite3.DLL in Windows is at version 3.3.4, which doesn't support that language construct, yet. As a workaround, just download the SQLite3.DLL from http://sqlite.org and copy it over the one in your Python installation. The real solution for Python is to update the SQLite3.DLL. Martin, can we update the SQLite3.DLL for the 2.5 branch? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-08 06:05 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? I don't have windows. ---------------------------------------------------------------------- Comment By: Oinopion (oinopion) Date: 2007-06-07 23:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Fri Jun 8 10:19:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 01:19:58 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 23:36 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) Assigned to: Martin v. L?wis (loewis) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- >Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:19 Message: Logged In: YES user_id=163326 Originator: NO If so, I'll do the necessary steps of course. ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:19 Message: Logged In: YES user_id=163326 Originator: NO That's because the SQLite3.DLL in Windows is at version 3.3.4, which doesn't support that language construct, yet. As a workaround, just download the SQLite3.DLL from http://sqlite.org and copy it over the one in your Python installation. The real solution for Python is to update the SQLite3.DLL. Martin, can we update the SQLite3.DLL for the 2.5 branch? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-08 06:05 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? I don't have windows. ---------------------------------------------------------------------- Comment By: Oinopion (oinopion) Date: 2007-06-07 23:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Fri Jun 8 12:57:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 03:57:59 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 18:28 Message generated for change (Comment added) made by alexteo21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 Please note that this 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.3 >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Alex (alexteo21) Date: 2007-06-08 18:57 Message: Logged In: YES user_id=1810740 Originator: YES Hi gbrandl, I think I understand where the problem is. But I am not sure if this is a bug by Python. In the code, I am using pexpect module which spawn a child for FTP session. After the child is closed, the file descriptor is still open (check /proc//fd) I believe that this cause the too many file open issue. However, when I run the same thing on Linux, the file descriptor is closed properly Is this the issue with the python pty module. It seems that the pty module on linux is more stable than on solaris Very much appreciate your comments Thanks, Alex ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 23:31 Message: Logged In: YES user_id=849994 Originator: NO We can't even remotely guess at the source of your exception with that info, even using our best crystal balls. But I see that you have posted on comp.lang.python, so let's see what comes out of it there. ---------------------------------------------------------------------- Comment By: Alex (alexteo21) Date: 2007-06-07 22:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 21:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Fri Jun 8 14:11:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 05:11:15 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 11:04 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2007-06-08 14:11 Message: Logged In: YES user_id=972995 Originator: YES What would be the RFC definition for a correct auto-line break in a (subject) mail header line? Wouldn't it be more simple to not do any auto-line break for the subject? or is there a requirement for the line break in the RFC. Don't think any reader program would fail because of >79 char subject header lines. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 22:17 Message: Logged In: YES user_id=12800 Originator: NO Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 22:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:40:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:40:25 -0700 Subject: [ python-Bugs-1733484 ] Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set Message-ID: Bugs item #1733484, was opened at 2007-06-08 08:40 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=1733484&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set Initial Comment: configure should detect that the 64 bit option has been specified, thus setting LD_LIBRARY_PATH_64. Or for all solaris builds LD_LIBRARY_PATH_64 can be set to whatever LD_LIBRARY_PATH is set too. LD_LIBRARY_PATH_64 is necesary to have when doing a shared object build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733484&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:42:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:42:38 -0700 Subject: [ python-Bugs-1733488 ] AIX Objects/buffereobject.c does not build on AIX Message-ID: Bugs item #1733488, was opened at 2007-06-08 08:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733488&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX Objects/buffereobject.c does not build on AIX Initial Comment: The file Objects/bufferobject.c does not build on AIX. This is do to a comma being inserted on the last item of the enum type buffer_t. If this comma is removed, which is legal C, then the file builds properly. The change is on line 22: enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, ANY_BUFFER, }; to 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=1733488&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:45:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:45:15 -0700 Subject: [ python-Bugs-1733493 ] AIX Modules/unicodedata.c does not build Message-ID: Bugs item #1733493, was opened at 2007-06-08 08: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=1733493&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX Modules/unicodedata.c does not build Initial Comment: There is a C++ style comment at line 78: // forward declaration static PyTypeObject UCD_Type; should be /* forward declaration */ static PyTypeObject UCD_Type; The AIX compiler can't handle this kind of comment in a C file and will not compile it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733493&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:52:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:52:55 -0700 Subject: [ python-Bugs-1733509 ] Modules/ld_so_aix needs to strip path off of whichcc call Message-ID: Bugs item #1733509, was opened at 2007-06-08 08: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=1733509&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/ld_so_aix needs to strip path off of whichcc call Initial Comment: In the shell, sh, which is used by ld_so_aix when doing the call whichcc=`which $CC` extraneous data could be added on before the path to the compiler, i.e. ARCH = rs6000, openwin = 1, term = xterm, shell = csh /usr/vacpp/bin/cc would be nice to have the script check for anything extra and strip it off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733509&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:56:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:56:12 -0700 Subject: [ python-Bugs-1733513 ] zlib configure behaves differently than main configure Message-ID: Bugs item #1733513, was opened at 2007-06-08 08: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=1733513&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: zlib configure behaves differently than main configure Initial Comment: The zlib configure has a different set of options than the root configure. For instance on the main configure if you want to use shared objects you use the parameter: --enable-shared but for zlib you have to use: --shared This is similar to all the options you can use within the zlib configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733513&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:58:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:58:14 -0700 Subject: [ python-Bugs-1733493 ] AIX Modules/unicodedata.c does not build Message-ID: Bugs item #1733493, was opened at 2007-06-08 22:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733493&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX Modules/unicodedata.c does not build Initial Comment: There is a C++ style comment at line 78: // forward declaration static PyTypeObject UCD_Type; should be /* forward declaration */ static PyTypeObject UCD_Type; The AIX compiler can't handle this kind of comment in a C file and will not compile it. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-06-08 22:58 Message: Logged In: YES user_id=55188 Originator: NO Already fixed in r52695, bug #1593525. Thank you for reporting! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733493&group_id=5470 From noreply at sourceforge.net Fri Jun 8 15:58:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 06:58:40 -0700 Subject: [ python-Bugs-1733518 ] setup.py incorrect for HP Message-ID: Bugs item #1733518, was opened at 2007-06-08 08: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=1733518&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py incorrect for HP Initial Comment: When building shared objects on HP, HP does not detect the shared object on link in the current directory unless it is told to. To fix this issue in setup.py the follow line needs to be added to the "def detect_modules() method: add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') to add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.library_dirs, './') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 From noreply at sourceforge.net Fri Jun 8 16:00:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 07:00:53 -0700 Subject: [ python-Bugs-1733523 ] HP shared object option Message-ID: Bugs item #1733523, was opened at 2007-06-08 09: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=1733523&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP shared object option Initial Comment: Would be nice to have an option to override the use of +z to use +Z instead. In the python that we use +Z is the more general of type of shared objects used, so we need to use this in our build. Currently we have to go in and edit the Makefiles to have it use +Z. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733523&group_id=5470 From noreply at sourceforge.net Fri Jun 8 16:04:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 07:04:14 -0700 Subject: [ python-Bugs-1733532 ] HP automatic build of zlib Message-ID: Bugs item #1733532, was opened at 2007-06-08 09: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=1733532&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP automatic build of zlib Initial Comment: When building on HP, the zlib module does not build, it fails. But if I cut and paste the same compile parameters into the window, it will build properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733532&group_id=5470 From noreply at sourceforge.net Fri Jun 8 16:07:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 07:07:13 -0700 Subject: [ python-Bugs-1733536 ] windows 64 bit builds Message-ID: Bugs item #1733536, was opened at 2007-06-08 09: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=1733536&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: windows 64 bit builds Initial Comment: It would be nice to have a full Visual Studio Solution available for Visual Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the vsextcomp utility, the options that are being used to make it 64 bit compatible are hidden and could cause issues in the future. I have converted the solution over to have the necesary compile/link option in a solution file if you want to do this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 From noreply at sourceforge.net Fri Jun 8 16:13:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 07:13:24 -0700 Subject: [ python-Bugs-1733544 ] HP 64 bit does not run Message-ID: Bugs item #1733544, was opened at 2007-06-08 09: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=1733544&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP 64 bit does not run Initial Comment: When building on HP(11.0 or 11.11) we unable to get a successful python interpreter to run, this is with python2.5. The problem seems to be due to changes to make the windows 64 bit build work. The integer sizes that are being returned for HP are bigger than what is allowed for python. Due to the sensitive area of this code, makeing this change caused alot of other errors to occur. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 From noreply at sourceforge.net Fri Jun 8 16:14:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 07:14:38 -0700 Subject: [ python-Bugs-1733546 ] AIX shared object build of python 2.5 does not work Message-ID: Bugs item #1733546, was opened at 2007-06-08 09:14 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=1733546&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX shared object build of python 2.5 does not work Initial Comment: When using the shared object option on AIX, this does create valid shared objects or a python interpreter that works. We were able to get the static version to work, but we require a shared object version as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733546&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:01:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:01:43 -0700 Subject: [ python-Bugs-1701409 ] Segfault in c_char_p of ctypes Message-ID: Bugs item #1701409, was opened at 2007-04-16 12:45 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701409&group_id=5470 Please note that this 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: 6 Private: No Submitted By: sebastien Martini (seb_martini) Assigned to: Thomas Heller (theller) Summary: Segfault in c_char_p of ctypes Initial Comment: Hi, I experienced a segmentation fault (when providing a wrong argument type to c_char_p) in the ctypes module under Linux and with the version 2.5 . sundae:~$ python Python 2.5.1c1 (release25-maint, Apr 6 2007, 22:02:36) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> c_char_p(42) zsh: segmentation fault (core dumped) python sundae:~$ Regards, Sebastien Martini ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 19:01 Message: Logged In: YES user_id=11105 Originator: NO Here's a patch that fixes the problems that belopolsky mentions: c_char_p_2.patch File Added: c_char_p_2.patch ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-20 22:42 Message: Logged In: YES user_id=835142 Originator: NO theller: [_objects] will not be set if the instance is modified by a foreign function call, so this is not robust. I thought about this before making my suggestion. I believe people will be less surprized if objects returned from an ffi call print with funny numbers than getting c_char_p(NNNNN) after entering c_char_p("abc"). A few comments on the patch: 1. Since c_void_p is printed in decimal, shouldn't c_char_p be treated the same? If hexadecimal is prefered, maybe c_void_p should be changed. 2. Currently c_char_p(0) is printed as c_char_p(None), but the patch will change that to c_char_p(0). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-04-20 21:52 Message: Logged In: YES user_id=11105 Originator: NO belopolsky: _objects is only set when the c_char_p instance is created in the way you described. It will not be set if the instance is modified by a foreign function call, so this is not robust. nnorwitz: Sure there are many ways to crash Python with ctypes, but printing c_char_p(42) should not carsh, IMO. I believe the best strategy would be to behave this way on Windows where the check for a valid string pointer can be made: >>> c_char_p(42) c_char_p(0x2A) >>> c_char("foo") c_char('foo') >>> and this way on other systems: >>> c_char_p(42) c_char_p(0x2A) >>> c_char_p("foo") c_char_p(0x2A7F3B) >>> The attached patch fixes this for c_char_p, a similar patch should be applied to c_wchar_p. File Added: c_char_p.patch ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-19 22:47 Message: Logged In: YES user_id=835142 Originator: NO It is easy to distinguish between a c_char_p that is created from a python string from one that is created from a python int: the former has an _objects attribute set to a string: >>> x,y = map(c_char_p, ('abc',42)) >>> (x._objects,y._objects) ('abc', None) It may be reasonable to give up a "nice" repr for the cases where c_char_p is not known to point into a python string. You can still keep "nice" str, so users can still enjoy a crash by printing c_char_p(42). :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-19 08:58 Message: Logged In: YES user_id=33168 Originator: NO > Do other platforms have a function that can do this check? There's no platform independent way to do this. I don't know anything about ctypes, but what might be a way to handle this is providing a way to convert an integer into a pointer (like a void*). Then all these routines could accept this void* type that you would define, but not accept a raw integer. That means people would still have access to do the same thing they can currently do, but it would be clearer that they are playing with fire by converting any int into a pointer. There are so many ways to use ctypes to crash, I'm not sure if this is worth fixing, except perhaps in the docs to point out the issues. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-04-18 21:20 Message: Logged In: YES user_id=11105 Originator: NO This is a difficult issue. The integer (which is interpreted as address) is allowed because some libraries use 'char *' pointers initialized to small, invalid addresses for special purposes. On windows, printing a c_char_p(42) does not crash, it raises a ValueError instead: >>> from ctypes import * >>> c_char_p(42) Traceback (most recent call last): File "", line 1, in ValueError: invalid string pointer 0x00B20B48 >>> Windows does this by checking if there is a valid string at the address (see Modules/_ctypes/cfield.c, line 1366) by calling the IsBadStringPointer api function. Do other platforms have a function that can do this check? If not, I'm afraid we would have to give up on the very convenient repr of 'normal' c_char_p instances: >>> c_char_p("foo bar") c_char_p('foo bar') >>> and only print the address (at least on non-windows). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-18 09:37 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the bug report Sebastien. This bug occurs in 2.5 and in the trunk, so it's not a regression. Thomas, could you take a look? Integers are specifically allowed here (floats are not). The problem is when trying to print the repr: #0 PyString_FromString (str=0x2a
) at Objects/stringobject.c:108 #1 z_get (ptr=0x2ae1aa9d6450, size=8) at Modules/_ctypes/cfield.c:1373 #2 Simple_get_value (self=0x2ae1aa9d63f8) at Modules/_ctypes/_ctypes.c:4007 #3 Simple_repr (self=0x2ae1aa9d63f8) at Modules/_ctypes/_ctypes.c:4095 #4 PyObject_Repr (v=0x2ae1aa9d63f8) at Objects/object.c:361 ---------------------------------------------------------------------- Comment By: sebastien Martini (seb_martini) Date: 2007-04-16 21:40 Message: Logged In: YES user_id=1528211 Originator: YES c_wchar_p also contains this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701409&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:15:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:15:54 -0700 Subject: [ python-Bugs-1733085 ] sqlite3 module trigger problem Message-ID: Bugs item #1733085, was opened at 2007-06-07 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=1733085&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oinopion (oinopion) >Assigned to: Anthony Baxter (anthonybaxter) Summary: sqlite3 module trigger problem Initial Comment: I and my team are building sqlite3 app and when used on Windows XP on Python 2.5.1 we get such an error: File "D:\studia\!bazy_projekt\svn2\src\muzzyk.py", line 39, in __init__ cur.executescript(scheme) OperationalError: near "NOT": syntax error while parsing http://muzzyk.googlecode.com/svn/trunk/src/scheme.sql Bug is about those triggers at the end of file. On linux or with pysqlite2 imported instead of sqlite3 everything is OK. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:15 Message: Logged In: YES user_id=21627 Originator: NO I don't know whether it is acceptable for 2.5.x to provide new features through the underlying DLL. That's for the release manager to decide. Anthony? ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:19 Message: Logged In: YES user_id=163326 Originator: NO If so, I'll do the necessary steps of course. ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:19 Message: Logged In: YES user_id=163326 Originator: NO That's because the SQLite3.DLL in Windows is at version 3.3.4, which doesn't support that language construct, yet. As a workaround, just download the SQLite3.DLL from http://sqlite.org and copy it over the one in your Python installation. The real solution for Python is to update the SQLite3.DLL. Martin, can we update the SQLite3.DLL for the 2.5 branch? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-08 06:05 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? I don't have windows. ---------------------------------------------------------------------- Comment By: Oinopion (oinopion) Date: 2007-06-07 23:57 Message: Logged In: YES user_id=1282560 Originator: YES File Added: scheme.sql ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733085&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:17:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:17:40 -0700 Subject: [ python-Bugs-1733536 ] windows 64 bit builds Message-ID: Bugs item #1733536, was opened at 2007-06-08 16:07 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: windows 64 bit builds Initial Comment: It would be nice to have a full Visual Studio Solution available for Visual Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the vsextcomp utility, the options that are being used to make it 64 bit compatible are hidden and could cause issues in the future. I have converted the solution over to have the necesary compile/link option in a solution file if you want to do this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:17 Message: Logged In: YES user_id=21627 Originator: NO That's already available in the PCbuild8 directory. Closing as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:18:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:18:09 -0700 Subject: [ python-Bugs-1733523 ] HP shared object option Message-ID: Bugs item #1733523, was opened at 2007-06-08 16:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733523&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP shared object option Initial Comment: Would be nice to have an option to override the use of +z to use +Z instead. In the python that we use +Z is the more general of type of shared objects used, so we need to use this in our build. Currently we have to go in and edit the Makefiles to have it use +Z. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:18 Message: Logged In: YES user_id=21627 Originator: NO Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733523&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:19:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:19:30 -0700 Subject: [ python-Bugs-1733532 ] HP automatic build of zlib Message-ID: Bugs item #1733532, was opened at 2007-06-08 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733532&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP automatic build of zlib Initial Comment: When building on HP, the zlib module does not build, it fails. But if I cut and paste the same compile parameters into the window, it will build properly. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:19 Message: Logged In: YES user_id=21627 Originator: NO Can you analyze this further? There must be something else going on, e.g. environment variables. Also, what is the specific error message that you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733532&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:19:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:19:30 -0700 Subject: [ python-Bugs-1733536 ] windows 64 bit builds Message-ID: Bugs item #1733536, was opened at 2007-06-08 09:07 Message generated for change (Comment added) made by bhochste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: windows 64 bit builds Initial Comment: It would be nice to have a full Visual Studio Solution available for Visual Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the vsextcomp utility, the options that are being used to make it 64 bit compatible are hidden and could cause issues in the future. I have converted the solution over to have the necesary compile/link option in a solution file if you want to do this. ---------------------------------------------------------------------- >Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 12:19 Message: Logged In: YES user_id=1812047 Originator: YES As of the python2.5 build, the pcBuild8 directory did not function properly. I imported from the pcbuild directory and then did my changes from that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 12:17 Message: Logged In: YES user_id=21627 Originator: NO That's already available in the PCbuild8 directory. Closing as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:21:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:21:42 -0700 Subject: [ python-Bugs-1733544 ] HP 64 bit does not run Message-ID: Bugs item #1733544, was opened at 2007-06-08 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP 64 bit does not run Initial Comment: When building on HP(11.0 or 11.11) we unable to get a successful python interpreter to run, this is with python2.5. The problem seems to be due to changes to make the windows 64 bit build work. The integer sizes that are being returned for HP are bigger than what is allowed for python. Due to the sensitive area of this code, makeing this change caused alot of other errors to occur. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:21 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide a precise description of the problem: what did you do, what happened, what did you expect to happen instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:22:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:22:37 -0700 Subject: [ python-Bugs-1733546 ] AIX shared object build of python 2.5 does not work Message-ID: Bugs item #1733546, was opened at 2007-06-08 16:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733546&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX shared object build of python 2.5 does not work Initial Comment: When using the shared object option on AIX, this does create valid shared objects or a python interpreter that works. We were able to get the static version to work, but we require a shared object version as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:22 Message: Logged In: YES user_id=21627 Originator: NO Can you give a precise description of the problem, please? What did you do, what happened, what did you expect to happen instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733546&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:23:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:23:47 -0700 Subject: [ python-Bugs-1733518 ] setup.py incorrect for HP Message-ID: Bugs item #1733518, was opened at 2007-06-08 15:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py incorrect for HP Initial Comment: When building shared objects on HP, HP does not detect the shared object on link in the current directory unless it is told to. To fix this issue in setup.py the follow line needs to be added to the "def detect_modules() method: add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') to add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.library_dirs, './') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:23 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug. Why do you have any libraries in the current directory that you want to link with? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:24:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:24:58 -0700 Subject: [ python-Bugs-1733513 ] zlib configure behaves differently than main configure Message-ID: Bugs item #1733513, was opened at 2007-06-08 15:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733513&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: zlib configure behaves differently than main configure Initial Comment: The zlib configure has a different set of options than the root configure. For instance on the main configure if you want to use shared objects you use the parameter: --enable-shared but for zlib you have to use: --shared This is similar to all the options you can use within the zlib configure. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:24 Message: Logged In: YES user_id=21627 Originator: NO What does that have to do with Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733513&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:25:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:25:30 -0700 Subject: [ python-Bugs-1733509 ] Modules/ld_so_aix needs to strip path off of whichcc call Message-ID: Bugs item #1733509, was opened at 2007-06-08 15:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733509&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/ld_so_aix needs to strip path off of whichcc call Initial Comment: In the shell, sh, which is used by ld_so_aix when doing the call whichcc=`which $CC` extraneous data could be added on before the path to the compiler, i.e. ARCH = rs6000, openwin = 1, term = xterm, shell = csh /usr/vacpp/bin/cc would be nice to have the script check for anything extra and strip it off. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:25 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733509&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:30:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:30:13 -0700 Subject: [ python-Bugs-1733488 ] AIX Objects/buffereobject.c does not build on AIX Message-ID: Bugs item #1733488, was opened at 2007-06-08 15:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733488&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: AIX Objects/buffereobject.c does not build on AIX Initial Comment: The file Objects/bufferobject.c does not build on AIX. This is do to a comma being inserted on the last item of the enum type buffer_t. If this comma is removed, which is legal C, then the file builds properly. The change is on line 22: enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, ANY_BUFFER, }; to enum buffer_t { READ_BUFFER, WRITE_BUFFER, CHAR_BUFFER, ANY_BUFFER }; ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:30 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. This is now fixed in r55829 and r55830 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733488&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:37:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:37:54 -0700 Subject: [ python-Bugs-1733484 ] Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set Message-ID: Bugs item #1733484, was opened at 2007-06-08 15:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733484&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 64 bit LD_LIBRARY_PATH_64 needs to be set Initial Comment: configure should detect that the 64 bit option has been specified, thus setting LD_LIBRARY_PATH_64. Or for all solaris builds LD_LIBRARY_PATH_64 can be set to whatever LD_LIBRARY_PATH is set too. LD_LIBRARY_PATH_64 is necesary to have when doing a shared object build. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:37 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a patch? Setting both unconditionally sounds fine to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733484&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:49:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:49:36 -0700 Subject: [ python-Bugs-1733134 ] sqlite3.dll cannot be relocated Message-ID: Bugs item #1733134, was opened at 2007-06-08 01:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3.dll cannot be relocated Initial Comment: >From Josh Ritter: A number of our Windows customers have an issue with the sqlite3 module included with Python 2.5.1 We've tracked the problem down to the sqlite3.dll included with the Python 2.5.1 distribition. It is stripped and thus cannot be relocated. This causes the following exception on computers where something is already loaded into the address the sqlite3.dll wants to use: File "sqlite3\__init__.pyc", line 24, in File "sqlite3\dbapi2.pyc", line 27, in ImportError: DLL load failed: Invalid access to memory location. I downloaded the latest sqlite3.dll from http://www.sqlite.org and this fixes the problem. (This dll isn't stripped) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:49 Message: Logged In: YES user_id=21627 Originator: NO I don't understand the problem, either. There is no "strip" operation on Windows that could cause this problem; relocation information is always present and cannot be removed under normal circumstances. So I think the problem is elsewhere. If Josh Ritter could report what precisely he did to determine that the 2.5-shipped version was "stripped" and the sqlite.org version isn't, that would be helpful. According to http://support.microsoft.com/kb/q196069/ the error 998 of LoadLibrary indicates ERROR_NOACCESS if an access violation occurred, so that might be a possible cause. To analyze this further, one would have to run the application under a debugger. ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2007-06-08 10:13 Message: Logged In: YES user_id=163326 Originator: NO Unfortunately, I don't know where the problem originates. Either the SQLite 3.3.4 DLL that was originally imported into Python was stripped and current ones aren't. Or somewhere in the Python win32 build process DLLs are stripped. Maybe we should just update the SQLite3.DLL to a current one in the Python 2.5 branch. Due to their extensive regression tests new ones should generally be better than old ones. And the current SQLite DLL is too old for some cases (SQLAlchemy refuses to work with it because it's too old and buggy, for example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733134&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:49:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:49:36 -0700 Subject: [ python-Bugs-1733518 ] setup.py incorrect for HP Message-ID: Bugs item #1733518, was opened at 2007-06-08 08:58 Message generated for change (Comment added) made by bhochste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py incorrect for HP Initial Comment: When building shared objects on HP, HP does not detect the shared object on link in the current directory unless it is told to. To fix this issue in setup.py the follow line needs to be added to the "def detect_modules() method: add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') to add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.library_dirs, './') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') ---------------------------------------------------------------------- >Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 12:49 Message: Logged In: YES user_id=1812047 Originator: YES sorry, this was due to a bad zlib that was occuring. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 12:23 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug. Why do you have any libraries in the current directory that you want to link with? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:52:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:52:47 -0700 Subject: [ python-Bugs-1733544 ] HP 64 bit does not run Message-ID: Bugs item #1733544, was opened at 2007-06-08 09:13 Message generated for change (Comment added) made by bhochste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP 64 bit does not run Initial Comment: When building on HP(11.0 or 11.11) we unable to get a successful python interpreter to run, this is with python2.5. The problem seems to be due to changes to make the windows 64 bit build work. The integer sizes that are being returned for HP are bigger than what is allowed for python. Due to the sensitive area of this code, makeing this change caused alot of other errors to occur. ---------------------------------------------------------------------- >Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 12:52 Message: Logged In: YES user_id=1812047 Originator: YES Here is a link to a discussion thread to see if anyone else had any information on the HP11 64 bit build on python2.5 http://groups.google.com/group/comp.lang.python/browse_thread/thread/1c9e61f222ac86ec/62586d476fdc4e24?lnk=st&q=bhochstetler&rnum=1#62586d476fdc4e24 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 12:21 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide a precise description of the problem: what did you do, what happened, what did you expect to happen instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:54:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:54:14 -0700 Subject: [ python-Bugs-1732686 ] Built-in open function fail. Too many file open Message-ID: Bugs item #1732686, was opened at 2007-06-07 12:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Alex (alexteo21) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in open function fail. Too many file open Initial Comment: Hi, I have created a cron script using python. Every hour it will batch process certain files e.g. t=open(filename,'rb') data=t.read() #processing data... t.close() The script is working fine on the day of execution. It is able to process the files. However, when the next day comes, the processing fail!! Traceback (most recent call last): File "./alexCopy.py", line 459, in processRequestModule sanityTestSteps(reqId,model) File "./alexCopy.py", line 699, in sanityTestSteps t = open(filename, 'rb') IOError: [Errno 24] Too many open files: I have explicitly closed the file. Please help. Thanks, Alex ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:54 Message: Logged In: YES user_id=21627 Originator: NO It's most likely a bug in your application; you should invoke .close() on the spawn object. If you do invoke .close() and the connection still stays open, it's a bug in pexpect, please report it to the authors of pexpect. Closing as invalid. ---------------------------------------------------------------------- Comment By: Alex (alexteo21) Date: 2007-06-08 12:57 Message: Logged In: YES user_id=1810740 Originator: YES Hi gbrandl, I think I understand where the problem is. But I am not sure if this is a bug by Python. In the code, I am using pexpect module which spawn a child for FTP session. After the child is closed, the file descriptor is still open (check /proc//fd) I believe that this cause the too many file open issue. However, when I run the same thing on Linux, the file descriptor is closed properly Is this the issue with the python pty module. It seems that the pty module on linux is more stable than on solaris Very much appreciate your comments Thanks, Alex ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 17:31 Message: Logged In: YES user_id=849994 Originator: NO We can't even remotely guess at the source of your exception with that info, even using our best crystal balls. But I see that you have posted on comp.lang.python, so let's see what comes out of it there. ---------------------------------------------------------------------- Comment By: Alex (alexteo21) Date: 2007-06-07 16:22 Message: Logged In: YES user_id=1810740 Originator: YES Additional info I am running the script on solaris. If I have a similar script in tcl but there is no issue there. It only happens on python ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 15:08 Message: Logged In: YES user_id=849994 Originator: NO Please do *not* open another bug when your first one was closed! If you think closing it was not correct, reopen the first one. In this case, however, I referred you to comp.lang.python, so *please* post the issue (and your script) there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732686&group_id=5470 From noreply at sourceforge.net Fri Jun 8 19:54:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 10:54:47 -0700 Subject: [ python-Bugs-1732557 ] T_LONGLONG chokes on ints Message-ID: Bugs item #1732557, was opened at 2007-06-07 06:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: T_LONGLONG chokes on ints Initial Comment: Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a plain int, and give a misleading error msg: TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:54 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 From noreply at sourceforge.net Fri Jun 8 20:58:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 11:58:19 -0700 Subject: [ python-Bugs-1733757 ] RuntimeWarning: tp_compare didn't return -1 or -2 Message-ID: Bugs item #1733757, was opened at 2007-06-08 18: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=1733757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabio Zadrozny (fabioz) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning: tp_compare didn't return -1 or -2 Initial Comment: The code attached is giving the error below D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return -1 or -2 for exception return _active[_get_ident()] Exception exceptions.SystemError: 'error return without exception set' in ignored Ok, I have no clues why there could be an error here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&group_id=5470 From noreply at sourceforge.net Fri Jun 8 20:58:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 11:58:44 -0700 Subject: [ python-Bugs-1733536 ] windows 64 bit builds Message-ID: Bugs item #1733536, was opened at 2007-06-08 16:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: windows 64 bit builds Initial Comment: It would be nice to have a full Visual Studio Solution available for Visual Studio 2005 64, with the proper 64 bit flags set. By hiding it behind the vsextcomp utility, the options that are being used to make it 64 bit compatible are hidden and could cause issues in the future. I have converted the solution over to have the necesary compile/link option in a solution file if you want to do this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 20:58 Message: Logged In: YES user_id=21627 Originator: NO Please try the release25-maint branch. If there are specific problems with it, please submit a new bug report. ---------------------------------------------------------------------- Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 19:19 Message: Logged In: YES user_id=1812047 Originator: YES As of the python2.5 build, the pcBuild8 directory did not function properly. I imported from the pcbuild directory and then did my changes from that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:17 Message: Logged In: YES user_id=21627 Originator: NO That's already available in the PCbuild8 directory. Closing as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733536&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:02:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:02:55 -0700 Subject: [ python-Bugs-1733518 ] setup.py incorrect for HP Message-ID: Bugs item #1733518, was opened at 2007-06-08 15:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py incorrect for HP Initial Comment: When building shared objects on HP, HP does not detect the shared object on link in the current directory unless it is told to. To fix this issue in setup.py the follow line needs to be added to the "def detect_modules() method: add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') to add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.library_dirs, './') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 21:02 Message: Logged In: YES user_id=21627 Originator: NO Ok. If you have non-standard build requirements, you are expected to adjust the build yourself. In general, editing Modules/Setup is the procedure you should use, rather than editing setup.py. Closing the report as wont-fix. ---------------------------------------------------------------------- Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 19:49 Message: Logged In: YES user_id=1812047 Originator: YES sorry, this was due to a bad zlib that was occuring. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:23 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug. Why do you have any libraries in the current directory that you want to link with? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733518&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:06:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:06:40 -0700 Subject: [ python-Bugs-1733544 ] HP 64 bit does not run Message-ID: Bugs item #1733544, was opened at 2007-06-08 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 Please note that this 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 Private: No Submitted By: Brad Hochstetler (bhochste) Assigned to: Nobody/Anonymous (nobody) Summary: HP 64 bit does not run Initial Comment: When building on HP(11.0 or 11.11) we unable to get a successful python interpreter to run, this is with python2.5. The problem seems to be due to changes to make the windows 64 bit build work. The integer sizes that are being returned for HP are bigger than what is allowed for python. Due to the sensitive area of this code, makeing this change caused alot of other errors to occur. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 21:06 Message: Logged In: YES user_id=21627 Originator: NO I can only repeat what I said there: please provide exact error messages, copying them literally from the screen. In any case, it's unlikely that this will get fixed, as there are no HP-UX experts around to look into the issue. ---------------------------------------------------------------------- Comment By: Brad Hochstetler (bhochste) Date: 2007-06-08 19:52 Message: Logged In: YES user_id=1812047 Originator: YES Here is a link to a discussion thread to see if anyone else had any information on the HP11 64 bit build on python2.5 http://groups.google.com/group/comp.lang.python/browse_thread/thread/1c9e61f222ac86ec/62586d476fdc4e24?lnk=st&q=bhochstetler&rnum=1#62586d476fdc4e24 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:21 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide a precise description of the problem: what did you do, what happened, what did you expect to happen instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733544&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:34:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:34:01 -0700 Subject: [ python-Bugs-1700455 ] ctypes Fundamental data types Message-ID: Bugs item #1700455, was opened at 2007-04-14 05:16 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700455&group_id=5470 Please note that this 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 Private: No Submitted By: hg6980 (hg6980) Assigned to: Thomas Heller (theller) Summary: ctypes Fundamental data types Initial Comment: I think the sentence:- The current memory block contents can be accessed (or changed) with the raw property, if you want to access it as NUL terminated string, use the string property should be The current memory block contents can be accessed (or changed) with the raw property, if you want to access it as NUL terminated string, use the value property ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 21:34 Message: Logged In: YES user_id=11105 Originator: NO Fixed now in trunk (rev 55833) and release25-maint (rev 55835). Thanks for the patch. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2007-04-16 14:15 Message: Logged In: YES user_id=888261 Originator: NO That may be technical correct, but such punctuation cannot be right. It should be... The current memory block contents can be accessed (or changed) with the raw property; if you want to access it as NUL terminated string, use the value property. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-04-14 21:06 Message: Logged In: YES user_id=21627 Originator: NO Thomas, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700455&group_id=5470 From noreply at sourceforge.net Sat Jun 9 06:35:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 21:35:42 -0700 Subject: [ python-Bugs-1733943 ] Tkinter is not working on trunk (2.6) Message-ID: Bugs item #1733943, was opened at 2007-06-09 13: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=1733943&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter is not working on trunk (2.6) Initial Comment: Hello. I tried to run tk app on trunk, I got following error. /////////////////////////////////// // Code import Tkinter as Tk root = Tk.Tk() label = Tk.Label(root, text="Test") label.pack(fill=Tk.BOTH, expand=True) root.mainloop() /////////////////////////////////// // Error Traceback (most recent call last): File "\debug.py", line 6, in label = Tk.Label(root, text="Test") File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 2464, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 1930, in __init__ (widgetName, self._w) + extra + self._options(cnf)) _tkinter.TclError: invalid command name "label .12893496 -text Test" This is due to the change revision 55504 (Stop using METH_OLDARGS) Currently, lib/lib-tk/Tkinter.py uses this convension 1929: self.tk.call( 1930: (widgetName, self._w) + extra + self._options(cnf)) ...passing argument as single tuple. METH_OLDARGS treats this as same as self.tk.call( widgetName, self._w, *(extra + self._options(cnf))) So it was working, but now METH_VARARGS, it doesn't expand single tuple as arguments. Maybe do we need to check all tk.call and apply patches like this? Index: Lib/lib-tk/Tkinter.py =================================================================== --- Lib/lib-tk/Tkinter.py (revision 55836) +++ Lib/lib-tk/Tkinter.py (working copy) @@ -1927,7 +1927,7 @@ classes.append((k, cnf[k])) del cnf[k] self.tk.call( - (widgetName, self._w) + extra + self._options(cnf)) + widgetName, self._w, *(extra + self._options(cnf))) for k, v in classes: k.configure(self, v) def destroy(self): # Maybe already someone working on this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733943&group_id=5470 From noreply at sourceforge.net Sat Jun 9 07:19:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 22:19:10 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 07:04 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-09 02:19 Message: Logged In: YES user_id=479790 Originator: NO Quoting RFC2822 section 2.2.3 : """The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test [...]Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP.""" That is, folding is done by inserting ONLY the sequence CRLF before any folding whitespace. When the header is interpreted, the whitespace is NOT removed, only the CRLF. The posted Subject header should become "Subject: 1 2 3...7 8\n\r 9 1 2...' I think this is a bug in the email.header.Header class; its __init__ says, about the continuation_ws argument: "[it] must be RFC 2822 compliant folding whitespace (usually either a space or a hard tab) which will be prepended to continuation lines.". Folding does not involve *prepending* any whitespace, just inserting CRLF right before *existing* whitespace. Note that this is wrong even for the old RFC 822 (with slightly different rules for line folding.) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2007-06-08 09:11 Message: Logged In: YES user_id=972995 Originator: YES What would be the RFC definition for a correct auto-line break in a (subject) mail header line? Wouldn't it be more simple to not do any auto-line break for the subject? or is there a requirement for the line break in the RFC. Don't think any reader program would fail because of >79 char subject header lines. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 18:17 Message: Logged In: YES user_id=12800 Originator: NO Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 18:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Sat Jun 9 08:52:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 23:52:33 -0700 Subject: [ python-Bugs-1732557 ] T_LONGLONG chokes on ints Message-ID: Bugs item #1732557, was opened at 2007-06-06 23:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: T_LONGLONG chokes on ints Initial Comment: Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a plain int, and give a misleading error msg: TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2007-06-09 01:52 Message: Logged In: YES user_id=771074 Originator: YES Submitted patch# 1733960 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 12:54 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 From noreply at sourceforge.net Sat Jun 9 09:01:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 00:01:53 -0700 Subject: [ python-Bugs-1729277 ] SVNVERSION redefined during compilation Message-ID: Bugs item #1729277, was opened at 2007-06-01 04:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 Please note that this 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.6 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj?n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-08 01:58 Message: Logged In: YES user_id=1262199 Originator: NO Applied the patch in change 55821, and backported to 25-maint in 55822 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 19:23 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me, please apply. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-05 14:18 Message: Logged In: YES user_id=1262199 Originator: NO Here is a suggested patch. I don't have a linux setup to test with this, what do you think? Oh, and sorry for messing this up, I thought subwcrev was used on all platforms :( File Added: woo.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-05 09:50 Message: Logged In: YES user_id=21627 Originator: NO The define is indeed needed on Windows. On a Windows installation, there is typically no svnversion binary. However, TortoiseSVN ships with a similar tool, calls subwcrev.exe, which does string interpolation on a template file. So the define in getbuildinfo is the template, and the link process creates a second C file (getbuildinfo1.c) which is then compiled and linked into the interpreter. As subwcrev.exe might not be installed, the build process used to pass a define SUBWCREV on the command line, which was a condition to the definition of SVNVERSION. As Kristjan removed the condition, the Unix build broke. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 23:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in ------------------------------------------------------------------------ r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. ------------------------------------------------------------------------ Kristjan, what was the rationale for making that specific change to getbuildinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 From noreply at sourceforge.net Sat Jun 9 09:40:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 00:40:48 -0700 Subject: [ python-Bugs-1733943 ] Tkinter is not working on trunk (2.6) Message-ID: Bugs item #1733943, was opened at 2007-06-09 04:35 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733943&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) >Assigned to: Neal Norwitz (nnorwitz) Summary: Tkinter is not working on trunk (2.6) Initial Comment: Hello. I tried to run tk app on trunk, I got following error. /////////////////////////////////// // Code import Tkinter as Tk root = Tk.Tk() label = Tk.Label(root, text="Test") label.pack(fill=Tk.BOTH, expand=True) root.mainloop() /////////////////////////////////// // Error Traceback (most recent call last): File "\debug.py", line 6, in label = Tk.Label(root, text="Test") File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 2464, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 1930, in __init__ (widgetName, self._w) + extra + self._options(cnf)) _tkinter.TclError: invalid command name "label .12893496 -text Test" This is due to the change revision 55504 (Stop using METH_OLDARGS) Currently, lib/lib-tk/Tkinter.py uses this convension 1929: self.tk.call( 1930: (widgetName, self._w) + extra + self._options(cnf)) ...passing argument as single tuple. METH_OLDARGS treats this as same as self.tk.call( widgetName, self._w, *(extra + self._options(cnf))) So it was working, but now METH_VARARGS, it doesn't expand single tuple as arguments. Maybe do we need to check all tk.call and apply patches like this? Index: Lib/lib-tk/Tkinter.py =================================================================== --- Lib/lib-tk/Tkinter.py (revision 55836) +++ Lib/lib-tk/Tkinter.py (working copy) @@ -1927,7 +1927,7 @@ classes.append((k, cnf[k])) del cnf[k] self.tk.call( - (widgetName, self._w) + extra + self._options(cnf)) + widgetName, self._w, *(extra + self._options(cnf))) for k, v in classes: k.configure(self, v) def destroy(self): # Maybe already someone working on this? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-09 07:40 Message: Logged In: YES user_id=849994 Originator: NO Neal, you did that change... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733943&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:06:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:06:19 -0700 Subject: [ python-Bugs-1732557 ] T_LONGLONG chokes on ints Message-ID: Bugs item #1732557, was opened at 2007-06-07 06:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: T_LONGLONG chokes on ints Initial Comment: Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a plain int, and give a misleading error msg: TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-09 10:06 Message: Logged In: YES user_id=21627 Originator: NO This is now fixed with said patch. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-06-09 08:52 Message: Logged In: YES user_id=771074 Originator: YES Submitted patch# 1733960 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-08 19:54 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:48:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:48:22 -0700 Subject: [ python-Bugs-1733757 ] RuntimeWarning: tp_compare didn't return -1 or -2 Message-ID: Bugs item #1733757, was opened at 2007-06-08 21:58 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabio Zadrozny (fabioz) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning: tp_compare didn't return -1 or -2 Initial Comment: The code attached is giving the error below D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return -1 or -2 for exception return _active[_get_ident()] Exception exceptions.SystemError: 'error return without exception set' in ignored Ok, I have no clues why there could be an error here... ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 11:48 Message: Logged In: YES user_id=231480 Originator: NO Bug #1733973 is related. What is happening in this bug, is that tokenize.tokenize is using generate_tokens to generate the tokens. Since tokeneater() fails while the iteration is occuring, the exception is raised and it unwinds the tokenize() call. This garbage collects the generate_tokens generator -- which throws a GeneratorExit into the generator. This time, sysmodule.c's trace_trampoline is the one assuming it can overwrite PyErr_*. Maybe the correct way of fixing the bug is saving+clearing/restoring PyErr_* in ceval.c:call_trace, rather than in each trace/profile handler. The upside is that they all seem to assume that they can overwrite PyErr_* and this will fix them all. The downside is that the PyErr_* that's been set in the frame will not be accessible to the trace function. This can be fixed by storing it in some global. Basically, the fix is to call PyErr_Fetch before the trace/profile func, and PyErr_Restore after it. The problem is that the trace/profile func is a function ptr in the PyThreadState that's used by more than Python's ceval.c. It seems to be liberally used by pyexpat and others. This means that this function pointer should always point at the wrapper function rather than the given function, which means storing more information in the thread state, and then extracting it from the thread state again. This got more complicated and intricate than I intended, and the whole thing has a wrong feel to it - as it seems to me that all calls to the trace/profile func should be in one centralized place, and that place should be wrapped. I hope someone else will implement the fix or at least comment on this. If anyone is not clear on what the fix is, please post questions (and if this bug system has mailing notifications) and I'll further explain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:53:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:53:53 -0700 Subject: [ python-Bugs-1733986 ] mmap.mmap can overrun buffer Message-ID: Bugs item #1733986, was opened at 2007-06-09 03: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=1733986&group_id=5470 Please note that this 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 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: mmap.mmap can overrun buffer Initial Comment: When opening a named mapping (windows only) that already exists, the size is ignored but the constructor assumes the passed-in size is the buffer size. If you specify a size larger than the original, the reopened mapping can write past the end of the valid buffer, resulting in a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733986&group_id=5470 From noreply at sourceforge.net Sat Jun 9 17:53:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 08:53:32 -0700 Subject: [ python-Bugs-1734111 ] struct.Struct.size is not documented Message-ID: Bugs item #1734111, was opened at 2007-06-09 23: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=1734111&group_id=5470 Please note that this 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 Private: No Submitted By: Yang Yang (wdscxsj) Assigned to: Nobody/Anonymous (nobody) Summary: struct.Struct.size is not documented Initial Comment: In Python 2.5 documentation, a description for struct.Struct.size is missing, although this member has been quoted in descriptions for struct.Struct.pack, struct.Struct.unpack, and struct.Struct.unpack_from. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734111&group_id=5470 From report at bugs.python.org Sat Jun 9 18:56:23 2007 From: report at bugs.python.org (admin) Date: Sat, 09 Jun 2007 16:56:23 -0000 Subject: [issue1001] New issue test for email Message-ID: <1181408183.68.0.0799376209997.issue1001@psf.upfronthosting.co.za> Changes by admin: ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From noreply at sourceforge.net Sat Jun 9 20:46:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 11:46:48 -0700 Subject: [ python-Bugs-1734164 ] sqlite3 causes memory read error Message-ID: Bugs item #1734164, was opened at 2007-06-10 03: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=1734164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 causes memory read error Initial Comment: Attached script causes memory read error at sqlite3.pyd. Tested on Python 2.5.1/Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&group_id=5470 From noreply at sourceforge.net Sun Jun 10 22:56:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 13:56:15 -0700 Subject: [ python-Bugs-1734164 ] sqlite3 causes memory read error Message-ID: Bugs item #1734164, was opened at 2007-06-09 11:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 causes memory read error Initial Comment: Attached script causes memory read error at sqlite3.pyd. Tested on Python 2.5.1/Windows XP. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-10 13:56 Message: Logged In: YES user_id=33168 Originator: NO I can't reproduce this on Linux with valgrind. Did you use purify to find this problem? Can you provide the complete report that shows the memory read error with the call stack? Are you sure the problem is in the python code? Could the problem be in the sqlite code itself? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&group_id=5470 From noreply at sourceforge.net Mon Jun 11 01:45:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 16:45:36 -0700 Subject: [ python-Bugs-1731068 ] Importing a submodule fails after unloading its parent Message-ID: Bugs item #1731068, was opened at 2007-06-04 20:21 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: Importing a submodule fails after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-10 20:45 Message: Logged In: YES user_id=479790 Originator: NO The same example works OK for me on 2.5.1 on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 From noreply at sourceforge.net Mon Jun 11 04:32:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 19:32:41 -0700 Subject: [ python-Bugs-1734723 ] Repr class from repr module ignores maxtuple attribute Message-ID: Bugs item #1734723, was opened at 2007-06-11 02: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=1734723&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Roberts (jasonjroberts) Assigned to: Nobody/Anonymous (nobody) Summary: Repr class from repr module ignores maxtuple attribute Initial Comment: The Repr class from the repr module is supposed limit the number of tuple items dumped to the value of the maxtuple attribute. But it uses the value of the maxlist attribute instead: def repr_tuple(self, x, level): return self._repr_iterable(x, level, '(', ')', self.maxlist, ',') As a result: >>> import sys >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' >>> import repr >>> r = repr.Repr() >>> r.maxtuple 6 >>> r.maxlist 6 >>> r.maxtuple = 3 >>> r.repr((1,2,3,4,5,6,7,8,9)) # Will print 6 items, not 3 '(1, 2, 3, 4, 5, 6, ...)' >>> r.maxlist = 3 >>> r.repr((1,2,3,4,5,6,7,8,9)) # Now will print 3 items '(1, 2, 3, ...)' The implementation of repr_tuple should be changed to: def repr_tuple(self, x, level): return self._repr_iterable(x, level, '(', ')', self.maxtuple, ',') Obviously this is not a major issue if nobody has noticed it by now. But it would be nice to correct the implementation to match the documentation. In my scenario, I want to dump out all of the items of a tuple but only three items from any embedded list. Something like this: >>> x = (......) >>> import repr >>> r = repr.Repr() >>> r.maxtuple = 255 >>> r.maxlist = 3 >>> print r.repr(x) But because maxlist controls both the dumping of lists and of tuples, I have to choose between only dumping a few items of the tuple and having small lists, or dumping all of the items in the tuple and having large lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734723&group_id=5470 From noreply at sourceforge.net Mon Jun 11 05:26:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 20:26:29 -0700 Subject: [ python-Bugs-1734732 ] Tutorial Section 6.4 Message-ID: Bugs item #1734732, was opened at 2007-06-10 22: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=1734732&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric Naeseth (enaeseth) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial Section 6.4 Initial Comment: The package names in the example given in section 6.4 are currently capitalized. It might be better to make them lower-case in agreement with Python naming conventions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734732&group_id=5470 From noreply at sourceforge.net Mon Jun 11 05:26:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 20:26:49 -0700 Subject: [ python-Bugs-1734732 ] Tutorial Section 6.4 Message-ID: Bugs item #1734732, was opened at 2007-06-10 22:26 Message generated for change (Settings changed) made by enaeseth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734732&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Eric Naeseth (enaeseth) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial Section 6.4 Initial Comment: The package names in the example given in section 6.4 are currently capitalized. It might be better to make them lower-case in agreement with Python naming conventions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734732&group_id=5470 From noreply at sourceforge.net Mon Jun 11 07:37:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 22:37:13 -0700 Subject: [ python-Bugs-1734732 ] Tutorial Section 6.4 Message-ID: Bugs item #1734732, was opened at 2007-06-10 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=1734732&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Eric Naeseth (enaeseth) >Assigned to: Neal Norwitz (nnorwitz) Summary: Tutorial Section 6.4 Initial Comment: The package names in the example given in section 6.4 are currently capitalized. It might be better to make them lower-case in agreement with Python naming conventions. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-10 22:37 Message: Logged In: YES user_id=33168 Originator: NO Thanks! Let us know if you find any more problems. Committed revision 55882. Committed revision 55883. (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734732&group_id=5470 From noreply at sourceforge.net Mon Jun 11 09:34:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 00:34:31 -0700 Subject: [ python-Bugs-1734723 ] Repr class from repr module ignores maxtuple attribute Message-ID: Bugs item #1734723, was opened at 2007-06-10 19:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734723&group_id=5470 Please note that this 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 Private: No Submitted By: Jason Roberts (jasonjroberts) >Assigned to: Neal Norwitz (nnorwitz) Summary: Repr class from repr module ignores maxtuple attribute Initial Comment: The Repr class from the repr module is supposed limit the number of tuple items dumped to the value of the maxtuple attribute. But it uses the value of the maxlist attribute instead: def repr_tuple(self, x, level): return self._repr_iterable(x, level, '(', ')', self.maxlist, ',') As a result: >>> import sys >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' >>> import repr >>> r = repr.Repr() >>> r.maxtuple 6 >>> r.maxlist 6 >>> r.maxtuple = 3 >>> r.repr((1,2,3,4,5,6,7,8,9)) # Will print 6 items, not 3 '(1, 2, 3, 4, 5, 6, ...)' >>> r.maxlist = 3 >>> r.repr((1,2,3,4,5,6,7,8,9)) # Now will print 3 items '(1, 2, 3, ...)' The implementation of repr_tuple should be changed to: def repr_tuple(self, x, level): return self._repr_iterable(x, level, '(', ')', self.maxtuple, ',') Obviously this is not a major issue if nobody has noticed it by now. But it would be nice to correct the implementation to match the documentation. In my scenario, I want to dump out all of the items of a tuple but only three items from any embedded list. Something like this: >>> x = (......) >>> import repr >>> r = repr.Repr() >>> r.maxtuple = 255 >>> r.maxlist = 3 >>> print r.repr(x) But because maxlist controls both the dumping of lists and of tuples, I have to choose between only dumping a few items of the tuple and having small lists, or dumping all of the items in the tuple and having large lists. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-11 00:34 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report Jason! Committed revision 55887. Committed revision 55888. (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734723&group_id=5470 From noreply at sourceforge.net Mon Jun 11 10:28:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:28:46 -0700 Subject: [ python-Bugs-1733757 ] RuntimeWarning: tp_compare didn't return -1 or -2 Message-ID: Bugs item #1733757, was opened at 2007-06-08 18:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabio Zadrozny (fabioz) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning: tp_compare didn't return -1 or -2 Initial Comment: The code attached is giving the error below D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return -1 or -2 for exception return _active[_get_ident()] Exception exceptions.SystemError: 'error return without exception set' in ignored Ok, I have no clues why there could be an error here... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-11 08:28 Message: Logged In: YES user_id=849994 Originator: NO Note that there is already a call_trace_protected in ceval.c which saves/restores the exception, it just doesn't seem to be called in this instance. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 08:48 Message: Logged In: YES user_id=231480 Originator: NO Bug #1733973 is related. What is happening in this bug, is that tokenize.tokenize is using generate_tokens to generate the tokens. Since tokeneater() fails while the iteration is occuring, the exception is raised and it unwinds the tokenize() call. This garbage collects the generate_tokens generator -- which throws a GeneratorExit into the generator. This time, sysmodule.c's trace_trampoline is the one assuming it can overwrite PyErr_*. Maybe the correct way of fixing the bug is saving+clearing/restoring PyErr_* in ceval.c:call_trace, rather than in each trace/profile handler. The upside is that they all seem to assume that they can overwrite PyErr_* and this will fix them all. The downside is that the PyErr_* that's been set in the frame will not be accessible to the trace function. This can be fixed by storing it in some global. Basically, the fix is to call PyErr_Fetch before the trace/profile func, and PyErr_Restore after it. The problem is that the trace/profile func is a function ptr in the PyThreadState that's used by more than Python's ceval.c. It seems to be liberally used by pyexpat and others. This means that this function pointer should always point at the wrapper function rather than the given function, which means storing more information in the thread state, and then extracting it from the thread state again. This got more complicated and intricate than I intended, and the whole thing has a wrong feel to it - as it seems to me that all calls to the trace/profile func should be in one centralized place, and that place should be wrapped. I hope someone else will implement the fix or at least comment on this. If anyone is not clear on what the fix is, please post questions (and if this bug system has mailing notifications) and I'll further explain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&group_id=5470 From noreply at sourceforge.net Mon Jun 11 10:31:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:31:28 -0700 Subject: [ python-Bugs-1734164 ] sqlite3 causes memory read error Message-ID: Bugs item #1734164, was opened at 2007-06-10 03:46 Message generated for change (Comment added) made by ishimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 causes memory read error Initial Comment: Attached script causes memory read error at sqlite3.pyd. Tested on Python 2.5.1/Windows XP. ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2007-06-11 17:31 Message: Logged In: YES user_id=463672 Originator: YES Purify is not needed to find this problem, since python aborts by running test script. VisualC++ reports memory read error occurred. Problem might be in the sqlite, not sqlite3. I'm not sure which is. I failed to find this problem at sqlite's trac. Here's stack trace:: sqlite3.dll!60931bb0() _sqlite3.pyd!00ac5887() _sqlite3.pyd!00ac589e() _sqlite3.pyd!00ac3e6f() _sqlite3.pyd!00ac4251() python25.dll!PyCFunction_Call(_object * func=0x00bedd78, _object * arg=0x00be66f0, _object * kw=0x00000000) ? 73 + 0x8 C python25.dll!call_function(_object * * * pp_stack=0x0021fdc0, int oparg=0) ? 3564 + 0x8f C python25.dll!PyEval_EvalFrameEx(_frame * f=0x00ba89e8, int throwflag=0) ? 2270 C python25.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x00bcae30, _object * globals=0x00ba89e8, _object * locals=0x00b7cdb0, _object * * args=0x00000000, int argcount=0, _object * * kws=0x00000000, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000) ? 2831 + 0x8 C python25.dll!PyEval_EvalCode(PyCodeObject * co=0x00bcae30, _object * globals=0x00b7cdb0, _object * locals=0x00b7cdb0) ? 499 + 0x22 C python25.dll!run_mod(_mod * mod=0x00c48538, const char * filename=0x00bec770, _object * globals=0x00b7cdb0, _object * locals=0x00b7cdb0, PyCompilerFlags * flags=0xbdf20da3, _arena * arena=0x00000000) ? 1271 + 0x11 C python25.dll!PyRun_FileExFlags(_iobuf * fp=0x7c3ab698, const char * filename=0x00ab3e4b, int start=257, _object * globals=0x00b7cdb0, _object * locals=0x00b7cdb0, int closeit=1, PyCompilerFlags * flags=0x0021ff1c) ? 1258 C python25.dll!PyRun_SimpleFileExFlags(_iobuf * fp=0x7c3ab698, const char * filename=0x00ab3e4b, int closeit=1, PyCompilerFlags * flags=0x0021ff1c) ? 878 + 0x18 C python25.dll!PyRun_AnyFileExFlags(_iobuf * fp=0x7c3ab698, const char * filename=0x00ab3e4b, int closeit=1, PyCompilerFlags * flags=0x0021ff1c) ? 696 + 0x11 C python25.dll!Py_Main(int argc=2, char * * argv=0x00000001) ? 526 + 0x21 C python.exe!1d0011a5() kernel32.dll!7c816fd7() ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-11 05:56 Message: Logged In: YES user_id=33168 Originator: NO I can't reproduce this on Linux with valgrind. Did you use purify to find this problem? Can you provide the complete report that shows the memory read error with the call stack? Are you sure the problem is in the python code? Could the problem be in the sqlite code itself? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&group_id=5470 From noreply at sourceforge.net Mon Jun 11 11:33:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 02:33:44 -0700 Subject: [ python-Bugs-1734860 ] sitecustomize.py not found Message-ID: Bugs item #1734860, was opened at 2007-06-11 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=1734860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: www.spirito.de (openspirito) Assigned to: Nobody/Anonymous (nobody) Summary: sitecustomize.py not found Initial Comment: Under my configuration (Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32) the sitecustomize.py is not found in the current directory. I added some testing code into site.def execsitecustomize() and found out, that the current path is not part of sys.path, but later on in the main program it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 From noreply at sourceforge.net Tue Jun 12 02:19:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 17:19:09 -0700 Subject: [ python-Bugs-1735418 ] file.read() truncating strings under Windows Message-ID: Bugs item #1735418, was opened at 2007-06-12 00: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=1735418&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 From noreply at sourceforge.net Tue Jun 12 08:48:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 23:48:20 -0700 Subject: [ python-Feature Requests-1735509 ] Newer reply format for imap commands in imaplib.py Message-ID: Feature Requests item #1735509, was opened at 2007-06-12 02: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=1735509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Naoyuki Tai (ntai) Assigned to: Nobody/Anonymous (nobody) Summary: Newer reply format for imap commands in imaplib.py Initial Comment: If the fetch command does not contain literal, the result is [ '1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)', '2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)'] If the fetch command contains literal, the result is [ ('1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'), ')', ('2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'), ')'] First off, the number of elements in the reply becomes twice of non-literal fetch command. Secondly, to parse the attribute string like "(FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)" , one must check the first and last character to be '(' and ')' for the correctness of reply. With the second type of reply / the reply with literal, the reply string needs to be reconstructed out of the first element of tuple in an element, the subsequent element by appending them. If the number of elements in the reply matches with the number of mails fetched, I can deal with the reply a lot easier. As the shape of fetch command output is very different depending on literal, the use of fetch() is too hard for its good. Therefore, I propose the new response format. fetch_status, [ entry1, entry2, entry3, ... ] And each entry is [entry-reply] or [entry-reply, [literals]] This allows that you can get to the entry reply uniformly regardless of whether or not the query of fetch with or without literal response. Since the proposed response format is not compatible with existing format, additional proposal is to let the user of imaplib.py to designate the response format, as existing format as 1, and the new format as 2. I have attached a patch for the proposed change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1735509&group_id=5470 From noreply at sourceforge.net Tue Jun 12 09:06:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 00:06:22 -0700 Subject: [ python-Feature Requests-1735509 ] Newer reply format for imap commands in imaplib.py Message-ID: Feature Requests item #1735509, was opened at 2007-06-12 02:48 Message generated for change (Comment added) made by ntai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1735509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Naoyuki Tai (ntai) Assigned to: Nobody/Anonymous (nobody) Summary: Newer reply format for imap commands in imaplib.py Initial Comment: If the fetch command does not contain literal, the result is [ '1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)', '2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)'] If the fetch command contains literal, the result is [ ('1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'), ')', ('2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'), ')'] First off, the number of elements in the reply becomes twice of non-literal fetch command. Secondly, to parse the attribute string like "(FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)" , one must check the first and last character to be '(' and ')' for the correctness of reply. With the second type of reply / the reply with literal, the reply string needs to be reconstructed out of the first element of tuple in an element, the subsequent element by appending them. If the number of elements in the reply matches with the number of mails fetched, I can deal with the reply a lot easier. As the shape of fetch command output is very different depending on literal, the use of fetch() is too hard for its good. Therefore, I propose the new response format. fetch_status, [ entry1, entry2, entry3, ... ] And each entry is [entry-reply] or [entry-reply, [literals]] This allows that you can get to the entry reply uniformly regardless of whether or not the query of fetch with or without literal response. Since the proposed response format is not compatible with existing format, additional proposal is to let the user of imaplib.py to designate the response format, as existing format as 1, and the new format as 2. I have attached a patch for the proposed change. ---------------------------------------------------------------------- >Comment By: Naoyuki Tai (ntai) Date: 2007-06-12 03:06 Message: Logged In: YES user_id=1577886 Originator: YES I overlooked that IMAP4_SSL needs the same enhancement. IMAP4_SSL's constructor should look like as follows. def __init__(self, host = '', port = IMAP4_SSL_PORT, keyfile = None, certfile = None, response_format = 1): self.keyfile = keyfile self.certfile = certfile IMAP4.__init__(self, host, port, response_format) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1735509&group_id=5470 From noreply at sourceforge.net Tue Jun 12 11:35:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 02:35:03 -0700 Subject: [ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP Message-ID: Bugs item #1704793, was opened at 2007-04-21 12:52 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 Please note that this 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: 6 Private: No Submitted By: vbr (vlbrom) >Assigned to: Martin v. L?wis (loewis) Summary: incorrect return value of unicodedata.lookup() - beoynd BMP Initial Comment: There seem to be an incorrect handling of unicode characters beyond the BMP (code point higher than 0xFFFF) in the unicodedata module - function lookup() on narrow unicode python builds (python 2.5.1, Windows XPh) >>> unicodedata.lookup("GOTHIC LETTER FAIHU") u'\u0346' (should be u'\U00010346' - the beginning of the literal is truncated - leading to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING BRIDGE ABOVE") on the contrary, the unicode string literals \N{name} work well. >>> u"\N{GOTHIC LETTER FAIHU}" u'\U00010346' Unfortunately, I haven't been able to find the problematic pieces of sourcecode, so I'm not able to fix it. It seems, that initially the correct information on the given codepoint is used, but finally only the last four digits of the codepoint value are taken into account using the "narrow" unicode literal \uxxxx instead of \Uxxxxxxxx , while the same task is handled correctly by the unicodeescape codec used for unicode string literals. vbr ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 11:35 Message: Logged In: YES user_id=38388 Originator: NO Martin, please have a look. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-04-21 22:29 Message: Logged In: YES user_id=849994 Originator: NO Confirmed with an linux-x86 UCS-4 build here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 From noreply at sourceforge.net Tue Jun 12 12:20:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 03:20:25 -0700 Subject: [ python-Bugs-1735632 ] Add O_NOATIME to os module Message-ID: Bugs item #1735632, was opened at 2007-06-12 10: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=1735632&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: sam morris (cortana) Assigned to: Nobody/Anonymous (nobody) Summary: Add O_NOATIME to os module Initial Comment: Please add a constant for O_NOATIME to the os module. -- Macro: int O_NOATIME If this bit is set, `read' will not update the access time of the file. *Note File Times::. This is used by programs that do backups, so that backing a file up does not count as reading it. Only the owner of the file or the superuser may use this bit. and possibly even a new character to the 'mode' paramter of the builtin 'open' function to do the same thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735632&group_id=5470 From noreply at sourceforge.net Tue Jun 12 13:12:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 04:12:55 -0700 Subject: [ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP Message-ID: Bugs item #1704793, was opened at 2007-04-21 19:52 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 Please note that this 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: 6 Private: No Submitted By: vbr (vlbrom) Assigned to: Martin v. L?wis (loewis) Summary: incorrect return value of unicodedata.lookup() - beoynd BMP Initial Comment: There seem to be an incorrect handling of unicode characters beyond the BMP (code point higher than 0xFFFF) in the unicodedata module - function lookup() on narrow unicode python builds (python 2.5.1, Windows XPh) >>> unicodedata.lookup("GOTHIC LETTER FAIHU") u'\u0346' (should be u'\U00010346' - the beginning of the literal is truncated - leading to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING BRIDGE ABOVE") on the contrary, the unicode string literals \N{name} work well. >>> u"\N{GOTHIC LETTER FAIHU}" u'\U00010346' Unfortunately, I haven't been able to find the problematic pieces of sourcecode, so I'm not able to fix it. It seems, that initially the correct information on the given codepoint is used, but finally only the last four digits of the codepoint value are taken into account using the "narrow" unicode literal \uxxxx instead of \Uxxxxxxxx , while the same task is handled correctly by the unicodeescape codec used for unicode string literals. vbr ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-06-12 20:12 Message: Logged In: YES user_id=55188 Originator: NO I attached a working fix for the problem. The patch encodes non-BMP characters as a surrogate pair in the lookup function. The surrogate pair encoding can be thought as something to be included in the standard unicode API. How about to provide UTF-32 codecs in the Python C-API to help this kind of use? File Added: unicodedata-lookup-ucs2fix.diff ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 18:35 Message: Logged In: YES user_id=38388 Originator: NO Martin, please have a look. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-04-22 05:29 Message: Logged In: YES user_id=849994 Originator: NO Confirmed with an linux-x86 UCS-4 build here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 From noreply at sourceforge.net Tue Jun 12 17:47:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 08:47:35 -0700 Subject: [ python-Bugs-1735418 ] file.read() truncating strings under Windows Message-ID: Bugs item #1735418, was opened at 2007-06-11 20:19 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:47 Message: Logged In: YES user_id=281701 Originator: NO This is your coding bug. (a) I would not trust tell(). Calculate the absolute position and use seek(). (b) Just from the documentation to Python's file-like objects I can assume that read() and tell() belong to different levels of API. The read() function has this in its documentation: "Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible". http://docs.python.org/lib/bltin-file-objects.html The tell() function's documentation refers to stdio's ftell(). This hints that tell() will return the position of the fread() buffer's end, not the read()'s end. (c) It also appears that by adding 1 to the "current position - unget size" you are skipping the space character itself. (d) The rfind() might return -1 if the search fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 From noreply at sourceforge.net Tue Jun 12 17:51:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 08:51:53 -0700 Subject: [ python-Bugs-1735418 ] file.read() truncating strings under Windows Message-ID: Bugs item #1735418, was opened at 2007-06-11 20:19 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:51 Message: Logged In: YES user_id=281701 Originator: NO (e) To have tell() on the same level with read(), try the unbuffered mode by specifying bufsize=0 in open(), http://docs.python.org/lib/built-in-funcs.html ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 11:47 Message: Logged In: YES user_id=281701 Originator: NO This is your coding bug. (a) I would not trust tell(). Calculate the absolute position and use seek(). (b) Just from the documentation to Python's file-like objects I can assume that read() and tell() belong to different levels of API. The read() function has this in its documentation: "Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible". http://docs.python.org/lib/bltin-file-objects.html The tell() function's documentation refers to stdio's ftell(). This hints that tell() will return the position of the fread() buffer's end, not the read()'s end. (c) It also appears that by adding 1 to the "current position - unget size" you are skipping the space character itself. (d) The rfind() might return -1 if the search fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 From noreply at sourceforge.net Tue Jun 12 23:12:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 14:12:03 -0700 Subject: [ python-Bugs-1736103 ] Mac build fails if not building universal due to libtool Message-ID: Bugs item #1736103, was opened at 2007-06-12 23: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=1736103&group_id=5470 Please note that this 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 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac build fails if not building universal due to libtool Initial Comment: If you try to build the svn trunk without universalsdk the make will fail: the Makefile tries to use libtool to create the shared library, but on (unmodified) OSX it should use glibtool. I have no idea who to assign this to, I hope you have a bettter idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 From noreply at sourceforge.net Wed Jun 13 06:25:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 21:25:36 -0700 Subject: [ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP Message-ID: Bugs item #1704793, was opened at 2007-04-21 12:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 Please note that this 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: 6 Private: No Submitted By: vbr (vlbrom) Assigned to: Martin v. L?wis (loewis) Summary: incorrect return value of unicodedata.lookup() - beoynd BMP Initial Comment: There seem to be an incorrect handling of unicode characters beyond the BMP (code point higher than 0xFFFF) in the unicodedata module - function lookup() on narrow unicode python builds (python 2.5.1, Windows XPh) >>> unicodedata.lookup("GOTHIC LETTER FAIHU") u'\u0346' (should be u'\U00010346' - the beginning of the literal is truncated - leading to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING BRIDGE ABOVE") on the contrary, the unicode string literals \N{name} work well. >>> u"\N{GOTHIC LETTER FAIHU}" u'\U00010346' Unfortunately, I haven't been able to find the problematic pieces of sourcecode, so I'm not able to fix it. It seems, that initially the correct information on the given codepoint is used, but finally only the last four digits of the codepoint value are taken into account using the "narrow" unicode literal \uxxxx instead of \Uxxxxxxxx , while the same task is handled correctly by the unicodeescape codec used for unicode string literals. vbr ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-13 06:25 Message: Logged In: YES user_id=21627 Originator: NO gbrandl: what precisely can you confirm? In any UCS-4 build, the lookup should return the correct result, and it does so on my machine. An alternative solution to the change proposed by perky would be to raise a ValueError, similar to unichr(). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-06-12 13:12 Message: Logged In: YES user_id=55188 Originator: NO I attached a working fix for the problem. The patch encodes non-BMP characters as a surrogate pair in the lookup function. The surrogate pair encoding can be thought as something to be included in the standard unicode API. How about to provide UTF-32 codecs in the Python C-API to help this kind of use? File Added: unicodedata-lookup-ucs2fix.diff ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 11:35 Message: Logged In: YES user_id=38388 Originator: NO Martin, please have a look. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-04-21 22:29 Message: Logged In: YES user_id=849994 Originator: NO Confirmed with an linux-x86 UCS-4 build here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 From noreply at sourceforge.net Wed Jun 13 08:37:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 23:37:49 -0700 Subject: [ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP Message-ID: Bugs item #1704793, was opened at 2007-04-21 10:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 Please note that this 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: 6 Private: No Submitted By: vbr (vlbrom) Assigned to: Martin v. L?wis (loewis) Summary: incorrect return value of unicodedata.lookup() - beoynd BMP Initial Comment: There seem to be an incorrect handling of unicode characters beyond the BMP (code point higher than 0xFFFF) in the unicodedata module - function lookup() on narrow unicode python builds (python 2.5.1, Windows XPh) >>> unicodedata.lookup("GOTHIC LETTER FAIHU") u'\u0346' (should be u'\U00010346' - the beginning of the literal is truncated - leading to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING BRIDGE ABOVE") on the contrary, the unicode string literals \N{name} work well. >>> u"\N{GOTHIC LETTER FAIHU}" u'\U00010346' Unfortunately, I haven't been able to find the problematic pieces of sourcecode, so I'm not able to fix it. It seems, that initially the correct information on the given codepoint is used, but finally only the last four digits of the codepoint value are taken into account using the "narrow" unicode literal \uxxxx instead of \Uxxxxxxxx , while the same task is handled correctly by the unicodeescape codec used for unicode string literals. vbr ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-13 06:37 Message: Logged In: YES user_id=849994 Originator: NO Indeed, it is UCS-2, sorry. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-13 04:25 Message: Logged In: YES user_id=21627 Originator: NO gbrandl: what precisely can you confirm? In any UCS-4 build, the lookup should return the correct result, and it does so on my machine. An alternative solution to the change proposed by perky would be to raise a ValueError, similar to unichr(). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-06-12 11:12 Message: Logged In: YES user_id=55188 Originator: NO I attached a working fix for the problem. The patch encodes non-BMP characters as a surrogate pair in the lookup function. The surrogate pair encoding can be thought as something to be included in the standard unicode API. How about to provide UTF-32 codecs in the Python C-API to help this kind of use? File Added: unicodedata-lookup-ucs2fix.diff ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 09:35 Message: Logged In: YES user_id=38388 Originator: NO Martin, please have a look. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-04-21 20:29 Message: Logged In: YES user_id=849994 Originator: NO Confirmed with an linux-x86 UCS-4 build here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470 From noreply at sourceforge.net Wed Jun 13 15:41:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 06:41:20 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 13:41 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=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Wed Jun 13 17:36:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 08:36:37 -0700 Subject: [ python-Bugs-1712522 ] urllib.quote throws exception on Unicode URL Message-ID: Bugs item #1712522, was opened at 2007-05-04 06:11 Message generated for change (Comment added) made by varmaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote throws exception on Unicode URL Initial Comment: The code in urllib.quote fails on Unicode input, when called by robotparser with a Unicode URL. Traceback (most recent call last): File "./sitetruth/InfoSitePage.py", line 415, in run pagetree = self.httpfetch() # fetch page File "./sitetruth/InfoSitePage.py", line 368, in httpfetch if not self.owner().checkrobotaccess(self.requestedurl) : # if access disallowed by robots.txt file File "./sitetruth/InfoSiteContent.py", line 446, in checkrobotaccess return(self.robotcheck.can_fetch(config.kuseragent, url)) # return can fetch File "/usr/local/lib/python2.5/robotparser.py", line 159, in can_fetch url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/" File "/usr/local/lib/python2.5/urllib.py", line 1197, in quote res = map(safe_map.__getitem__, s) KeyError: u'\xe2' That bit of code needs some attention. - It still assumes ASCII goes up to 255, which hasn't been true in Python for a while now. - The initialization may not be thread-safe; a table is being initialized on first use. "robotparser" was trying to check if a URL with a Unicode character in it was allowed. Note the "KeyError: u'\xe2'" ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-06-13 15:36 Message: Logged In: YES user_id=863202 Originator: NO It should be noted that the unicode aspect of this bug is actually a recognized flaw with a nontrivial solution. See this thread from the Python-dev list, dated from July 2006: http://mail.python.org/pipermail/python-dev/2006-July/067248.html It was essentially agreed upon in this thread that the "obvious" solution--simply converting to UTF-8 as per rfc3986--doesn't actually cover all cases, and that passing a unicode string in to urllib.quote() indeed has ambiguous results. For more information, see Mike Brown's comment on the aforementioned thread: http://mail.python.org/pipermail/python-dev/2006-July/067335.html It was generally agreed in the thread that the proper solution was to have urllib.quote() *only* deal with standard Python string data, and to raise a TypeError if a unicode string is passed in, implying that any conversion needs to be done by higher-level code, because implicit conversion within urllib.quote() is too ambiguous. However, it seems the TypeError fix was never made to the Python SVN repository; perhaps this is because it may have broken legacy code that actually catches KeyErrors as John Nagle mentioned? Or perhaps it was simply because no one ever got around to it. Unfortunately, I'm not in a position to say for sure, but I hope my explanation helps. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2007-06-06 16:49 Message: Logged In: YES user_id=5571 Originator: YES As a workaround, you can surround calls to "can_fetch" with an try-block and catch KeyError exceptions. That's what I'm doing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-06-05 23:39 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly provide a patch to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1712522&group_id=5470 From noreply at sourceforge.net Wed Jun 13 19:07:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 10:07:45 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 09:41 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 13:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Wed Jun 13 22:19:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 13:19:17 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by incongruity You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Thu Jun 14 00:32:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 15:32:25 -0700 Subject: [ python-Bugs-1736792 ] dict reentrant/threading bug Message-ID: Bugs item #1736792, was opened at 2007-06-13 16: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=1736792&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: dict reentrant/threading bug Initial Comment: As I first mentioned in my post[1] on comp.lang.python, it seems possible to modify a dict while a lookup is ongoing, without causing the lookup to restart. This requires the ma_table be reallocated twice (first to a new address, then a second time back to the original address). This could also happen if the constants or behaviour relating to ma_smalltable were changed, but the current implementation is safe. To fix this, I suggest two more tests be added along side the ep0 and startkey tests that currently restart the lookup process. 1) ma_mask. If ma_table was reallocated, and the new allocation is smaller, memory corruption would result. Checking ma_mask for changes would ensure this doesn't happen. 2) reallocation counter. Increment every time ma_table is reallocated. It would be technically possible to overflow this, but the circumstances would be exceedingly unusual. [1] http://groups.google.com/group/comp.lang.python/browse_thread/thread/7f5b8fc59aadbdea/d77bdbcf5b20c056 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736792&group_id=5470 From noreply at sourceforge.net Thu Jun 14 03:28:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 18:28:45 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 13:41 Message generated for change (Comment added) made by cpegeric You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- >Comment By: Eric (cpegeric) Date: 2007-06-14 01:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 17:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 04:24:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 19:24:04 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 09:41 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 22:24 Message: Logged In: YES user_id=281701 Originator: NO I've realized my suggestion was not precise. I meant asking to run the argument to popen() rather than popen(). That is, I would run this from command line to see if there is an issue with the shell: $ yes | echo hello ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-13 21:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 13:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 04:46:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 19:46:38 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 13:41 Message generated for change (Comment added) made by cpegeric You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- >Comment By: Eric (cpegeric) Date: 2007-06-14 02:46 Message: Logged In: YES user_id=1595194 Originator: YES sorry for the misunderstanding. Here is the result. % yes | echo hello hello % echo $? 0 % ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-14 02:24 Message: Logged In: YES user_id=281701 Originator: NO I've realized my suggestion was not precise. I meant asking to run the argument to popen() rather than popen(). That is, I would run this from command line to see if there is an issue with the shell: $ yes | echo hello ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-14 01:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 17:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 05:15:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 20:15:15 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 09:41 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 23:15 Message: Logged In: YES user_id=281701 Originator: NO It appears your "yes" does not catch SIGPIPE. I've reproduced the issue with $ python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' Traceback (most recent call last): File "", line 1, in KeyboardInterrupt The documentation on Python module signal says SIGPIPE is ignored by Python as well. My work-around to this was to catch SIGPIPE, but the GNU C library would terminate the whole script. $ python -c 'import sys, os, signal; signal.signal(signal.SIGPIPE, signal.SIG_DFL); sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' hello http://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html Perhaps, writing own signal handler might help. ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-13 22:46 Message: Logged In: YES user_id=1595194 Originator: YES sorry for the misunderstanding. Here is the result. % yes | echo hello hello % echo $? 0 % ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 22:24 Message: Logged In: YES user_id=281701 Originator: NO I've realized my suggestion was not precise. I meant asking to run the argument to popen() rather than popen(). That is, I would run this from command line to see if there is an issue with the shell: $ yes | echo hello ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-13 21:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 13:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 05:22:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 20:22:10 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 09:41 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 23:22 Message: Logged In: YES user_id=281701 Originator: NO The SIG_DFL default handler seems to terminate the current process (argument to popen()), not Python script. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 23:15 Message: Logged In: YES user_id=281701 Originator: NO It appears your "yes" does not catch SIGPIPE. I've reproduced the issue with $ python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' Traceback (most recent call last): File "", line 1, in KeyboardInterrupt The documentation on Python module signal says SIGPIPE is ignored by Python as well. My work-around to this was to catch SIGPIPE, but the GNU C library would terminate the whole script. $ python -c 'import sys, os, signal; signal.signal(signal.SIGPIPE, signal.SIG_DFL); sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' hello http://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html Perhaps, writing own signal handler might help. ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-13 22:46 Message: Logged In: YES user_id=1595194 Originator: YES sorry for the misunderstanding. Here is the result. % yes | echo hello hello % echo $? 0 % ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 22:24 Message: Logged In: YES user_id=281701 Originator: NO I've realized my suggestion was not precise. I meant asking to run the argument to popen() rather than popen(). That is, I would run this from command line to see if there is an issue with the shell: $ yes | echo hello ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-13 21:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 13:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 05:49:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 20:49:09 -0700 Subject: [ python-Bugs-1736483 ] os.popen('yes | echo hello') stuck Message-ID: Bugs item #1736483, was opened at 2007-06-13 13:41 Message generated for change (Comment added) made by cpegeric You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: Eric (cpegeric) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen('yes | echo hello') stuck Initial Comment: after calling os.popen('yes | echo hello'), the process never returns. ---------------------------------------------------------------------- >Comment By: Eric (cpegeric) Date: 2007-06-14 03:49 Message: Logged In: YES user_id=1595194 Originator: YES It works now. thank you. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-14 03:22 Message: Logged In: YES user_id=281701 Originator: NO The SIG_DFL default handler seems to terminate the current process (argument to popen()), not Python script. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-14 03:15 Message: Logged In: YES user_id=281701 Originator: NO It appears your "yes" does not catch SIGPIPE. I've reproduced the issue with $ python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' Traceback (most recent call last): File "", line 1, in KeyboardInterrupt The documentation on Python module signal says SIGPIPE is ignored by Python as well. My work-around to this was to catch SIGPIPE, but the GNU C library would terminate the whole script. $ python -c 'import sys, os, signal; signal.signal(signal.SIGPIPE, signal.SIG_DFL); sys.stdout.write(os.popen("while :; do echo yes ; done | echo hello").read())' hello http://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals.html Perhaps, writing own signal handler might help. ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-14 02:46 Message: Logged In: YES user_id=1595194 Originator: YES sorry for the misunderstanding. Here is the result. % yes | echo hello hello % echo $? 0 % ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-14 02:24 Message: Logged In: YES user_id=281701 Originator: NO I've realized my suggestion was not precise. I meant asking to run the argument to popen() rather than popen(). That is, I would run this from command line to see if there is an issue with the shell: $ yes | echo hello ---------------------------------------------------------------------- Comment By: Eric (cpegeric) Date: 2007-06-14 01:28 Message: Logged In: YES user_id=1595194 Originator: YES command line also get stuck. The OS is MacOSX. Python version 2.3.5. Will it help update to new version? I quited the program by Ctrl-C. python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt % python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' ^CTraceback (most recent call last): File "", line 1, in ? KeyboardInterrupt ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-13 17:07 Message: Logged In: YES user_id=281701 Originator: NO Could you try the same command from your shell? I am guessing "yes" will write an error message about the broken pipe to stderr. $ python -c 'import sys, os; sys.stdout.write(os.popen("yes | echo hello").read())' yes: standard output: Broken pipe yes: write error hello $ python -c 'import sys, os; sys.stdout.write(os.popen3("yes | echo hello")[1].read())' hello ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736483&group_id=5470 From noreply at sourceforge.net Thu Jun 14 09:43:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 00:43:33 -0700 Subject: [ python-Bugs-1734860 ] sitecustomize.py not found Message-ID: Bugs item #1734860, was opened at 2007-06-11 06:33 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: www.spirito.de (openspirito) Assigned to: Nobody/Anonymous (nobody) Summary: sitecustomize.py not found Initial Comment: Under my configuration (Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32) the sitecustomize.py is not found in the current directory. I added some testing code into site.def execsitecustomize() and found out, that the current path is not part of sys.path, but later on in the main program it is. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-14 04:43 Message: Logged In: YES user_id=479790 Originator: NO I don't think that allowing sitecustomize.py to be run from the current directory would be a good idea, as it gets executed automatically on any invocation of the Python program (and it could contain arbitrary code). You can put sitecustomize.py inside Lib or Lib\site-packages and it will be picked fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 From noreply at sourceforge.net Thu Jun 14 10:53:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 01:53:39 -0700 Subject: [ python-Bugs-1734860 ] sitecustomize.py not found Message-ID: Bugs item #1734860, was opened at 2007-06-11 11:33 Message generated for change (Comment added) made by openspirito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: www.spirito.de (openspirito) Assigned to: Nobody/Anonymous (nobody) Summary: sitecustomize.py not found Initial Comment: Under my configuration (Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32) the sitecustomize.py is not found in the current directory. I added some testing code into site.def execsitecustomize() and found out, that the current path is not part of sys.path, but later on in the main program it is. ---------------------------------------------------------------------- >Comment By: www.spirito.de (openspirito) Date: 2007-06-14 10:53 Message: Logged In: YES user_id=1103348 Originator: YES It worked like this in all previous versions of Python. I think it is very useful e.g. if you work with development versions of other libraries. Better than adding import paths via sys.path += ['abc'] at the top of Python scripts. Or is there another or better way to add project specific import paths? But at least there should be a notice in the documentation of Python 2.5 that this behaviour changed. I spend some time to find out that it was changed. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-14 09:43 Message: Logged In: YES user_id=479790 Originator: NO I don't think that allowing sitecustomize.py to be run from the current directory would be a good idea, as it gets executed automatically on any invocation of the Python program (and it could contain arbitrary code). You can put sitecustomize.py inside Lib or Lib\site-packages and it will be picked fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 From noreply at sourceforge.net Thu Jun 14 12:35:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 03:35:13 -0700 Subject: [ python-Bugs-1717900 ] Destructor behavior faulty Message-ID: Bugs item #1717900, was opened at 2007-05-12 20:41 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wolf Rogner (wrogner) Assigned to: Nobody/Anonymous (nobody) Summary: Destructor behavior faulty Initial Comment: I tried example 11.4. from bytesofpython (by C.H. Swaroop). Example works fine. Added a new Person instance 'wolf' -> Program terminated with: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in > ignored added print list(globals()) -> ['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__'] changed wolf to aaa: print list(globals()) -> ['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__'] Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'. If the destructing code removes items in this order, no wonder I get an error. Person should not get deleted if refcount is still > 0. Wolf Rogner ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-06-06 16:38 Message: Logged In: YES user_id=1115903 Originator: NO Brought this up on python-dev: http://mail.python.org/pipermail/python-dev/2007-May/073329.html Since there is some interest in making the change Armin suggested, I suggest re-opening this item so that it doesn't get overlooked/forgotten. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-05-28 02:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: 2007-05-17 08:15 Message: Logged In: YES user_id=849994 Originator: NO Alan: you should bring that up on python-dev. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-16 22:58 Message: Logged In: YES user_id=1115903 Originator: NO I tried out a simple change (to the trunk) in _PyModule_Clear to prevent this particular problem. Between the "remove everything beginning with an underscore" and the "remove everything except __builtins__" steps, I added a step to remove all instance objects in the module's dictionary. It appears to stop this problem and passes the regression test suite. I can post it as a patch if this seems like a reasonable change to make. Also, I noticed that earlier I posted the wrong link for the location of the example code; it should have been: http://www.dpawson.co.uk/bop/byteofpython_120.txt ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 22:06 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 11:19 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-15 18:44 Message: Logged In: YES user_id=479790 Originator: NO FWIW, the script name appears to be relevant as well. I were going to say that I could not reproduce it as it was; this same example saved as "a.py" doesn't show the error; "w.py" does. To the OP: Module finalization is a fragile step; this is a long standing issue and could be improved, but anyway I don't think it can be made robust enough (this is just my opinion!). I usually try to *never* reference any globals in destructors. In this case, using self.__class__ instead of Person is safer and works fine; if other globals were needed they could be passed as default argument values. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-14 15:38 Message: Logged In: YES user_id=1115903 Originator: NO I took the example mentioned from here: http://www.python.org/doc/essays/cleanup/ and added this line to the end: wolf = Person('wolf') and it gives the reported error. Here is a minimal snippet that produces the same error when executed as the top-level module: class Person: population = 0 def __del__(self): Person.population -= 1 wolf = Person() This appears to be consistent with the behavior described here: http://www.python.org/doc/essays/cleanup/ While I understand that cleaning up a module at exit time is probably not an easy thing to make arbitrarily smart, this behavior seems a little too not-smart to me. It seems like it's not all that hard to get bitten by it, and the error makes no sense unless you're familiar with the module cleanup algorithm. For what it's worth, I offer to help make module cleanup a little smarter, although I may not be able to spend much time on it until I finish some things I'm already committed to do. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-05-12 23:36 Message: Logged In: YES user_id=1115903 Originator: NO Could you post the code for your entire script? It makes it a lot easier to figure out what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470 From pfdubois at gmail.com Sat Jun 9 19:11:57 2007 From: pfdubois at gmail.com (Paul Dubois) Date: Sat, 9 Jun 2007 10:11:57 -0700 Subject: Spammer-messages this morning just me cleaning up Message-ID: You may have received some messages this morning that looked like more spam. They were not, they were me permanently retiring some issues that had been posted by spammers a month ago. Unfortunately we have set up an auditor that sends ALL changes to python-bugs-list, so even such administrative actions result in messages. I lobbied for not sending out mail when there was no message attached (which is Roundup's default) but we were told to do otherwise. I continue to think this is a bad idea, and this morning's messages are an example why. (Another one was me just closing an issue without comment; it had been a test issue I had posted some time back). I am entering the totally-retired state (just 3 more working days) and will start spam patrol on the tracker on a regular basis. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20070609/95ba61a7/attachment.html From brett at python.org Sat Jun 9 23:09:07 2007 From: brett at python.org (Brett Cannon) Date: Sat, 9 Jun 2007 14:09:07 -0700 Subject: [Tracker-discuss] Spammer-messages this morning just me cleaning up In-Reply-To: References: Message-ID: On 6/9/07, Paul Dubois wrote: > > You may have received some messages this morning that looked like more > spam. They were not, they were me permanently retiring some issues that had > been posted by spammers a month ago. Unfortunately we have set up an auditor > that sends ALL changes to python-bugs-list, so even such administrative > actions result in messages. I lobbied for not sending out mail when there > was no message attached (which is Roundup's default) but we were told to do > otherwise. I continue to think this is a bad idea, and this morning's > messages are an example why. (Another one was me just closing an issue > without comment; it had been a test issue I had posted some time back). Well, this might be the example that changes that idea for the bugs list. Will just have to tell people to include a comment about why they performed an action in order for it to show up. I am entering the totally-retired state (just 3 more working days) and will > start spam patrol on the tracker on a regular basis. Thanks, Paul! And hopefully retirement will be fun for you. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20070609/4595bc97/attachment.htm From noreply at sourceforge.net Thu Jun 14 14:05:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 05:05:52 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 14: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=1737127&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Thu Jun 14 14:06:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 05:06:26 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 14:05 Message generated for change (Comment added) made by abakker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- >Comment By: Arno Bakker (abakker) Date: 2007-06-14 14:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Thu Jun 14 16:14:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 07:14:56 -0700 Subject: [ python-Bugs-1737210 ] Add/Remove programs shows Martin v Löwis Message-ID: Bugs item #1737210, was opened at 2007-06-14 17:14 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=1737210&group_id=5470 Please note that this 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 Private: No Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: Add/Remove programs shows Martin v L?wis Initial Comment: Vista Ultimate x86 / Python 2.5.1 Installed using the MSI Looking in the Add/Remove programs menu, I see "Martin v. L?vis" as the publisher I would have expected Python / Python.org / PSF / ? I.e. something that indicates that Python isn't a one-man show (even though the installer probably is...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737210&group_id=5470 From noreply at sourceforge.net Thu Jun 14 19:59:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 10:59:50 -0700 Subject: [ python-Bugs-1735418 ] file.read() truncating strings under Windows Message-ID: Bugs item #1735418, was opened at 2007-06-12 00:19 Message generated for change (Comment added) made by cgkanchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: cgkanchi (cgkanchi) Assigned to: Nobody/Anonymous (nobody) Summary: file.read() truncating strings under Windows Initial Comment: On Python 2.4.4 and 2.5.1 under Windows, file.read() fails to read a varying number of characters from the last line(s) of text files when asked to read more than 800 characters from near the end of the file. For example, if the last word of a 500kb file is "superlative", file.read() might output "erlative". The file pointer at this stage is very close (a few words at most) to the end of the file. I ran into this problem while writing a program to split .txt ebooks into smaller files so that my ancient iPod could handle them. The behaviour is identical on both 2.4.4 and 2.5.1 under Windows, but does not appear under Mac OS X. I was unable to test it under Linux. To test the bug, I used various books from http://gutenberg.org . The one primarily used was Pride and Prejudice by Jane Austen. ---------------------------------------------------------------------- >Comment By: cgkanchi (cgkanchi) Date: 2007-06-14 17:59 Message: Logged In: YES user_id=1814873 Originator: YES >(e) To have tell() on the same level with read(), try the unbuffered mode >by specifying bufsize=0 in open(), > > http://docs.python.org/lib/built-in-funcs.html This does not work either. There is no change in the behaviour of the program. >(a) I would not trust tell(). Calculate the absolute position and use >seek(). That defeats the purpose of having native string handling in python. It means I have to do things the C way. Therefore, it is a bug in the implementation. >(b) Just from the documentation to Python's file-like objects I can assume >that read() and tell() belong to different levels of API. The read() >function has this in its documentation: >"Note that this method may call the underlying C function fread() more >than once in an effort to acquire as close to size bytes as possible". >http://docs.python.org/lib/bltin-file-objects.html That should not make any difference whatsoever. >The tell() function's documentation refers to stdio's ftell(). This hints >that tell() will return the position of the fread() buffer's end, not the >read()'s end. Again, irrelevant. >(c) It also appears that by adding 1 to the "current position - unget >size" you are skipping the space character itself. This is by design. I didn't want the space. Functionally, it makes no difference. >(d) The rfind() might return -1 if the search fails. This is by design as well, when there are no spaces in the remaining file, i.e., the file pointer is on the last word, a return value of -1 causes read() to read till EOF. I did however find the solution in the python docs, but it is a workaround rather than a fix for a very obvious bug. "tell() Return the file's current position, like stdio's ftell(). Note: On Windows, tell() can return illegal values (after an fgets()) when reading files with Unix-style line-endings. Use binary mode ('rb') to circumvent this problem. " Cheers, cgkanchi ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 15:51 Message: Logged In: YES user_id=281701 Originator: NO (e) To have tell() on the same level with read(), try the unbuffered mode by specifying bufsize=0 in open(), http://docs.python.org/lib/built-in-funcs.html ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-12 15:47 Message: Logged In: YES user_id=281701 Originator: NO This is your coding bug. (a) I would not trust tell(). Calculate the absolute position and use seek(). (b) Just from the documentation to Python's file-like objects I can assume that read() and tell() belong to different levels of API. The read() function has this in its documentation: "Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible". http://docs.python.org/lib/bltin-file-objects.html The tell() function's documentation refers to stdio's ftell(). This hints that tell() will return the position of the fread() buffer's end, not the read()'s end. (c) It also appears that by adding 1 to the "current position - unget size" you are skipping the space character itself. (d) The rfind() might return -1 if the search fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1735418&group_id=5470 From noreply at sourceforge.net Thu Jun 14 22:54:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 13:54:12 -0700 Subject: [ python-Bugs-1737210 ] Add/Remove programs shows Martin v Löwis Message-ID: Bugs item #1737210, was opened at 2007-06-14 16:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737210&group_id=5470 Please note that this 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 Private: No Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: Add/Remove programs shows Martin v L?wis Initial Comment: Vista Ultimate x86 / Python 2.5.1 Installed using the MSI Looking in the Add/Remove programs menu, I see "Martin v. L?vis" as the publisher I would have expected Python / Python.org / PSF / ? I.e. something that indicates that Python isn't a one-man show (even though the installer probably is...) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-14 22:54 Message: Logged In: YES user_id=21627 Originator: NO I can't really see this as a bug... I can change it to "Python Software Foundation", if the PSF wants me to. The publisher definitely is *not* "Python" or "Python.org". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737210&group_id=5470 From noreply at sourceforge.net Fri Jun 15 04:04:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 19:04:21 -0700 Subject: [ python-Bugs-1230540 ] sys.excepthook doesn't work in threads Message-ID: Bugs item #1230540, was opened at 2005-06-30 19:06 Message generated for change (Comment added) made by ellisj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: sys.excepthook doesn't work in threads Initial Comment: simple script to reproduce: import sys, threading def log_exception(*args): print 'got exception %s' % (args,) sys.excepthook = log_exception def foo(): a = 1 / 0 threading.Thread(target=foo).start() Note that a normal traceback is printed instead of "got exception." ---------------------------------------------------------------------- >Comment By: Jonathan Ellis (ellisj) Date: 2007-06-15 02:04 Message: Logged In: YES user_id=657828 Originator: YES Here is a workaround in the meantime: def install_thread_excepthook(): """ Workaround for sys.excepthook thread bug (https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470). Call once from __main__ before creating any threads. If using psyco, call psycho.cannotcompile(threading.Thread.run) since this replaces a new-style class method. """ import sys run_old = threading.Thread.run def run(*args, **kwargs): try: run_old(*args, **kwargs) except (KeyboardInterrupt, SystemExit): raise except: sys.excepthook(*sys.exc_info()) threading.Thread.run = run ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2007-06-06 11:11 Message: Logged In: YES user_id=6656 Originator: NO I've just run into this, and it's very annoying. The stupid part is that threads started with the thread module don't have this problem, it's just a problem with threading.Thread()s trying to be too clever. I would vote for deleting all the code to do with exception printing in threading.py and letting the C machinery take care of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470 From noreply at sourceforge.net Fri Jun 15 11:59:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 02:59:07 -0700 Subject: [ python-Bugs-1737737 ] telnetlib.Telnet does not process DATA MARK (DM) Message-ID: Bugs item #1737737, was opened at 2007-06-15 11: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=1737737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Norbert Buchm?ller (norbert_b) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.Telnet does not process DATA MARK (DM) Initial Comment: According to RFC854, the DATA MARK (DM, character code 0xf2) is a control character of the TELNET protocol that should be removed from the input stream (see 'THE TELNET "SYNCH" SIGNAL' in RFC854). Unfortunately the telnetlib.Telnet implementation shipped with Python version 2.5 simply passes the DM char through.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737737&group_id=5470 From noreply at sourceforge.net Fri Jun 15 16:05:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 07:05:40 -0700 Subject: [ python-Bugs-1613573 ] xmlrpclib ServerProxy uses old httplib interface Message-ID: Bugs item #1613573, was opened at 2006-12-12 00:17 Message generated for change (Comment added) made by itkovian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Brown (mattgbrown) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib ServerProxy uses old httplib interface Initial Comment: The ServerProxy class of the xmlrpclib module uses the old style HTTP / HTTPS classes of the httplib module rather than the newer HTTPConnection and HTTPConnection classes. The practical result of this is that xmlrpc connections are not able to make use of HTTP/1.1 functionality. Please update the xmlrpclib module to use the newer API provided by httplib so that the advanced functionality of HTTP/1.1 is available. ---------------------------------------------------------------------- Comment By: Itkovian (itkovian) Date: 2007-06-15 16:05 Message: Logged In: YES user_id=1818513 Originator: NO I think the only changes required are these: --- /sw/lib/python2.5/xmlrpclib.py 2006-11-29 02:46:38.000000000 +0100 +++ xmlrpclib.py 2007-06-15 16:03:17.000000000 +0200 @@ -1182,23 +1182,13 @@ self.send_user_agent(h) self.send_content(h, request_body) - errcode, errmsg, headers = h.getreply() + response = h.getresponse() + + if response.status != 200: + raise ProtocolError(host + handler, response.status, response.reason, response.msg.headers) - if errcode != 200: - raise ProtocolError( - host + handler, - errcode, errmsg, - headers - ) - - self.verbose = verbose - - try: - sock = h._conn.sock - except AttributeError: - sock = None - - return self._parse_response(h.getfile(), sock) + payload = response.read() + return payload ## # Create parser. @@ -1250,7 +1240,7 @@ # create a HTTP connection object from a host descriptor import httplib host, extra_headers, x509 = self.get_host_info(host) - return httplib.HTTP(host) + return httplib.HTTPConnection(host) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 21:58 Message: Logged In: YES user_id=11375 Originator: NO Can you provide a patch to make this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&group_id=5470 From noreply at sourceforge.net Fri Jun 15 16:50:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 07:50:55 -0700 Subject: [ python-Bugs-1737864 ] logging.exception() does not allow empty string Message-ID: Bugs item #1737864, was opened at 2007-06-15 17: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=1737864&group_id=5470 Please note that this 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 Private: No Submitted By: Dmitrii Tisnek (dimaq) Assigned to: Nobody/Anonymous (nobody) Summary: logging.exception() does not allow empty string Initial Comment: Due to the following code, logging.exception("") does not work. I suggest replacing s[-1]=="\n" with s.endswith("\n"). logging/__init__.py:formatException(): --snip-- if s[-1] == "\n": s = s[:-1] return s ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470 From noreply at sourceforge.net Fri Jun 15 17:06:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 08:06:13 -0700 Subject: [ python-Feature Requests-1733259 ] ZipFile CallBack Needed... Message-ID: Feature Requests item #1733259, was opened at 2007-06-08 03:54 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1733259&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: durumdara (durumdara) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile CallBack Needed... Initial Comment: Hi! I wrote about this here: http://groups.google.com/group/comp.lang.python/browse_thread/thread/f08c37f30b654746/a0fe8ab504b3b702 And here: http://groups.google.com.kh/group/comp.lang.python/browse_thread/thread/c6069d12273025bf/18b9b1c286d9af7b?lnk=st&q=python+zip+callback&rnum=1#18b9b1c286d9af7b So need a little modification in ZipFile module to get more control on compression. A callback procedure needed to: - I show progress bar when I compress a file - I can abort the whole compression procedure When I compress little files, no problem. But when compress large files, I lost the control, and I don't know (I can't show) the compression progress, and the remaining bytes. I can change this in my app only, but if I installed a new Python I lost it everytime... :-( Thanks for your help: dd ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-06-15 11:06 Message: Logged In: YES user_id=764593 Originator: NO Does the fact that """I can change this in my app only, but if I installed a new Python I lost it everytime...""" mean that you already have a patch? Patches get applied faster than feature requests get worked on... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1733259&group_id=5470 From noreply at sourceforge.net Fri Jun 15 18:39:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 09:39:18 -0700 Subject: [ python-Bugs-1737864 ] logging.exception() does not allow empty string Message-ID: Bugs item #1737864, was opened at 2007-06-15 14:50 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470 Please note that this 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 Private: No Submitted By: Dmitrii Tisnek (dimaq) >Assigned to: Vinay Sajip (vsajip) Summary: logging.exception() does not allow empty string Initial Comment: Due to the following code, logging.exception("") does not work. I suggest replacing s[-1]=="\n" with s.endswith("\n"). logging/__init__.py:formatException(): --snip-- if s[-1] == "\n": s = s[:-1] return s ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-15 16:39 Message: Logged In: YES user_id=849994 Originator: NO Sounds reasonable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470 From noreply at sourceforge.net Sat Jun 16 03:24:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 18:24:54 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18: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=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sat Jun 16 03:55:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 18:55:26 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sat Jun 16 04:00:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 19:00:08 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by paulbeard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sat Jun 16 10:03:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Jun 2007 01:03:44 -0700 Subject: [ python-Bugs-1738250 ] Universal MacPython 2.5.1 installation fails Message-ID: Bugs item #1738250, was opened at 2007-06-16 01: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=1738250&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shinichiro Wachi (swachi) Assigned to: Jack Jansen (jackjansen) Summary: Universal MacPython 2.5.1 installation fails Initial Comment: Cannot install package due to file errors. Somehow related to wrong archive format. Install log is attached. Google search indicates that at least one other person has reported this error in external forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 From noreply at sourceforge.net Sat Jun 16 20:25:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Jun 2007 11:25:23 -0700 Subject: [ python-Bugs-1738441 ] shutil.move doesn't work when only case changes Message-ID: Bugs item #1738441, was opened at 2007-06-16 15:25 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=1738441&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel Gambetta (ggambett) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move doesn't work when only case changes Initial Comment: shutil.move() appears to fail silently when the source and destination filenames only differ in case (ie "SomeFile" and "Somefile"). This is with python 2.4.3-18.fc6, on a case-sensitive filesystem (ext3), so this rename *is* meaningful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 From noreply at sourceforge.net Sun Jun 17 07:08:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Jun 2007 22:08:40 -0700 Subject: [ python-Bugs-1738441 ] shutil.move doesn't work when only case changes Message-ID: Bugs item #1738441, was opened at 2007-06-16 23:55 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel Gambetta (ggambett) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move doesn't work when only case changes Initial Comment: shutil.move() appears to fail silently when the source and destination filenames only differ in case (ie "SomeFile" and "Somefile"). This is with python 2.4.3-18.fc6, on a case-sensitive filesystem (ext3), so this rename *is* meaningful. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-17 10:38 Message: Logged In: YES user_id=942711 Originator: NO I guess, this should be very much python 2.4.3-18.fc6 specific. While I have python 2.3.4, python 2.5, python 2.6a0. I am unable to reproduce this defect. Having said that, help(shutil.move) mentions about the various issues of moving the implementation glosses over. Please provide some more details or anyone with python 2.4.3-18 should be able to verify it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 From noreply at sourceforge.net Sun Jun 17 09:29:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 00:29:42 -0700 Subject: [ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Message-ID: Bugs item #1738559, was opened at 2007-06-17 07: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=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 From noreply at sourceforge.net Sun Jun 17 17:08:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 08:08:18 -0700 Subject: [ python-Bugs-1738670 ] sqlite3 doc fix Message-ID: Bugs item #1738670, was opened at 2007-06-17 15: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=1738670&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Carter (comcol) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 doc fix Initial Comment: I ran the example given at http://docs.python.org/lib/module-sqlite3.html but it didn't affect the database because no commit() was made. This is a "gotcha" that will affect others, too. I recommend appending the example: ---begin conn = sqlite3.connect('/tmp/example') # ... c = conn.cursor() # Create table c.execute('''create table stocks (date text, trans text, symbol text, qty real, price real)''') # Insert a row of data c.execute("""insert into stocks values ('2006-01-05','BUY','RHAT',100,35.14)""") ---end with the lines: # commit the changes, and close out c.close() conn.commit() # make the changes "stick" conn.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738670&group_id=5470 From noreply at sourceforge.net Sun Jun 17 20:28:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 11:28:28 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by paulbeard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: paul beard (paulbeard) Date: 2007-06-17 11:28 Message: Logged In: YES user_id=201298 Originator: YES Still trying to find a way to verify what this problem is. Since it's a python script file[1] that generates the error, and python itself that keeps requesting more memory as a result[2], what other information can I provide? It seems like that in itself is a python code test, since nothing else is involved by python code (excluding the xml files it's choking on). This is OS-specific, as it works fine in FreeBSD 6.2. Repro-ing it would require someone to run OS X and install the MacPorts infrastructure. 1. /opt/local/bin/xml2po: a /opt/local/bin/python script text executable 2. Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug (null)Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region File Added: build.log ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sun Jun 17 20:34:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 11:34:44 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 11:34 Message: Logged In: YES user_id=33168 Originator: NO Run ulimit -a on both the OS X machine and FreeBSD machine. My guess is that the heap size (possibly called virtual memory) is lower on the OS X box and not enough to allow Python to do the work. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:28 Message: Logged In: YES user_id=201298 Originator: YES Still trying to find a way to verify what this problem is. Since it's a python script file[1] that generates the error, and python itself that keeps requesting more memory as a result[2], what other information can I provide? It seems like that in itself is a python code test, since nothing else is involved by python code (excluding the xml files it's choking on). This is OS-specific, as it works fine in FreeBSD 6.2. Repro-ing it would require someone to run OS X and install the MacPorts infrastructure. 1. /opt/local/bin/xml2po: a /opt/local/bin/python script text executable 2. Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug (null)Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region File Added: build.log ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sun Jun 17 20:38:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 11:38:52 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by paulbeard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: paul beard (paulbeard) Date: 2007-06-17 11:38 Message: Logged In: YES user_id=201298 Originator: YES I am also attaching a screen grab of what this looks like, memory and CPU-wide: Python is using 70+ % of CPU (and churns away for several minutes) and memory is 100% used with more than 1 Gb swap in use. File Added: pythonmem.png ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 11:34 Message: Logged In: YES user_id=33168 Originator: NO Run ulimit -a on both the OS X machine and FreeBSD machine. My guess is that the heap size (possibly called virtual memory) is lower on the OS X box and not enough to allow Python to do the work. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:28 Message: Logged In: YES user_id=201298 Originator: YES Still trying to find a way to verify what this problem is. Since it's a python script file[1] that generates the error, and python itself that keeps requesting more memory as a result[2], what other information can I provide? It seems like that in itself is a python code test, since nothing else is involved by python code (excluding the xml files it's choking on). This is OS-specific, as it works fine in FreeBSD 6.2. Repro-ing it would require someone to run OS X and install the MacPorts infrastructure. 1. /opt/local/bin/xml2po: a /opt/local/bin/python script text executable 2. Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug (null)Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region File Added: build.log ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Sun Jun 17 20:50:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 11:50:01 -0700 Subject: [ python-Bugs-1738670 ] sqlite3 doc fix Message-ID: Bugs item #1738670, was opened at 2007-06-17 08:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738670&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Carter (comcol) >Assigned to: Neal Norwitz (nnorwitz) Summary: sqlite3 doc fix Initial Comment: I ran the example given at http://docs.python.org/lib/module-sqlite3.html but it didn't affect the database because no commit() was made. This is a "gotcha" that will affect others, too. I recommend appending the example: ---begin conn = sqlite3.connect('/tmp/example') # ... c = conn.cursor() # Create table c.execute('''create table stocks (date text, trans text, symbol text, qty real, price real)''') # Insert a row of data c.execute("""insert into stocks values ('2006-01-05','BUY','RHAT',100,35.14)""") ---end with the lines: # commit the changes, and close out c.close() conn.commit() # make the changes "stick" conn.close() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 11:50 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. I updated the example and tested it. I did a slightly different change by doing the commit first and optionally closing the cursor. Committed revision 56009. Committed revision 56010. (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738670&group_id=5470 From noreply at sourceforge.net Sun Jun 17 22:11:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 13:11:11 -0700 Subject: [ python-Bugs-1738754 ] Tutorial error in 3.1.2 Strings Message-ID: Bugs item #1738754, was opened at 2007-06-17 22: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=1738754&group_id=5470 Please note that this 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 Private: No Submitted By: otan (otan) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial error in 3.1.2 Strings Initial Comment: The backslash is removed by the interpreter in this context: >>> '"Isn\'t," she said.' '"Isn\'t," she said.' correct is: >>> '"Isn\'t," she said.' '"Isn't," she said.' This might be confusing especially for beginners! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738754&group_id=5470 From noreply at sourceforge.net Mon Jun 18 01:59:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 16:59:52 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Comment added) made by paulbeard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- >Comment By: paul beard (paulbeard) Date: 2007-06-17 16:59 Message: Logged In: YES user_id=201298 Originator: YES This seems to be resolved by ripping out and rebuilding/re-installing all the dependencies that make up gnome-doc-utils (which is where the xml2po script lives). So it looks like I bothered you all for nothing. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:38 Message: Logged In: YES user_id=201298 Originator: YES I am also attaching a screen grab of what this looks like, memory and CPU-wide: Python is using 70+ % of CPU (and churns away for several minutes) and memory is 100% used with more than 1 Gb swap in use. File Added: pythonmem.png ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 11:34 Message: Logged In: YES user_id=33168 Originator: NO Run ulimit -a on both the OS X machine and FreeBSD machine. My guess is that the heap size (possibly called virtual memory) is lower on the OS X box and not enough to allow Python to do the work. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:28 Message: Logged In: YES user_id=201298 Originator: YES Still trying to find a way to verify what this problem is. Since it's a python script file[1] that generates the error, and python itself that keeps requesting more memory as a result[2], what other information can I provide? It seems like that in itself is a python code test, since nothing else is involved by python code (excluding the xml files it's choking on). This is OS-specific, as it works fine in FreeBSD 6.2. Repro-ing it would require someone to run OS X and install the MacPorts infrastructure. 1. /opt/local/bin/xml2po: a /opt/local/bin/python script text executable 2. Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug (null)Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region File Added: build.log ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Mon Jun 18 04:26:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 19:26:45 -0700 Subject: [ python-Bugs-1738193 ] parser error : out of memory error Message-ID: Bugs item #1738193, was opened at 2007-06-15 18:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: paul beard (paulbeard) Assigned to: Nobody/Anonymous (nobody) Summary: parser error : out of memory error Initial Comment: Having some trouble parsing some xml files for GNOME on OS X 10.4.9 in Python 2.4.4. make[3]: Nothing to be done for `all'. if ! test -d es/; then mkdir es/; fi if [ -f "C/gdm.xml" ]; then d="../"; else d="/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_gnome_gdm/work/gdm-2.18.2/docs/"; fi; \ (cd es/ && \ `which xml2po` -e -p \ "${d}es/es.po" \ "${d}C/gdm.xml" > gdm.xml.tmp && \ cp gdm.xml.tmp gdm.xml && rm -f gdm.xml.tmp) Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug (null)(null)Python(451) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(451) malloc: *** error: can't allocate region Python(451) malloc: *** set a breakpoint in szone_error to debug Entity: line 1: parser error : out of memory error %para.char.mix; ^ Entity: line 2: |footnoteref|xref |abbrev|acronym|citation|citerefentry|citetitle|emphasis ^ ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 16:59 Message: Logged In: YES user_id=201298 Originator: YES This seems to be resolved by ripping out and rebuilding/re-installing all the dependencies that make up gnome-doc-utils (which is where the xml2po script lives). So it looks like I bothered you all for nothing. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:38 Message: Logged In: YES user_id=201298 Originator: YES I am also attaching a screen grab of what this looks like, memory and CPU-wide: Python is using 70+ % of CPU (and churns away for several minutes) and memory is 100% used with more than 1 Gb swap in use. File Added: pythonmem.png ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 11:34 Message: Logged In: YES user_id=33168 Originator: NO Run ulimit -a on both the OS X machine and FreeBSD machine. My guess is that the heap size (possibly called virtual memory) is lower on the OS X box and not enough to allow Python to do the work. ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-17 11:28 Message: Logged In: YES user_id=201298 Originator: YES Still trying to find a way to verify what this problem is. Since it's a python script file[1] that generates the error, and python itself that keeps requesting more memory as a result[2], what other information can I provide? It seems like that in itself is a python code test, since nothing else is involved by python code (excluding the xml files it's choking on). This is OS-specific, as it works fine in FreeBSD 6.2. Repro-ing it would require someone to run OS X and install the MacPorts infrastructure. 1. /opt/local/bin/xml2po: a /opt/local/bin/python script text executable 2. Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region Python(24212) malloc: *** set a breakpoint in szone_error to debug (null)Python(24212) malloc: *** vm_allocate(size=1069056) failed (error code=3) Python(24212) malloc: *** error: can't allocate region File Added: build.log ---------------------------------------------------------------------- Comment By: paul beard (paulbeard) Date: 2007-06-15 19:00 Message: Logged In: YES user_id=201298 Originator: YES I don't know how to devise a test case but let me see if I can get some help on this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-15 18:55 Message: Logged In: YES user_id=33168 Originator: NO This isn't clearly a python problem. Can you provide a self-contained test case that includes just python code that demonstrates this problem? (ie, something that we can reproduce) It looks like a ulimit might be set too low. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738193&group_id=5470 From noreply at sourceforge.net Mon Jun 18 04:53:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 19:53:48 -0700 Subject: [ python-Bugs-1738754 ] Tutorial error in 3.1.2 Strings Message-ID: Bugs item #1738754, was opened at 2007-06-17 13:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738754&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: otan (otan) >Assigned to: Neal Norwitz (nnorwitz) Summary: Tutorial error in 3.1.2 Strings Initial Comment: The backslash is removed by the interpreter in this context: >>> '"Isn\'t," she said.' '"Isn\'t," she said.' correct is: >>> '"Isn\'t," she said.' '"Isn't," she said.' This might be confusing especially for beginners! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-17 19:53 Message: Logged In: YES user_id=33168 Originator: NO This is correct in context. If it was printed (ie, the str()), it would be correct to remove the backslash. In this case it's taking the repr(), so the backslash must be in there. >>> '"Isn\'t," she said.' '"Isn\'t," she said.' >>> print '"Isn\'t," she said.' "Isn't," she said. Or more specifically: >>> print repr('"Isn\'t," she said.') '"Isn\'t," she said.' >>> print str('"Isn\'t," she said.') "Isn't," she said. I only wish I had noticed there wasn't a print before checking in a "fix". :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738754&group_id=5470 From noreply at sourceforge.net Mon Jun 18 16:32:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 07:32:28 -0700 Subject: [ python-Bugs-1739107 ] Bug assigning list comprehension to __slots__ in python 2.5 Message-ID: Bugs item #1739107, was opened at 2007-06-18 10: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=1739107&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fran?ois Desloges (fdesloges) Assigned to: Nobody/Anonymous (nobody) Summary: Bug assigning list comprehension to __slots__ in python 2.5 Initial Comment: I use the package 2.5-4.1mdv2007.1.i586 in mandriva. I don't know if this has already been reported elsewhere but the following code: a= ['C','D'] class A(object): __slots__ = a + ['__'+name for name in a] def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) a = A() results is an a.name attribute with value 'D'. But using : b= tuple('C','D') class B(object): __slots__ = b + tuple('__'+name for name in b) def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) b = B() b appropriately do not have a b.name attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739107&group_id=5470 From noreply at sourceforge.net Mon Jun 18 16:41:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 07:41:58 -0700 Subject: [ python-Bugs-1739115 ] shutil.rmtree's error message is confusing Message-ID: Bugs item #1739115, was opened at 2007-06-18 16:41 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=1739115&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.rmtree's error message is confusing Initial Comment: If you run shutil.rmtree(something) on Windows where something is file and not a directory, you get the following exception: Traceback (most recent call last): File "", line 1, in File "C:\Python25\Lib\shutil.py", line 161, in rmtree onerror(os.listdir, path, sys.exc_info()) File "C:\Python25\Lib\shutil.py", line 159, in rmtree names = os.listdir(path) WindowsError: [Error 22] The directory name is invalid: 'foobar/*.*' The error message is pretty confusing and it shouldn't be to hard to fix it. Plus, if it shouldn't be possible to remove files with shutil.rmtree(), then the docs should say so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739115&group_id=5470 From noreply at sourceforge.net Mon Jun 18 16:43:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 07:43:50 -0700 Subject: [ python-Bugs-1739118 ] Investigated ref leak report related to thread(regrtest.py - Message-ID: Bugs item #1739118, was opened at 2007-06-18 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=1739118&group_id=5470 Please note that this 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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Investigated ref leak report related to thread(regrtest.py - Initial Comment: Hello. I investigated ref leak report related to thread. Please run python regrtest.py -R :: test_leak.py (attached file) Sometimes ref leak is reported. # I saw this as regression failure on python-checkins. # total ref count 92578 -> 92669 _Condition 2 Thread 6 _Event 1 bool 10 instancemethod 1 code 2 dict 9 file 1 frame 3 function 2 int 1 list 2 builtin_function_or_method 5 NoneType 2 str 27 thread.lock 7 tuple 5 type 5 Probably this happens because threading.Thread is implemented as Python code, (expecially threading.Thread#join), the code of regrtest.py if i >= nwarmup: deltas.append(sys.gettotalrefcount() - rc - 2) can run before thread really quits. (before Moudles/threadmodule.c t_bootstrap()'s Py_DECREF(boot->func); Py_DECREF(boot->args); Py_XDECREF(boot->keyw); runs) So I experimentally inserted the code to wait for thread termination. (attached file experimental.patch) And I confirmed error was gone. # Sorry for hackish patch which only runs on windows. It should run # on other platforms if you replace Sleep() in Python/sysmodule.c # sys_debug_ref_leak_leave() with appropriate function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739118&group_id=5470 From noreply at sourceforge.net Mon Jun 18 17:20:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 08:20:25 -0700 Subject: [ python-Bugs-1739107 ] Bug assigning list comprehension to __slots__ in python 2.5 Message-ID: Bugs item #1739107, was opened at 2007-06-18 14:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739107&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Private: No Submitted By: Fran?ois Desloges (fdesloges) Assigned to: Nobody/Anonymous (nobody) Summary: Bug assigning list comprehension to __slots__ in python 2.5 Initial Comment: I use the package 2.5-4.1mdv2007.1.i586 in mandriva. I don't know if this has already been reported elsewhere but the following code: a= ['C','D'] class A(object): __slots__ = a + ['__'+name for name in a] def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) a = A() results is an a.name attribute with value 'D'. But using : b= tuple('C','D') class B(object): __slots__ = b + tuple('__'+name for name in b) def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) b = B() b appropriately do not have a b.name attribute. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-18 15:20 Message: Logged In: YES user_id=849994 Originator: NO Sorry, I can't follow you. Why should b have a "name" attribute? Also, is it intentional that your __init is not named __init__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739107&group_id=5470 From noreply at sourceforge.net Mon Jun 18 17:21:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 08:21:57 -0700 Subject: [ python-Bugs-1739107 ] Bug assigning list comprehension to __slots__ in python 2.5 Message-ID: Bugs item #1739107, was opened at 2007-06-18 14:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739107&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Fran?ois Desloges (fdesloges) Assigned to: Nobody/Anonymous (nobody) Summary: Bug assigning list comprehension to __slots__ in python 2.5 Initial Comment: I use the package 2.5-4.1mdv2007.1.i586 in mandriva. I don't know if this has already been reported elsewhere but the following code: a= ['C','D'] class A(object): __slots__ = a + ['__'+name for name in a] def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) a = A() results is an a.name attribute with value 'D'. But using : b= tuple('C','D') class B(object): __slots__ = b + tuple('__'+name for name in b) def __init(self, c, d): self.__C = c self.__D = d C = property(lambda self: self.__C) D = property(lambda self: self.__D) b = B() b appropriately do not have a b.name attribute. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-18 15:21 Message: Logged In: YES user_id=849994 Originator: NO Ah, strike my last comment. This is not a bug, or at least not fixable, since list comprehensions do leak their iteration variable into the enclosing scope, while generator expressions don't. They will stop doing this in Py3k. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-18 15:20 Message: Logged In: YES user_id=849994 Originator: NO Sorry, I can't follow you. Why should b have a "name" attribute? Also, is it intentional that your __init is not named __init__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739107&group_id=5470 From noreply at sourceforge.net Mon Jun 18 19:23:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 10:23:38 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 08:05 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 13:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. ---------------------------------------------------------------------- Comment By: Arno Bakker (abakker) Date: 2007-06-14 08:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Mon Jun 18 19:48:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 10:48:02 -0700 Subject: [ python-Bugs-1739118 ] Investigated ref leak report related to thread(regrtest.py - Message-ID: Bugs item #1739118, was opened at 2007-06-18 23:43 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739118&group_id=5470 Please note that this 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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Investigated ref leak report related to thread(regrtest.py - Initial Comment: Hello. I investigated ref leak report related to thread. Please run python regrtest.py -R :: test_leak.py (attached file) Sometimes ref leak is reported. # I saw this as regression failure on python-checkins. # total ref count 92578 -> 92669 _Condition 2 Thread 6 _Event 1 bool 10 instancemethod 1 code 2 dict 9 file 1 frame 3 function 2 int 1 list 2 builtin_function_or_method 5 NoneType 2 str 27 thread.lock 7 tuple 5 type 5 Probably this happens because threading.Thread is implemented as Python code, (expecially threading.Thread#join), the code of regrtest.py if i >= nwarmup: deltas.append(sys.gettotalrefcount() - rc - 2) can run before thread really quits. (before Moudles/threadmodule.c t_bootstrap()'s Py_DECREF(boot->func); Py_DECREF(boot->args); Py_XDECREF(boot->keyw); runs) So I experimentally inserted the code to wait for thread termination. (attached file experimental.patch) And I confirmed error was gone. # Sorry for hackish patch which only runs on windows. It should run # on other platforms if you replace Sleep() in Python/sysmodule.c # sys_debug_ref_leak_leave() with appropriate function. ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-06-19 02:48 Message: Logged In: YES user_id=1200846 Originator: YES Sorry, I updated the patch. Moved fprintf(stderr, "================= thread leave\n"); current_thread_count--; in threadmodule.c just before PyThread_exit_thread(). File Added: archive.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739118&group_id=5470 From noreply at sourceforge.net Tue Jun 19 00:28:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 15:28:26 -0700 Subject: [ python-Bugs-1682241 ] Problems with urllib2 read() Message-ID: Bugs item #1682241, was opened at 2007-03-16 16:00 Message generated for change (Comment added) made by andyshorts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... ---------------------------------------------------------------------- Comment By: AndyShorts (andyshorts) Date: 2007-06-18 22:28 Message: Logged In: YES user_id=1563697 Originator: NO While a newbie to Python I would like to point out that RFC2616 (the HTTP/1.1 spec) does allow for byte ranges to be requested and that these could be used to mimic seek &c. In order to do so though the client must retain the file pointer itself etc. However, given my experience of real world servers you are never sure if the target will support them - it need not - and even if it does proxies (both visible and transparent) are free to utterly trash these requests as they see fit. I've gained this the hard way while writing HTTP client software :-) The only safe thing to do with HTTP data is treat it as a stream and if you want to seek through it then your choices are: a. Buffer it locally and access it that way b. Keep opening and closing the resource and reading through to where you want to be. imo the urllib.urlopen acts in the only sane way possible. [btw this is my first post so sorry if this is OT - though I notice this thread has gone into torpor] ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-04-27 11:57 Message: Logged In: YES user_id=1421845 Originator: NO > import urllib > urlobj = urllib.urlopen("someurl") > header = urlobj.read(1) > # some other operations (no other urlobj.read()) > contents = header + urlobj.read() This is effectively buffering the output, which is a perfectly acceptable solution... although I'd write like this: import urllib class BufferedReader(object): def __init__(self, fileobj, buffsize = 8192): def mark(self, maxbytes = 8192): def seek(self): br = BufferedReader(urllib.urlopen()) br.mark() header = br.read(1) br.seek() contents = br.read() That way you store all bytes that have been read. Rather than hoping nobody calls read(). > On the contrary I'm pretty sure using a sequential access this can be done > without doing these workarounds. Right now sequential access is provided without keeping a copy in memory. The issue arises when you want random access, however; urlobjs have no indication as to whether you're going to call seek(). As such, to provide the method they must assume you will call it. Therefore, regardless of whether seek() is actually called or not, a copy must be kept to offer the *possibility* that it can be called. You can work around this by offering the degenerate seek() provided by BufferedReader, but that's functionality that belongs in it's own class anyway. > anyway I don't understand a thing: HTTP can't delegate the server to > seek() the file? For one thing, its not supported by the standard. For another, it would be a waste of server resources, bandwidth and to top it off it would be really slow... even slower than using StringIO. HTTP resources are not simply files served up by httpd, they can also be dynamically generated content... How is an HTTP server supposed to seek backward and forward in a page that is programatically generated? Go try an tell web developers that they need to keep a copy of every page requested indefinitely, in case you want to send a SEEK request. HTTP resources are not local. To treat them as local you must make then local by putting them in a container, such as StringIO, a buffer or a local file. It's that simple. To try and abstract this fact would result in major performance issues or unreliability, or both. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-04-27 09:26 Message: Logged In: YES user_id=1403274 Originator: YES If you don't want the intere file on your memory, there's two solutions: ---------- import urllib urlobj = urllib.urlopen("someurl") header = urlobj.read(1) # some other operations (no other urlobj.read()) contents = header + urlobj.read() ---------- I don't think it's a --good-- solution, because some other programmers can do other read() operations and mess all the result. The other solution is: ---------- def readall(x) : url = x.geturl x.close() try : y = urllib.openurl(url) except : return None return y.read() import urllib urlobj = urllib.urlopen("someurl") header = urlobj.read(1) # some other operations contents = readall(urlobj) ---------- This is still a bad solution (two calls to the server for the same file). On the contrary I'm pretty sure using a sequencial access this can be done without doing these workarounds. (anyway I don't understand a thing: HTTP can't delegate the server to seek() the file?) ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-04-27 03:36 Message: Logged In: YES user_id=1421845 Originator: NO > In my opinion it's not complicated, it's convoluted. I must use two > object to handle one data stream. seek() is not a stream operation. It is a random access operation (file-like != stream). If you were only trying to use stream operations then you wouldn't have these problems. Each class provides a separate functionality, urllib gets the file while StringIO stores it. The fact that these responsibilities are given to different classes should not be surprising since the represent separately useful concepts that abstract different things. It's not convoluted, it's good design. If every class tried to do everything, pretty soon you're adding solve_my_business_problem_using_SOA() to __builtins__ and nobody wants that. > Furthermore it's a waste of resources. I must copy data to another > object. Luckily in my script I download and handle only little files. But what if > a python program must handle big files? This is exactly why urllib *doesn't* provide seek. Deep down in the networking library there's a socket with a 8KiB buffer talking to the HTTP server. No matter how big the file you're getting with urllib, once that buffer is full the socket starts dropping packets. To provide seek(), urllib would need to keep an entire copy of the file that was retrieved, (or provide mark()/seek(), but those have wildly different semantics from the seek()s were used to in python, and besides they're too Java). This works fine if you're only working with small files, but you raise a good point: "But what if a python program must handle big files?". What about really big files (say a Knoppix DVD ISO)? Sure you could use urlretrieve, but what if urlretrive is implemented in terms of urlopen? Sure urllib could implement seek (with the same semantics as file.seek()) but that would mean breaking urllib for any resource big enough that you don't want the whole thing in memory. >> You can check the type of the response content before you try >> to uncompress it via the Content-Encoding header of the >> response >It's not a generic solution The point of this suggestion is not that this is the be all and end all solution, but that code that *needs* seek can probably be rewritten so that it does not. Either that or you could implement BufferedReader with the methods mark() and seek() and wrap the result of urlopen. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-04-26 20:41 Message: Logged In: YES user_id=1403274 Originator: YES In my opinion it's not complicated, it's convoluted. I must use two object to handle one data stream. Furthermore it's a waste of resources. I must copy data to another object. Luckily in my script I download and handle only little files. But what if a python program must handle big files? If seek() can't be used (an except is raised), urllib could use a sequential access method. ---------------------------------------------------------------------- Comment By: Calvin Spealman (ironfroggy) Date: 2007-04-26 13:55 Message: Logged In: YES user_id=112166 Originator: NO I have to agree that this is not a bug. HTTP responses are strings, not random access files. Adding a seek would have disastrous performance penalties. If you think the work around is too complicated, I can't understand why. ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-21 01:39 Message: Logged In: YES user_id=1421845 Originator: NO > I use the method you wrote, but this must be done manually, > and I don't know why. read() is a stream processing method, whereas seek() is a random access processing method. HTTP resources are in essence streams so they implement read() but not seek(). Trying to shoehorn a stream to act like a random access file has some rather important technical implications. For example: what happens when an HTTP resource is larger than available memory and we try to maintain a full featured seek() implementation? > so what is urlopen() for? Fetching a webpage or RSS feed and feeding it to a parser, for example. StringIO is a class that was designed to implement feature complete, random access, file-like object behavior that can be wrapped around a stream. StringIO can and should be used as an adapter for when you have a stream that you need random access to. This allows designers the freedom to simply implement a good read() implementation and let clients wrap the output in a StringIO if needed. If in your application you always want random access and you don't have to deal with large files: def my_urlopen(*args, **kwargs): return StringIO.StringIO(urllib2.urlopen(*args, **kwargs).read()) Python makes delegation trivially easy. In essence, urlfiles (the result of urllib2.urlopen()) and regular files (the result of open()) behave differently because they implement different interfaces. If you use the common interface (read), then you can treat them equally. If you use the specialized interface (seek, tell, etc.) you'll have trouble. The solution is wrap the general objects in a specialized object that implements the desired interface, StringIO. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-20 08:59 Message: Logged In: YES user_id=1403274 Originator: YES > If you need to seek, you can wrap the file-like object in a > StringIO (which is what urllib would have to do internally > [...] ) I think it's really a bug, or at least a non-pythonic method. I use the method you wrote, but this must be done manually, and I don't know why. Actually without this "trick" you can't handle url and file objects together as they don't work in the same manner. I think it's not too complicated using the internal StringIO object in urllib class when I must seek() or use other file-like methods. > You can check the type of the response content before you try > to uncompress it via the Content-Encoding header of the > response It's not a generic solution (thanks anyway for suggested solutions :) ) ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-20 02:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 From noreply at sourceforge.net Tue Jun 19 03:13:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 18:13:32 -0700 Subject: [ python-Bugs-1739118 ] Investigated ref leak report related to thread(regrtest.py - Message-ID: Bugs item #1739118, was opened at 2007-06-18 23:43 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739118&group_id=5470 Please note that this 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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Investigated ref leak report related to thread(regrtest.py - Initial Comment: Hello. I investigated ref leak report related to thread. Please run python regrtest.py -R :: test_leak.py (attached file) Sometimes ref leak is reported. # I saw this as regression failure on python-checkins. # total ref count 92578 -> 92669 _Condition 2 Thread 6 _Event 1 bool 10 instancemethod 1 code 2 dict 9 file 1 frame 3 function 2 int 1 list 2 builtin_function_or_method 5 NoneType 2 str 27 thread.lock 7 tuple 5 type 5 Probably this happens because threading.Thread is implemented as Python code, (expecially threading.Thread#join), the code of regrtest.py if i >= nwarmup: deltas.append(sys.gettotalrefcount() - rc - 2) can run before thread really quits. (before Moudles/threadmodule.c t_bootstrap()'s Py_DECREF(boot->func); Py_DECREF(boot->args); Py_XDECREF(boot->keyw); runs) So I experimentally inserted the code to wait for thread termination. (attached file experimental.patch) And I confirmed error was gone. # Sorry for hackish patch which only runs on windows. It should run # on other platforms if you replace Sleep() in Python/sysmodule.c # sys_debug_ref_leak_leave() with appropriate function. ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-06-19 10:13 Message: Logged In: YES user_id=1200846 Originator: YES Umm, maybe still not enough? applied this patch (fix for 3 str leaks) test_urllib2_localnet.py still reports leaks sometimes. Index: Lib/test/test_urllib2_localnet.py =================================================================== --- Lib/test/test_urllib2_localnet.py (revision 56002) +++ Lib/test/test_urllib2_localnet.py (working copy) @@ -208,7 +208,7 @@ testing. """ - digest_auth_handler = DigestAuthHandler() + digest_auth_handler = None def log_message(self, format, *args): # Uncomment the next line for debugging. @@ -240,6 +240,7 @@ PROXY_URL = "http://127.0.0.1:%d" % PORT def setUp(self): + FakeProxyHandler.digest_auth_handler = DigestAuthHandler() FakeProxyHandler.digest_auth_handler.set_users({ self.USER : self.PASSWD }) @@ -257,6 +258,7 @@ def tearDown(self): self.server.stop() + FakeProxyHandler.digest_auth_handler = None def test_proxy_with_bad_password_raises_httperror(self): self._digest_auth_handler.add_password(self.REALM, self.URL, /////////////////////////// test_urllib2_localnet leaked [2, 0, 0, 0] references, sum=2 # it is now rare case though.... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-06-19 02:48 Message: Logged In: YES user_id=1200846 Originator: YES Sorry, I updated the patch. Moved fprintf(stderr, "================= thread leave\n"); current_thread_count--; in threadmodule.c just before PyThread_exit_thread(). File Added: archive.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739118&group_id=5470 From noreply at sourceforge.net Tue Jun 19 13:16:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 04:16:41 -0700 Subject: [ python-Bugs-1739659 ] Interactive help raise exception while listing modules Message-ID: Bugs item #1739659, was opened at 2007-06-19 15:16 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=1739659&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help raise exception while listing modules Initial Comment: Pydoc module shouldn't try to get slice from the dict's keys view and should use floor division where appropriate. The fix attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 From noreply at sourceforge.net Tue Jun 19 13:55:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 04:55:13 -0700 Subject: [ python-Feature Requests-1739678 ] make colon optional Message-ID: Feature Requests item #1739678, was opened at 2007-06-19 13: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=1739678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: make colon optional Initial Comment: Make colon optional after class Abcd: def xyz(): if n=m: ... etc. P.S. Wonder why I did not find this FR already ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 From noreply at sourceforge.net Tue Jun 19 13:57:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 04:57:27 -0700 Subject: [ python-Feature Requests-1739679 ] add multi-line comments Message-ID: Feature Requests item #1739679, was opened at 2007-06-19 13: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=1739679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: add multi-line comments Initial Comment: python lacks something like /* commentblock lalala more comment another line */ which I would like to use particularily while debugging to remove some lines of code temorarily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:27:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:27:41 -0700 Subject: [ python-Feature Requests-1739678 ] make colon optional Message-ID: Feature Requests item #1739678, was opened at 2007-06-19 11:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: make colon optional Initial Comment: Make colon optional after class Abcd: def xyz(): if n=m: ... etc. P.S. Wonder why I did not find this FR already ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:27 Message: Logged In: YES user_id=849994 Originator: NO This was pondered a long time ago, and usability surveys showed that the colon adds quite a lot in terms of readability, so it will stay. Marking as Rejected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:33:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:33:37 -0700 Subject: [ python-Bugs-1739659 ] Interactive help raise exception while listing modules Message-ID: Bugs item #1739659, was opened at 2007-06-19 11:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help raise exception while listing modules Initial Comment: Pydoc module shouldn't try to get slice from the dict's keys view and should use floor division where appropriate. The fix attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:33 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 56037. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:36:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:36:18 -0700 Subject: [ python-Bugs-1737864 ] logging.exception() does not allow empty string Message-ID: Bugs item #1737864, was opened at 2007-06-15 14:50 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Dmitrii Tisnek (dimaq) Assigned to: Vinay Sajip (vsajip) Summary: logging.exception() does not allow empty string Initial Comment: Due to the following code, logging.exception("") does not work. I suggest replacing s[-1]=="\n" with s.endswith("\n"). logging/__init__.py:formatException(): --snip-- if s[-1] == "\n": s = s[:-1] return s ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:36 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 56038, 56039 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-15 16:39 Message: Logged In: YES user_id=849994 Originator: NO Sounds reasonable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:38:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:38:53 -0700 Subject: [ python-Bugs-1739115 ] shutil.rmtree's error message is confusing Message-ID: Bugs item #1739115, was opened at 2007-06-18 14:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739115&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.rmtree's error message is confusing Initial Comment: If you run shutil.rmtree(something) on Windows where something is file and not a directory, you get the following exception: Traceback (most recent call last): File "", line 1, in File "C:\Python25\Lib\shutil.py", line 161, in rmtree onerror(os.listdir, path, sys.exc_info()) File "C:\Python25\Lib\shutil.py", line 159, in rmtree names = os.listdir(path) WindowsError: [Error 22] The directory name is invalid: 'foobar/*.*' The error message is pretty confusing and it shouldn't be to hard to fix it. Plus, if it shouldn't be possible to remove files with shutil.rmtree(), then the docs should say so. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:38 Message: Logged In: YES user_id=849994 Originator: NO Updated the docs in rev. 56040, 56041 (2.5). IMO the error message is clear enough now if you read the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739115&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:40:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:40:48 -0700 Subject: [ python-Bugs-1738441 ] shutil.move doesn't work when only case changes Message-ID: Bugs item #1738441, was opened at 2007-06-16 18:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel Gambetta (ggambett) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move doesn't work when only case changes Initial Comment: shutil.move() appears to fail silently when the source and destination filenames only differ in case (ie "SomeFile" and "Somefile"). This is with python 2.4.3-18.fc6, on a case-sensitive filesystem (ext3), so this rename *is* meaningful. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:40 Message: Logged In: YES user_id=849994 Originator: NO This is quite strange. Gabriel, could you try to use another Python version provided by Fedora, or even a self-compiled one? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-17 05:08 Message: Logged In: YES user_id=942711 Originator: NO I guess, this should be very much python 2.4.3-18.fc6 specific. While I have python 2.3.4, python 2.5, python 2.6a0. I am unable to reproduce this defect. Having said that, help(shutil.move) mentions about the various issues of moving the implementation glosses over. Please provide some more details or anyone with python 2.4.3-18 should be able to verify it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:41:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:41:46 -0700 Subject: [ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Message-ID: Bugs item #1738559, was opened at 2007-06-17 07:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:44:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:44:30 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 12:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 17:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. ---------------------------------------------------------------------- Comment By: Arno Bakker (abakker) Date: 2007-06-14 12:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Tue Jun 19 16:03:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 07:03:54 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 14:05 Message generated for change (Comment added) made by abakker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- >Comment By: Arno Bakker (abakker) Date: 2007-06-19 16:03 Message: Logged In: YES user_id=216477 Originator: YES Is that GIL & searching problem reported separately somewhere, otherwise I'm hereby submitting that bug ;o) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 14:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 19:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. ---------------------------------------------------------------------- Comment By: Arno Bakker (abakker) Date: 2007-06-14 14:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Tue Jun 19 17:29:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:29:02 -0700 Subject: [ python-Bugs-1737127 ] re.findall hangs python completely Message-ID: Bugs item #1737127, was opened at 2007-06-14 12:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=849994 Originator: NO It's a feature request, not a bug, but it is submitted, yes :) ---------------------------------------------------------------------- Comment By: Arno Bakker (abakker) Date: 2007-06-19 14:03 Message: Logged In: YES user_id=216477 Originator: YES Is that GIL & searching problem reported separately somewhere, otherwise I'm hereby submitting that bug ;o) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 17:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. ---------------------------------------------------------------------- Comment By: Arno Bakker (abakker) Date: 2007-06-14 12:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 From noreply at sourceforge.net Tue Jun 19 17:31:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:31:28 -0700 Subject: [ python-Feature Requests-1739679 ] add multi-line comments Message-ID: Feature Requests item #1739679, was opened at 2007-06-19 11:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 Please note that this 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: Rejected Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: add multi-line comments Initial Comment: python lacks something like /* commentblock lalala more comment another line */ which I would like to use particularily while debugging to remove some lines of code temorarily. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 15:31 Message: Logged In: YES user_id=849994 Originator: NO For that, you should use a decent editor that can comment out multiple lines of code at once. Alternatively, if you don't have such an editor, you can enclose the code in triple-quoted strings or put an "if 0:" around it. In any way, Guido pronounced this isn't going to happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 From noreply at sourceforge.net Tue Jun 19 18:57:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 09:57:20 -0700 Subject: [ python-Bugs-1739842 ] xmlrpclib can no longer marshal Fault objects Message-ID: Bugs item #1739842, was opened at 2007-06-19 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=105470&aid=1739842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Bonnet (mbonnet) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib can no longer marshal Fault objects Initial Comment: xmlrpclib attempts to marshal class instances by registering the dump_instance() method as the marshaller for the type. This is how marshalling of Fault objects contained in a tuple (for example, one result in a multicall) is handled. This worked for Fault objects in python2.4 and earlier because they were old-style classes, and their type was always . In python2.5, Exception (and thus Fault, which inherits from it) moved from an old-style class to a new-style class (inheriting from object). This means that rather than type(faultinstance) returning , it returns . This results in xmlrpclib.Marshaller.__dump() throwing TypeError when it encounters a Fault (or any other new-style class). This is a regression from python2.4 and earlier, and is particularly problematic for applications that expect to be able to marshal Fault instances. I've attached a simple patch which allows Fault objects (and all other new-style classes) to be marshalled as structs, the same way Fault objects and old-style classes were in python2.4 and earlier. This fixes the regression caused by the change in the Exception inheritance hierarchy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739842&group_id=5470 From noreply at sourceforge.net Wed Jun 20 01:40:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 16:40:50 -0700 Subject: [ python-Bugs-1720705 ] thread + import => crashes? Message-ID: Bugs item #1720705, was opened at 2007-05-17 13:08 Message generated for change (Comment added) made by andyshorts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720705&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: thread + import => crashes? Initial Comment: I got some experience of crash on Tkinter, so I minimized triger code. (I'll attach it as 'bug.py') Same error happens on released python 2.5.1 binary, trunk built with VC6, and release25-maint built with VC6. (Not every time this error occurs, but frequently) # Here is error message. S:\python\tkinter>bug.py Traceback (most recent call last): File "S:\python\tkinter\bug.py", line 13, in raise RuntimeError() RuntimeError Fatal Python error: PyImport_GetModuleDict: no module dictionary! This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. # Here is stack trace. (Win2000SP4 + VC6) NTDLL! 77f9193c() PyImport_GetModuleDict() line 361 + 10 bytes import_submodule(_object * 0x1e3148b8 __Py_NoneStruct, char * 0x013fe440, char * 0x013fe440) line 2357 + 5 bytes load_next(_object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, char * * 0x013fe554, char * 0x013fe440, int * 0x013fe43c) line 2216 + 17 bytes import_module_level(char * 0x00000000, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 1997 + 35 bytes PyImport_ImportModuleLevel(char * 0x009408cc, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 2068 + 25 bytes builtin___import__(_object * 0x00000000, _object * 0x00b0aaa0, _object * 0x00000000) line 48 + 25 bytes PyCFunction_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 77 + 15 bytes PyObject_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 1860 + 15 bytes PyEval_CallObjectWithKeywords(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x00000000) line 3434 PyEval_EvalFrameEx(_frame * 0x00a5d3e8, int 107) line 2065 fast_function(_object * 0x00000000, _object * * * 0x013fef00, int 1, int 1, int 10152296) line 3651 call_function(_object * * * 0x013fef00, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a706b8, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e80e8, _object * 0x00a706b8, _object * 0x00000002, _object * * 0x00ac86a0, int 2, _object * * 0x00ac86a8, int 0, _object * * 0x00a1ccfc, int 1, _object * 0x00000000) line 2831 + 11 bytes fast_function(_object * 0x00000001, _object * * * 0x013ff418, int 2, int 2, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ff418, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00ac8528, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e4c88, _object * 0x00ac8528, _object * 0x00000002, _object * * 0x00a5b590, int 2, _object * * 0x00a5b598, int 0, _object * * 0x00a1cc1c, int 1, _object * 0x00000000) line 2831 + 11 bytes fast_function(_object * 0x00000001, _object * * * 0x013ff930, int 2, int 2, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ff930, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a5b440, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e44a8, _object * 0x00a5b440, _object * 0x00000001, _object * * 0x00a5b224, int 1, _object * * 0x00a5b228, int 0, _object * * 0x00a1e9cc, int 2, _object * 0x00000000) line 2831 + 11 bytes fast_function(_object * 0x00000002, _object * * * 0x013ffe48, int 1, int 1, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ffe48, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a5b0e0, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009d5ce8, _object * 0x00a5b0e0, _object * 0x00000000, _object * * 0x008c104c, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 2831 + 11 bytes function_call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 522 + 64 bytes PyObject_Call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 1860 + 15 bytes PyEval_CallObjectWithKeywords(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x00000000) line 3434 t_bootstrap(void * 0x008c8508) line 425 + 26 bytes bootstrap(void * 0x0022f8cc) line 179 + 7 bytes _threadstart(void * 0x009bff78) line 187 + 13 bytes KERNEL32! 77e5b396() ---------------------------------------------------------------------- Comment By: AndyShorts (andyshorts) Date: 2007-06-19 23:40 Message: Logged In: YES user_id=1563697 Originator: NO I have had a look at this using the latest trunk code built using VisualStudio 2005 on Windows XP SP2. I modified the source scripts from bug2.zip so that the code was wrapped in a function and added the same code as a function to main.py; I did this so as to see if the difference in calling method would affect it at all, i.e. if by removing the import of sub.py it would make the issue any better or worse. Running it in the debugger and modifying the debug output from the engine to include Win32 thread identifiers seems to suggest that the main thread is exiting and cleaning up the Python system modules and then the Win32 system is closing the other Python threads which are then trying to access the global Python modules and they can't find them and they exit. [Though as a /total/ newbie to Python I am only about 40-50% confident of this] And as to be expected the error does not happen all the time - I can run the same script and maybe get the error as listed maybe about 60-70% of the time. Interestingly in main.c there is a call to a function called "WaitForThreadShutdown" - but sadly it only looks to see if the Python threading module has been imported. I think extending this function to include the Python thread module might be the way to go - but I really don't know and I certainly haven't got to grips with the Python source yet. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-05-17 14:49 Message: Logged In: YES user_id=1200846 Originator: YES Sorry, Tkinter and urllib is not source of problem. I changed summary to "thread + import => crashes?". # I'll attach reproducable script as "bug.zip". please run main.py Probabry "import" in another thread causes crash, but I'll investigate more. File Added: bug.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720705&group_id=5470 From noreply at sourceforge.net Wed Jun 20 15:02:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 06:02:18 -0700 Subject: [ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Message-ID: Bugs item #1738559, was opened at 2007-06-17 07:29 Message generated for change (Comment added) made by shuvo1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo ---------------------------------------------------------------------- >Comment By: shuvo (shuvo1470) Date: 2007-06-20 13:02 Message: Logged In: YES user_id=1819895 Originator: YES No. These are last error messages while exiting build process. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 From noreply at sourceforge.net Wed Jun 20 22:19:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 13:19:28 -0700 Subject: [ python-Bugs-1740572 ] asynchat should call "handle_close" Message-ID: Bugs item #1740572, was opened at 2007-06-20 22: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=1740572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat should call "handle_close" Initial Comment: When 'close_when_done' is used and the producer is consumed 'close' method is called. IMO a better delegation design would be calling handle_close instead, just like recv already does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 From noreply at sourceforge.net Wed Jun 20 22:19:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 13:19:52 -0700 Subject: [ python-Bugs-1740572 ] asynchat should call "handle_close" Message-ID: Bugs item #1740572, was opened at 2007-06-20 22:19 Message generated for change (Settings changed) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asynchat should call "handle_close" Initial Comment: When 'close_when_done' is used and the producer is consumed 'close' method is called. IMO a better delegation design would be calling handle_close instead, just like recv already does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 From noreply at sourceforge.net Wed Jun 20 23:24:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 14:24:45 -0700 Subject: [ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Message-ID: Bugs item #1740599, was opened at 2007-06-20 16: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=1740599&group_id=5470 Please note that this 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 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 From noreply at sourceforge.net Thu Jun 21 03:44:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 18:44:47 -0700 Subject: [ python-Bugs-1734860 ] sitecustomize.py not found Message-ID: Bugs item #1734860, was opened at 2007-06-11 06:33 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: www.spirito.de (openspirito) Assigned to: Nobody/Anonymous (nobody) Summary: sitecustomize.py not found Initial Comment: Under my configuration (Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32) the sitecustomize.py is not found in the current directory. I added some testing code into site.def execsitecustomize() and found out, that the current path is not part of sys.path, but later on in the main program it is. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-20 22:44 Message: Logged In: YES user_id=479790 Originator: NO This is due to patch and is documented in the NEWS.txt file for 2.5: - Patch #1232023: Stop including current directory in search path on Windows. ---------------------------------------------------------------------- Comment By: www.spirito.de (openspirito) Date: 2007-06-14 05:53 Message: Logged In: YES user_id=1103348 Originator: YES It worked like this in all previous versions of Python. I think it is very useful e.g. if you work with development versions of other libraries. Better than adding import paths via sys.path += ['abc'] at the top of Python scripts. Or is there another or better way to add project specific import paths? But at least there should be a notice in the documentation of Python 2.5 that this behaviour changed. I spend some time to find out that it was changed. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-14 04:43 Message: Logged In: YES user_id=479790 Originator: NO I don't think that allowing sitecustomize.py to be run from the current directory would be a good idea, as it gets executed automatically on any invocation of the Python program (and it could contain arbitrary code). You can put sitecustomize.py inside Lib or Lib\site-packages and it will be picked fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734860&group_id=5470 From noreply at sourceforge.net Thu Jun 21 07:40:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 22:40:39 -0700 Subject: [ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Message-ID: Bugs item #1740599, was opened at 2007-06-20 14:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 Please note that this 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 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-20 22:40 Message: Logged In: YES user_id=33168 Originator: NO I looked at the attachment and it's not clear how you are using this given there is a main(). The main() doesn't have a Py_Initialize() either. So I'm guessing that was left over and you are really using this as a module. Can you reduce it to the minimal test case? Remove the main() and all the methods that are not used and will cause the crash. Also what is the python code that you execute. Basically can you demonstrate a complete scenario (how to build and execute) to cause the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 From noreply at sourceforge.net Thu Jun 21 07:41:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 22:41:45 -0700 Subject: [ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Message-ID: Bugs item #1740599, was opened at 2007-06-20 14:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 Please note that this 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 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-20 22:41 Message: Logged In: YES user_id=33168 Originator: NO I forgot to mention about the putenv()s. Are those necessary? The directories won't exist on any one else's box. If those are not necessary to cause the assertion, remove those too from the minimal test case. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-20 22:40 Message: Logged In: YES user_id=33168 Originator: NO I looked at the attachment and it's not clear how you are using this given there is a main(). The main() doesn't have a Py_Initialize() either. So I'm guessing that was left over and you are really using this as a module. Can you reduce it to the minimal test case? Remove the main() and all the methods that are not used and will cause the crash. Also what is the python code that you execute. Basically can you demonstrate a complete scenario (how to build and execute) to cause the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 From noreply at sourceforge.net Thu Jun 21 20:36:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 11:36:53 -0700 Subject: [ python-Bugs-1741130 ] struct.pack("I", "foo"); struct.pack("L", "foo") should fail Message-ID: Bugs item #1741130, was opened at 2007-06-21 20: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=1741130&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: struct.pack("I", "foo"); struct.pack("L", "foo") should fail Initial Comment: The following code prints out "I L" when run with python 2.5 and current SVN trunk (if you silence the DeprecationWarnings): """ import struct for c in "bBhHiIlLqQdf": try: struct.pack(c, "foo bar") except struct.error: pass else: print c """ It works correctly (prints nothing) in Python 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741130&group_id=5470 From noreply at sourceforge.net Thu Jun 21 22:55:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 13:55:14 -0700 Subject: [ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Message-ID: Bugs item #1740599, was opened at 2007-06-20 16:24 Message generated for change (Comment added) made by stuffduff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 Please note that this 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 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. ---------------------------------------------------------------------- >Comment By: Sean (stuffduff) Date: 2007-06-21 15:55 Message: Logged In: YES user_id=1093262 Originator: YES Very stripped down, but complex instructions. See the README file. PUTENV replaces the need for an environment variable. File Added: pyGTMbug.tar.gz ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:41 Message: Logged In: YES user_id=33168 Originator: NO I forgot to mention about the putenv()s. Are those necessary? The directories won't exist on any one else's box. If those are not necessary to cause the assertion, remove those too from the minimal test case. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:40 Message: Logged In: YES user_id=33168 Originator: NO I looked at the attachment and it's not clear how you are using this given there is a main(). The main() doesn't have a Py_Initialize() either. So I'm guessing that was left over and you are really using this as a module. Can you reduce it to the minimal test case? Remove the main() and all the methods that are not used and will cause the crash. Also what is the python code that you execute. Basically can you demonstrate a complete scenario (how to build and execute) to cause the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 From noreply at sourceforge.net Fri Jun 22 01:33:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 16:33:01 -0700 Subject: [ python-Bugs-1741218 ] string formatter %x problem with indirectly given long Message-ID: Bugs item #1741218, was opened at 2007-06-21 16: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=1741218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenji Noguchi (kenjinoguchi) Assigned to: Nobody/Anonymous (nobody) Summary: string formatter %x problem with indirectly given long Initial Comment: "%x" % v fails if the v is a instance, and its __int__ returns larger than 0x80000000 on 32bit OS. I've reported the problem at Python ML. http://mail.python.org/pipermail/python-list/2007-June/446103.html "%x" % int(v) "%x" % 0x80000000L above two work fine because string formatter processes a long value exceptionally. It looks inconsistent. So I made this patch. --- stringobject.c.org 2007-06-21 13:57:54.745877000 -0700 +++ stringobject.c 2007-06-21 13:59:19.576646000 -0700 @@ -4684,6 +4684,15 @@ case 'X': if (c == 'i') c = 'd'; + /* try to convert objects to number*/ + PyNumberMethods *nb; + if ((nb = v->ob_type->tp_as_number) && + nb->nb_int) { + v = (*nb->nb_int) (v); + if(v == NULL) + goto error; + } + if (PyLong_Check(v)) { int ilen; temp = _PyString_FormatLong(v, flags, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741218&group_id=5470 From noreply at sourceforge.net Fri Jun 22 08:16:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 23:16:56 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 22:52 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 06:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 23:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 23:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Fri Jun 22 08:35:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 23:35:16 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 22:52 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 06:35 Message: Logged In: YES user_id=703403 Originator: YES One more result. This is definitely getting suspicious now--I'll submit my patch. >>> from decimal import * >>> getcontext().prec = 3 >>> Decimal(11772).sqrt() Decimal("109") >>> Decimal(11774).sqrt() Decimal("108") ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 06:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 23:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 23:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Fri Jun 22 12:44:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 03:44:25 -0700 Subject: [ python-Bugs-444913 ] cgi.FieldStorage doesn't have __nonzero_ Message-ID: Bugs item #444913, was opened at 2001-07-26 20:21 Message generated for change (Comment added) made by petersidor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 Please note that this 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 Private: No Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage doesn't have __nonzero_ Initial Comment: In some cases cgi.FieldStorage raises an exception on __len__, which means that if you test for truth it will raise an exception (very confusing!). It should just implement def __nonzero__(self): return 1 or something. ---------------------------------------------------------------------- Comment By: Peter Sidor (petersidor) Date: 2007-06-22 10:44 Message: Logged In: YES user_id=1825058 Originator: NO Truth is always to be tested for. :) I am doing something like this: FORM = cgi.FieldStorage() for f in FORM: if f in ['uploaded_file']: uploadedFile = FORM[k] break Later on, I use a function to actually save the uploaded file, perform a couple checks, etc. But it would be definitely nice to be able to test against that object, ie: if uploadedFile: print "stuff" ...instead of, say, storing something into another variable. ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2001-07-26 20:50 Message: Logged In: YES user_id=210337 Logically false or true would be fine -- or just capture the exception and return false (or true) on exception from __len__. I was using some code that returned a string or None, but the FieldStorage object on file upload. I wanted None to be '', so I did: value = value or '' And got what at first seemed like a very weird exception (since the call to __len__ was implicit). It would be nice if the FieldStorage for the file upload was true (as it isn't empty). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-07-26 20:42 Message: Logged In: YES user_id=21627 Adding this nonzero method would break backwards-compatibility: Currently, an object created with cgi.FieldStorage() is logically false, whereas it would be true with this change. Can you give an example where you need to check the truth of a FieldStorage? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 20:31 Message: Logged In: YES user_id=6380 You shouldn't be testing for truth. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 From noreply at sourceforge.net Fri Jun 22 14:28:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 05:28:37 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 19:52 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) >Assigned to: Facundo Batista (facundobatista) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 03:35 Message: Logged In: YES user_id=703403 Originator: YES One more result. This is definitely getting suspicious now--I'll submit my patch. >>> from decimal import * >>> getcontext().prec = 3 >>> Decimal(11772).sqrt() Decimal("109") >>> Decimal(11774).sqrt() Decimal("108") ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 03:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 20:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 20:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Fri Jun 22 15:56:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 06:56:06 -0700 Subject: [ python-Bugs-1741524 ] defined format returns error Message-ID: Bugs item #1741524, was opened at 2007-06-22 13: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=1741524&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ted Bell (ted7234889) Assigned to: Nobody/Anonymous (nobody) Summary: defined format returns error Initial Comment: print round(i[,2]) This returned the error invalid syntex but this round( x[, n]) is out it is shown the reference library under 2.1 Built in functions. I have tried leaving out the comma as well asvarious other combinations to no avail, can someone help please, I need to round a number to two decimal places before outputting to the user. Ted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741524&group_id=5470 From noreply at sourceforge.net Fri Jun 22 16:05:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 07:05:00 -0700 Subject: [ python-Bugs-1741524 ] defined format returns error Message-ID: Bugs item #1741524, was opened at 2007-06-22 13:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741524&group_id=5470 Please note that this 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 Private: No Submitted By: Ted Bell (ted7234889) Assigned to: Nobody/Anonymous (nobody) Summary: defined format returns error Initial Comment: print round(i[,2]) This returned the error invalid syntex but this round( x[, n]) is out it is shown the reference library under 2.1 Built in functions. I have tried leaving out the comma as well asvarious other combinations to no avail, can someone help please, I need to round a number to two decimal places before outputting to the user. Ted ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-22 14:05 Message: Logged In: YES user_id=849994 Originator: NO The square brackets indicate an optional argument: print round(i) print round(i, 2) are both valid calls of round(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741524&group_id=5470 From noreply at sourceforge.net Fri Jun 22 18:06:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 09:06:50 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 18:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Facundo Batista (facundobatista) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2007-06-22 12:06 Message: Logged In: YES user_id=31435 Originator: NO Of course you're right, the spec does say inputs shouldn't be rounded. And that last example is horrendous: sqrt should definitely be monotonic (a floating function f is "monotonic" if it guarantees f(x) >= f(y) whenever x >= y; you found x and y such that x > y but sqrt(x) < sqrt(y) -- ouch!). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 02:35 Message: Logged In: YES user_id=703403 Originator: YES One more result. This is definitely getting suspicious now--I'll submit my patch. >>> from decimal import * >>> getcontext().prec = 3 >>> Decimal(11772).sqrt() Decimal("109") >>> Decimal(11774).sqrt() Decimal("108") ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 02:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 19:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 19:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Fri Jun 22 20:57:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 11:57:50 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 22:52 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Facundo Batista (facundobatista) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 18:57 Message: Logged In: YES user_id=703403 Originator: YES See patch 1741308. I'll contact Mike Cowlishaw to verify that the reference implementation really is buggy. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-06-22 16:06 Message: Logged In: YES user_id=31435 Originator: NO Of course you're right, the spec does say inputs shouldn't be rounded. And that last example is horrendous: sqrt should definitely be monotonic (a floating function f is "monotonic" if it guarantees f(x) >= f(y) whenever x >= y; you found x and y such that x > y but sqrt(x) < sqrt(y) -- ouch!). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 06:35 Message: Logged In: YES user_id=703403 Originator: YES One more result. This is definitely getting suspicious now--I'll submit my patch. >>> from decimal import * >>> getcontext().prec = 3 >>> Decimal(11772).sqrt() Decimal("109") >>> Decimal(11774).sqrt() Decimal("108") ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 06:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 23:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 23:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Sat Jun 23 00:30:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 15:30:10 -0700 Subject: [ python-Bugs-1741898 ] Odd UDP problems in socket library Message-ID: Bugs item #1741898, was opened at 2007-06-22 17:30 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=1741898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay Sherby (bluej774) Assigned to: Nobody/Anonymous (nobody) Summary: Odd UDP problems in socket library Initial Comment: I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info. I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang. for i in range(2): client.sendto(data, (sys.argv[1], 123)) data, address = client.recvfrom(1024) Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP. Thanks for looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 From noreply at sourceforge.net Sat Jun 23 13:37:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 04:37:08 -0700 Subject: [ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Message-ID: Bugs item #1738559, was opened at 2007-06-17 09:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-23 13:37 Message: Logged In: YES user_id=21627 Originator: NO Please report the first errors; the errors you show are likely follow-up errors. If possible, attach the entire build output as a compressed file to this report. ---------------------------------------------------------------------- Comment By: shuvo (shuvo1470) Date: 2007-06-20 15:02 Message: Logged In: YES user_id=1819895 Originator: YES No. These are last error messages while exiting build process. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 14:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 From noreply at sourceforge.net Sat Jun 23 16:07:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 07:07:22 -0700 Subject: [ python-Bugs-1740572 ] asynchat should call "handle_close" Message-ID: Bugs item #1740572, was opened at 2007-06-20 13:19 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asynchat should call "handle_close" Initial Comment: When 'close_when_done' is used and the producer is consumed 'close' method is called. IMO a better delegation design would be calling handle_close instead, just like recv already does. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 07:07 Message: Logged In: YES user_id=341410 Originator: NO Indeed, asynchat.async_chat.refill_buffer() should call handle_close() rather than close(). In the patch I recently provided, it calls handle_close() in the equivalent method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 From noreply at sourceforge.net Sat Jun 23 17:10:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 08:10:25 -0700 Subject: [ python-Bugs-1741898 ] Odd UDP problems in socket library Message-ID: Bugs item #1741898, was opened at 2007-06-22 15:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay Sherby (bluej774) Assigned to: Nobody/Anonymous (nobody) Summary: Odd UDP problems in socket library Initial Comment: I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info. I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang. for i in range(2): client.sendto(data, (sys.argv[1], 123)) data, address = client.recvfrom(1024) Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP. Thanks for looking into it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 08:10 Message: Logged In: YES user_id=341410 Originator: NO Could you produce a small runnable sample, describe what it should produce, and what it actually produces? That would make it much easier for us to help you. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 From noreply at sourceforge.net Sat Jun 23 20:16:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 11:16:54 -0700 Subject: [ python-Bugs-1742164 ] Incorrect docs for optparse OptionParser add_help_option Message-ID: Bugs item #1742164, was opened at 2007-06-23 11:16 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=1742164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docs for optparse OptionParser add_help_option Initial Comment: http://www.python.org/doc/2.5/lib/optparse-creating-parser.html The docs say: "add_help_option (default: True) If true, optparse will add a help option (with option strings "-h" and "-help") to the parser." In fact, it adds option strings "-h" and "--help". Note the additional '-' character as compared to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742164&group_id=5470 From noreply at sourceforge.net Sat Jun 23 21:07:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 12:07:40 -0700 Subject: [ python-Bugs-1742205 ] ZipFile.writestr writes incorrect extended local headers Message-ID: Bugs item #1742205, was opened at 2007-06-23 16: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=1742205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: alexis (asak) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.writestr writes incorrect extended local headers Initial Comment: According to http://www.onicos.com/staff/iz/formats/zip.html the format of an optional extended local header is: Extended local header: Offset Length Contents 0 4 bytes Extended Local file header signature (0x08074b50) 4 4 bytes CRC-32 8 4 bytes Compressed size 12 4 bytes Uncompressed size If you call ZipFile.writestr passing a ZipInfo where flag_bits & 0x08 is true, it will try to write an extended local header, but it won't write the header signature. Even though (on Linux) unzip doesn't complain about it, a zip -T file.zip tells me: $ zip -T file.zip zip warning: extended local header not found for filename zip error: Zip file structure invalid (file.zip) Tested on a debian unstable system, with Python 2.3.5, 2.4.4 and 2.5.1. I'm attaching a simple test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742205&group_id=5470 From noreply at sourceforge.net Sat Jun 23 21:12:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 12:12:58 -0700 Subject: [ python-Bugs-1741898 ] Odd UDP problems in socket library Message-ID: Bugs item #1741898, was opened at 2007-06-22 17:30 Message generated for change (Settings changed) made by bluej774 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Jay Sherby (bluej774) Assigned to: Nobody/Anonymous (nobody) Summary: Odd UDP problems in socket library Initial Comment: I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info. I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang. for i in range(2): client.sendto(data, (sys.argv[1], 123)) data, address = client.recvfrom(1024) Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP. Thanks for looking into it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 10:10 Message: Logged In: YES user_id=341410 Originator: NO Could you produce a small runnable sample, describe what it should produce, and what it actually produces? That would make it much easier for us to help you. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 From noreply at sourceforge.net Mon Jun 25 10:38:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 01:38:32 -0700 Subject: [ python-Bugs-1741218 ] string formatter %x problem with indirectly given long Message-ID: Bugs item #1741218, was opened at 2007-06-21 20:33 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenji Noguchi (kenjinoguchi) Assigned to: Nobody/Anonymous (nobody) Summary: string formatter %x problem with indirectly given long Initial Comment: "%x" % v fails if the v is a instance, and its __int__ returns larger than 0x80000000 on 32bit OS. I've reported the problem at Python ML. http://mail.python.org/pipermail/python-list/2007-June/446103.html "%x" % int(v) "%x" % 0x80000000L above two work fine because string formatter processes a long value exceptionally. It looks inconsistent. So I made this patch. --- stringobject.c.org 2007-06-21 13:57:54.745877000 -0700 +++ stringobject.c 2007-06-21 13:59:19.576646000 -0700 @@ -4684,6 +4684,15 @@ case 'X': if (c == 'i') c = 'd'; + /* try to convert objects to number*/ + PyNumberMethods *nb; + if ((nb = v->ob_type->tp_as_number) && + nb->nb_int) { + v = (*nb->nb_int) (v); + if(v == NULL) + goto error; + } + if (PyLong_Check(v)) { int ilen; temp = _PyString_FormatLong(v, flags, ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-25 05:38 Message: Logged In: YES user_id=479790 Originator: NO Patch #1742669 tries to fix this problem and is a bit more generic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741218&group_id=5470 From noreply at sourceforge.net Mon Jun 25 15:24:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 06:24:09 -0700 Subject: [ python-Bugs-1742837 ] Documentation for BaseHTTPServer.HTTPServer Message-ID: Bugs item #1742837, was opened at 2007-06-25 09: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=1742837&group_id=5470 Please note that this 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 Private: No Submitted By: Brandon Mintern (bmintern) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for BaseHTTPServer.HTTPServer Initial Comment: I have frequently used the BaseHTTPServer.HTTPServer class to create servers to perform a variety of tasks. In the past, I have always simply created an instance of the class and invoked "serve_forever" (as shown in http://docs.python.org/lib/module-BaseHTTPServer.html). This time around, however, I needed to be able to run the server inside a while loop, so that I could eventually terminate the server. The docs.python.org site has no real documentation indicating how to do this, since the HTTPServer class is not really documented. I found the information I needed at http://pydoc.org/2.4.1/BaseHTTPServer.html#HTTPServer. This is a request to include more information on HTTPServer on the docs.python.org site, especially documentation for functions like handle_request(). I understand that HTTPServer inherits from SocketServer.TCPServer, which inherits from SocketServer.BaseServer, and that is where this method comes from. For this reason, it doesn't really make sense to duplicate that information. I would simply like to see another use case to supplement the first one, i.e. ## What is there already def run(server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): server_address = ('', 8000) httpd = server_class(server_address, handler_class) httpd.serve_forever() ## I would like to see something like the following added def run_while_true(keep_running, server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): """keep_running is a function of no arguments which is tested initially and after each request. If its return value evaluates to True, the server continues.""" server_address = ('', 8000) httpd = server_class(server_address, handler_class) while keep_running: httpd.handle_request() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742837&group_id=5470 From noreply at sourceforge.net Mon Jun 25 15:26:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 06:26:37 -0700 Subject: [ python-Bugs-1742837 ] Documentation for BaseHTTPServer.HTTPServer Message-ID: Bugs item #1742837, was opened at 2007-06-25 09:24 Message generated for change (Comment added) made by bmintern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742837&group_id=5470 Please note that this 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 Private: No Submitted By: Brandon Mintern (bmintern) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for BaseHTTPServer.HTTPServer Initial Comment: I have frequently used the BaseHTTPServer.HTTPServer class to create servers to perform a variety of tasks. In the past, I have always simply created an instance of the class and invoked "serve_forever" (as shown in http://docs.python.org/lib/module-BaseHTTPServer.html). This time around, however, I needed to be able to run the server inside a while loop, so that I could eventually terminate the server. The docs.python.org site has no real documentation indicating how to do this, since the HTTPServer class is not really documented. I found the information I needed at http://pydoc.org/2.4.1/BaseHTTPServer.html#HTTPServer. This is a request to include more information on HTTPServer on the docs.python.org site, especially documentation for functions like handle_request(). I understand that HTTPServer inherits from SocketServer.TCPServer, which inherits from SocketServer.BaseServer, and that is where this method comes from. For this reason, it doesn't really make sense to duplicate that information. I would simply like to see another use case to supplement the first one, i.e. ## What is there already def run(server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): server_address = ('', 8000) httpd = server_class(server_address, handler_class) httpd.serve_forever() ## I would like to see something like the following added def run_while_true(keep_running, server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): """keep_running is a function of no arguments which is tested initially and after each request. If its return value evaluates to True, the server continues.""" server_address = ('', 8000) httpd = server_class(server_address, handler_class) while keep_running: httpd.handle_request() ---------------------------------------------------------------------- >Comment By: Brandon Mintern (bmintern) Date: 2007-06-25 09:26 Message: Logged In: YES user_id=1827662 Originator: YES Wow... I'm a first time SourceForge user. How dumb is it that they don't wrap comments in pre tags, knowing that there will probably be a lot of code snippets posted? I hope you can tell what I meant above. Just pretend that it's all indented as it should be :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742837&group_id=5470 From noreply at sourceforge.net Mon Jun 25 15:28:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 06:28:22 -0700 Subject: [ python-Bugs-1742837 ] Documentation for BaseHTTPServer.HTTPServer Message-ID: Bugs item #1742837, was opened at 2007-06-25 09:24 Message generated for change (Comment added) made by bmintern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742837&group_id=5470 Please note that this 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 Private: No Submitted By: Brandon Mintern (bmintern) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for BaseHTTPServer.HTTPServer Initial Comment: I have frequently used the BaseHTTPServer.HTTPServer class to create servers to perform a variety of tasks. In the past, I have always simply created an instance of the class and invoked "serve_forever" (as shown in http://docs.python.org/lib/module-BaseHTTPServer.html). This time around, however, I needed to be able to run the server inside a while loop, so that I could eventually terminate the server. The docs.python.org site has no real documentation indicating how to do this, since the HTTPServer class is not really documented. I found the information I needed at http://pydoc.org/2.4.1/BaseHTTPServer.html#HTTPServer. This is a request to include more information on HTTPServer on the docs.python.org site, especially documentation for functions like handle_request(). I understand that HTTPServer inherits from SocketServer.TCPServer, which inherits from SocketServer.BaseServer, and that is where this method comes from. For this reason, it doesn't really make sense to duplicate that information. I would simply like to see another use case to supplement the first one, i.e. ## What is there already def run(server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): server_address = ('', 8000) httpd = server_class(server_address, handler_class) httpd.serve_forever() ## I would like to see something like the following added def run_while_true(keep_running, server_class=BaseHTTPServer.HTTPServer, handler_class=BaseHTTPServer.BaseHTTPRequestHandler): """keep_running is a function of no arguments which is tested initially and after each request. If its return value evaluates to True, the server continues.""" server_address = ('', 8000) httpd = server_class(server_address, handler_class) while keep_running: httpd.handle_request() ---------------------------------------------------------------------- >Comment By: Brandon Mintern (bmintern) Date: 2007-06-25 09:28 Message: Logged In: YES user_id=1827662 Originator: YES ...and of course, "while keep_running:" should actually be "while keep_running():". Geez, I hope this is my last comment (at least until someone else replies). ---------------------------------------------------------------------- Comment By: Brandon Mintern (bmintern) Date: 2007-06-25 09:26 Message: Logged In: YES user_id=1827662 Originator: YES Wow... I'm a first time SourceForge user. How dumb is it that they don't wrap comments in pre tags, knowing that there will probably be a lot of code snippets posted? I hope you can tell what I meant above. Just pretend that it's all indented as it should be :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742837&group_id=5470 From noreply at sourceforge.net Mon Jun 25 16:43:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 07:43:03 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 14: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=1742889&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:09:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:09:25 -0700 Subject: [ python-Bugs-1742901 ] shlex handles 'None' poorly Message-ID: Bugs item #1742901, was opened at 2007-06-25 15: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=1742901&group_id=5470 Please note that this 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 Private: No Submitted By: Seth Vidal (skvidal) Assigned to: Nobody/Anonymous (nobody) Summary: shlex handles 'None' poorly Initial Comment: If you pass shlex.split() None for any reason it will run forever waiting for input, w/o outputting anything. That seems like the wrong behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742901&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:22:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:22:39 -0700 Subject: [ python-Bugs-1742901 ] shlex handles 'None' poorly Message-ID: Bugs item #1742901, was opened at 2007-06-25 15:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742901&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Seth Vidal (skvidal) Assigned to: Nobody/Anonymous (nobody) Summary: shlex handles 'None' poorly Initial Comment: If you pass shlex.split() None for any reason it will run forever waiting for input, w/o outputting anything. That seems like the wrong behavior. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:22 Message: Logged In: YES user_id=849994 Originator: NO This won't fix, because that comes from split() creating a shlex() instance, which takes None as sys.stdin. But I've added a documentation note in rev. 56084, 56085 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742901&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:26:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:26:29 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 14:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:53:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:53:29 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 14:43 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2007-06-25 15:53 Message: Logged In: YES user_id=73023 Originator: YES I'm not aware of any such contract. Can you point to anything in writing? See for example: file:///home/jim/Documentation/Python-Docs-2.4.1/tut/node10.html#SECTION0010500000000000000000 which teaches people to create custom exceptions that: - don't set args ro message and - won't be unpicklable in Python 2.5. Also, as I mentioned, the reduce implementation doesn't preserve the message, so even if that was the contract, the contract is broken. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:57:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:57:21 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 14:43 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2007-06-25 15:57 Message: Logged In: YES user_id=73023 Originator: YES I'll note that I think the right thing to do is to: - Take args and message out of the C struct. - inherit the default reduce behavior from object. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 15:53 Message: Logged In: YES user_id=73023 Originator: YES I'm not aware of any such contract. Can you point to anything in writing? See for example: file:///home/jim/Documentation/Python-Docs-2.4.1/tut/node10.html#SECTION0010500000000000000000 which teaches people to create custom exceptions that: - don't set args ro message and - won't be unpicklable in Python 2.5. Also, as I mentioned, the reduce implementation doesn't preserve the message, so even if that was the contract, the contract is broken. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Mon Jun 25 17:57:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 08:57:56 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 14:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:57 Message: Logged In: YES user_id=849994 Originator: NO No, I haven't anything written -- and this should be fixed anyway. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 15:57 Message: Logged In: YES user_id=73023 Originator: YES I'll note that I think the right thing to do is to: - Take args and message out of the C struct. - inherit the default reduce behavior from object. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 15:53 Message: Logged In: YES user_id=73023 Originator: YES I'm not aware of any such contract. Can you point to anything in writing? See for example: file:///home/jim/Documentation/Python-Docs-2.4.1/tut/node10.html#SECTION0010500000000000000000 which teaches people to create custom exceptions that: - don't set args ro message and - won't be unpicklable in Python 2.5. Also, as I mentioned, the reduce implementation doesn't preserve the message, so even if that was the contract, the contract is broken. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 15:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Mon Jun 25 18:28:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 09:28:18 -0700 Subject: [ python-Bugs-1742940 ] can't run single lamba funcs as unittest Message-ID: Bugs item #1742940, was opened at 2007-06-25 10: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=1742940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: timmeh (tctimmeh) Assigned to: Nobody/Anonymous (nobody) Summary: can't run single lamba funcs as unittest Initial Comment: I have some code that adds new test funtions to a TestCase class as lambda functions: ExmplTests.myTest = lambda: 1+2 When I run the app and specify my lamba test to run, as in: myTestProg ExmplTests.mytest I get: Traceback (most recent call last): File "C:\work\CTTS\o-ticket\scOmniCTTS\test\otfbatch_test.py", line 188, in ? unittest.main(defaultTest = 'suite') File "C:\Python24\lib\unittest.py", line 761, in __init__ self.parseArgs(argv) File "C:\Python24\lib\unittest.py", line 788, in parseArgs self.createTests() File "C:\Python24\lib\unittest.py", line 794, in createTests self.module) File "C:\Python24\lib\unittest.py", line 559, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "C:\Python24\lib\unittest.py", line 543, in loadTestsFromName return parent(obj.__name__) File "C:\Python24\lib\unittest.py", line 211, in __init__ raise ValueError, "no such test method in %s: %s" % \ ValueError: no such test method in : It seems this is the case because lamba functions are always named ''. If I change unittest.py ln543 from: return parent(obj.__name__) to: return parent(part) it fixes my problem because part has the function name as a string, instead of getting it from obj, which returns '' in my case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742940&group_id=5470 From noreply at sourceforge.net Mon Jun 25 23:57:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 14:57:37 -0700 Subject: [ python-Bugs-1742940 ] can't run single lamba funcs as unittest Message-ID: Bugs item #1742940, was opened at 2007-06-25 10:28 Message generated for change (Comment added) made by tctimmeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: timmeh (tctimmeh) Assigned to: Nobody/Anonymous (nobody) Summary: can't run single lamba funcs as unittest Initial Comment: I have some code that adds new test funtions to a TestCase class as lambda functions: ExmplTests.myTest = lambda: 1+2 When I run the app and specify my lamba test to run, as in: myTestProg ExmplTests.mytest I get: Traceback (most recent call last): File "C:\work\CTTS\o-ticket\scOmniCTTS\test\otfbatch_test.py", line 188, in ? unittest.main(defaultTest = 'suite') File "C:\Python24\lib\unittest.py", line 761, in __init__ self.parseArgs(argv) File "C:\Python24\lib\unittest.py", line 788, in parseArgs self.createTests() File "C:\Python24\lib\unittest.py", line 794, in createTests self.module) File "C:\Python24\lib\unittest.py", line 559, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "C:\Python24\lib\unittest.py", line 543, in loadTestsFromName return parent(obj.__name__) File "C:\Python24\lib\unittest.py", line 211, in __init__ raise ValueError, "no such test method in %s: %s" % \ ValueError: no such test method in : It seems this is the case because lamba functions are always named ''. If I change unittest.py ln543 from: return parent(obj.__name__) to: return parent(part) it fixes my problem because part has the function name as a string, instead of getting it from obj, which returns '' in my case. ---------------------------------------------------------------------- >Comment By: timmeh (tctimmeh) Date: 2007-06-25 15:57 Message: Logged In: YES user_id=1827855 Originator: YES Here is code that causes the problem: import unittest class Exmpl(unittest.TestCase): pass Exmpl.testBug = lambda self: 1+2 if (__name__ == '__main__'): unittest.main() Running "program.py" with no args is an error free run. Running "program.py Exmpl.testBug" dies with the stack trace mentioned above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742940&group_id=5470 From noreply at sourceforge.net Tue Jun 26 03:18:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 18:18:33 -0700 Subject: [ python-Bugs-1740599 ] python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Message-ID: Bugs item #1740599, was opened at 2007-06-20 16:24 Message generated for change (Comment added) made by stuffduff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 Please note that this 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 Private: No Submitted By: Sean (stuffduff) Assigned to: Nobody/Anonymous (nobody) Summary: python: Modules/gcmodule.c:240: update_refs: Assertion `gc-> Initial Comment: Extension module loads and runs correctly. When exiting python the following error occurrs: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: python2.4 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208243504 (LWP 12884)] collect (generation=2) at Modules/gcmodule.c:241 241 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) bt #0 collect (generation=2) at Modules/gcmodule.c:241 #1 0x080e1ec5 in PyGC_Collect () at Modules/gcmodule.c:1196 #2 0x080da88a in Py_Finalize () at Python/pythonrun.c:353 #3 0x08055176 in Py_Main (argc=0, argv=0xbfb8dae4) at Modules/main.c: 513 #4 0x08054962 in main (argc=-1208273400, argv=0x812ed68) at Modules/python.c:23 Debug build of python2.4.4 gives: python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed. ---------------------------------------------------------------------- >Comment By: Sean (stuffduff) Date: 2007-06-25 20:18 Message: Logged In: YES user_id=1093262 Originator: YES Close this. I found the error. Sorry. ---------------------------------------------------------------------- Comment By: Sean (stuffduff) Date: 2007-06-21 15:55 Message: Logged In: YES user_id=1093262 Originator: YES Very stripped down, but complex instructions. See the README file. PUTENV replaces the need for an environment variable. File Added: pyGTMbug.tar.gz ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:41 Message: Logged In: YES user_id=33168 Originator: NO I forgot to mention about the putenv()s. Are those necessary? The directories won't exist on any one else's box. If those are not necessary to cause the assertion, remove those too from the minimal test case. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-21 00:40 Message: Logged In: YES user_id=33168 Originator: NO I looked at the attachment and it's not clear how you are using this given there is a main(). The main() doesn't have a Py_Initialize() either. So I'm guessing that was left over and you are really using this as a module. Can you reduce it to the minimal test case? Remove the main() and all the methods that are not used and will cause the crash. Also what is the python code that you execute. Basically can you demonstrate a complete scenario (how to build and execute) to cause the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740599&group_id=5470 From noreply at sourceforge.net Tue Jun 26 05:51:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 20:51:20 -0700 Subject: [ python-Bugs-1738441 ] shutil.move doesn't work when only case changes Message-ID: Bugs item #1738441, was opened at 2007-06-16 15:25 Message generated for change (Comment added) made by ggambett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Gabriel Gambetta (ggambett) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move doesn't work when only case changes Initial Comment: shutil.move() appears to fail silently when the source and destination filenames only differ in case (ie "SomeFile" and "Somefile"). This is with python 2.4.3-18.fc6, on a case-sensitive filesystem (ext3), so this rename *is* meaningful. ---------------------------------------------------------------------- >Comment By: Gabriel Gambetta (ggambett) Date: 2007-06-26 00:51 Message: Logged In: YES user_id=517400 Originator: YES Sorry, my bad. This happened in a FAT volume mounted somewhere in an ext3 tree so the rename wasn't meaningful within the volume. Still doing shutil.move(source, "__temp__") and shutil.move("__temp__", dest) did achieve the result I wanted. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 09:40 Message: Logged In: YES user_id=849994 Originator: NO This is quite strange. Gabriel, could you try to use another Python version provided by Fedora, or even a self-compiled one? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-17 02:08 Message: Logged In: YES user_id=942711 Originator: NO I guess, this should be very much python 2.4.3-18.fc6 specific. While I have python 2.3.4, python 2.5, python 2.6a0. I am unable to reproduce this defect. Having said that, help(shutil.move) mentions about the various issues of moving the implementation glosses over. Please provide some more details or anyone with python 2.4.3-18 should be able to verify it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 From noreply at sourceforge.net Tue Jun 26 17:18:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 08:18:53 -0700 Subject: [ python-Bugs-1743665 ] conditional expressions vs. () and * in call arguments. Message-ID: Bugs item #1743665, was opened at 2007-06-26 10:18 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=1743665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: conditional expressions vs. () and * in call arguments. Initial Comment: Consider: >>> def foo(x, y=23): ... print x, y ... >>> data = (1, 2) >>> foo(*data if data else data) 1 2 >>> data = None >>> foo(*data if data else data) Traceback (most recent call last): File "", line 1, in TypeError: foo() argument after * must be a sequence >>> Ok, * binds tighter than if else, so add the parens to fix this: >>> foo((*data) if data else data) File "", line 1 foo((*data) if data else data) ^ SyntaxError: invalid syntax >>> The parser thinks I'm trying to use the *tuple syntax inside a tuple in an argument list - at least, that's what I think it is flagging as invalid syntax. But that's not what I'm doing! Wrapping parens around an expression doesn't automatically turn it into a tuple, even in an argument list: >>> foo((1)) 1 23 >>> This looks like a parser bug to me. However, the interactions of the various things one can put in argument lists have gotten complex enough that it's hard to say for sure. If it's not a bug, it should probably be documented somewhere. For the record, the workaround is: >>> foo(*data if data else (data,)) None 23 >>> And yes, that last comma is required, otherwise you're back to the first error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743665&group_id=5470 From noreply at sourceforge.net Tue Jun 26 18:51:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 09:51:26 -0700 Subject: [ python-Bugs-1743665 ] conditional expressions vs. () and * in call arguments. Message-ID: Bugs item #1743665, was opened at 2007-06-26 15:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743665&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: conditional expressions vs. () and * in call arguments. Initial Comment: Consider: >>> def foo(x, y=23): ... print x, y ... >>> data = (1, 2) >>> foo(*data if data else data) 1 2 >>> data = None >>> foo(*data if data else data) Traceback (most recent call last): File "", line 1, in TypeError: foo() argument after * must be a sequence >>> Ok, * binds tighter than if else, so add the parens to fix this: >>> foo((*data) if data else data) File "", line 1 foo((*data) if data else data) ^ SyntaxError: invalid syntax >>> The parser thinks I'm trying to use the *tuple syntax inside a tuple in an argument list - at least, that's what I think it is flagging as invalid syntax. But that's not what I'm doing! Wrapping parens around an expression doesn't automatically turn it into a tuple, even in an argument list: >>> foo((1)) 1 23 >>> This looks like a parser bug to me. However, the interactions of the various things one can put in argument lists have gotten complex enough that it's hard to say for sure. If it's not a bug, it should probably be documented somewhere. For the record, the workaround is: >>> foo(*data if data else (data,)) None 23 >>> And yes, that last comma is required, otherwise you're back to the first error. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-26 16:51 Message: Logged In: YES user_id=849994 Originator: NO Sorry, I can't see a problem here. "data if data else data" is nonsensical and equivalent to "data". This of course doesn't work since None is not a sequence. Thus, your "workaround" is the correct solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743665&group_id=5470 From noreply at sourceforge.net Tue Jun 26 19:47:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 10:47:26 -0700 Subject: [ python-Bugs-1732145 ] python 2.6 latest fails test_socketserver.py Message-ID: Bugs item #1732145, was opened at 2007-06-06 10:41 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732145&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.6 latest fails test_socketserver.py Initial Comment: test_socket_ssl test_socketserver test test_socketserver crashed -- : (104, 'Connection reset by peer') test_softspace test_sort Exception in thread Thread-63: Traceback (most recent call last): File "/build/work/python-2.6/Lib/threading.py", line 465, in __bootstrap self.run() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 93, in run svr.serve_a_few() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 35, in serve_a_few self.handle_request() File "/build/work/python-2.6/Lib/SocketServer.py", line 224, in handle_request self.handle_error(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 429, in process_request self.collect_children() File "/build/work/python-2.6/Lib/SocketServer.py", line 425, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-06-26 12:47 Message: Logged In: YES user_id=1115903 Originator: NO Could you provide some details of the environment in which this failed (platform, command used to run the tests, etc.)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732145&group_id=5470 From noreply at sourceforge.net Tue Jun 26 20:45:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 11:45:20 -0700 Subject: [ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata Message-ID: Bugs item #1743795, was opened at 2007-06-26 18: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=1743795&group_id=5470 Please note that this 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 Private: No Submitted By: admindomeny (admindomeny) Assigned to: M.-A. Lemburg (lemburg) Summary: Some incorrect national characters (Polish) in unicodedata Initial Comment: Hello, This problem regards pythonwin (I haven't checked whether unix/commandline python is affected), Python 2.5.1. Examples on attached screenshot. E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character (latin small a with some caret above it it seems) as well as print unicodedata.name( / latin small letter a with circumflex, typed in Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE', which is obviously incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 From noreply at sourceforge.net Tue Jun 26 22:20:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 13:20:10 -0700 Subject: [ python-Bugs-1743846 ] Examples dropped from PDF version of docs Message-ID: Bugs item #1743846, was opened at 2007-06-26 20: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=1743846&group_id=5470 Please note that this 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 Private: No Submitted By: Terry Carroll (tcarroll) Assigned to: Nobody/Anonymous (nobody) Summary: Examples dropped from PDF version of docs Initial Comment: In section 13.13 of the PDF version Python Library Reference (on SQLite), a number of examples are dropped and instead have what looks like a statement that should have had the examples imported. The HTML pages look fine, however. For example, in section 13.13.3, in the PDF file it reads: """ This example shows how to use parameters with qmark style: 1.py This example shows how to use the named style: 2.py """ In the HTML, it reads, correctly: """ This example shows how to use parameters with qmark style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=? and age=?", (who, age)) print cur.fetchone() Download as text (original file name: sqlite3/execute_1.py). This example shows how to use the named style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=:who and age=:age", {"who": who, "age": age}) print cur.fetchone() Download as text (original file name: sqlite3/execute_2.py). """ I've only looked at Chapter 13.13 (because I'm starting to use SQLite) and have found this in the following sections: 13.13.1 (under complete_statement) 13.13.2 (under row_factory and text_factory) 13.13.3 (4 instances) 13.13.4 (5 instances) 13.13.6 (1 instance) I'm attaching PDFs of the start of section 13.13.3 for comparison purposes: one copy from the PDF from http://docs.python.org/ftp/python/doc/2.5/pdf-letter-2.5.zip and one copy from the HTML at http://docs.python.org/lib/sqlite3-Cursor-Objects.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 From noreply at sourceforge.net Tue Jun 26 22:21:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 13:21:30 -0700 Subject: [ python-Bugs-1743846 ] Examples dropped from PDF version of docs Message-ID: Bugs item #1743846, was opened at 2007-06-26 20:20 Message generated for change (Comment added) made by tcarroll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 Please note that this 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 Private: No Submitted By: Terry Carroll (tcarroll) Assigned to: Nobody/Anonymous (nobody) Summary: Examples dropped from PDF version of docs Initial Comment: In section 13.13 of the PDF version Python Library Reference (on SQLite), a number of examples are dropped and instead have what looks like a statement that should have had the examples imported. The HTML pages look fine, however. For example, in section 13.13.3, in the PDF file it reads: """ This example shows how to use parameters with qmark style: 1.py This example shows how to use the named style: 2.py """ In the HTML, it reads, correctly: """ This example shows how to use parameters with qmark style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=? and age=?", (who, age)) print cur.fetchone() Download as text (original file name: sqlite3/execute_1.py). This example shows how to use the named style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=:who and age=:age", {"who": who, "age": age}) print cur.fetchone() Download as text (original file name: sqlite3/execute_2.py). """ I've only looked at Chapter 13.13 (because I'm starting to use SQLite) and have found this in the following sections: 13.13.1 (under complete_statement) 13.13.2 (under row_factory and text_factory) 13.13.3 (4 instances) 13.13.4 (5 instances) 13.13.6 (1 instance) I'm attaching PDFs of the start of section 13.13.3 for comparison purposes: one copy from the PDF from http://docs.python.org/ftp/python/doc/2.5/pdf-letter-2.5.zip and one copy from the HTML at http://docs.python.org/lib/sqlite3-Cursor-Objects.html ---------------------------------------------------------------------- >Comment By: Terry Carroll (tcarroll) Date: 2007-06-26 20:21 Message: Logged In: YES user_id=755895 Originator: YES Adding copy from HTML version,illustrating how it should look. File Added: Lib-13-13-3-HTML.pdf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 From noreply at sourceforge.net Tue Jun 26 22:31:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 13:31:33 -0700 Subject: [ python-Bugs-1743846 ] Examples dropped from PDF version of docs Message-ID: Bugs item #1743846, was opened at 2007-06-26 20:20 Message generated for change (Comment added) made by tcarroll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 Please note that this 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 Private: No Submitted By: Terry Carroll (tcarroll) Assigned to: Nobody/Anonymous (nobody) Summary: Examples dropped from PDF version of docs Initial Comment: In section 13.13 of the PDF version Python Library Reference (on SQLite), a number of examples are dropped and instead have what looks like a statement that should have had the examples imported. The HTML pages look fine, however. For example, in section 13.13.3, in the PDF file it reads: """ This example shows how to use parameters with qmark style: 1.py This example shows how to use the named style: 2.py """ In the HTML, it reads, correctly: """ This example shows how to use parameters with qmark style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=? and age=?", (who, age)) print cur.fetchone() Download as text (original file name: sqlite3/execute_1.py). This example shows how to use the named style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=:who and age=:age", {"who": who, "age": age}) print cur.fetchone() Download as text (original file name: sqlite3/execute_2.py). """ I've only looked at Chapter 13.13 (because I'm starting to use SQLite) and have found this in the following sections: 13.13.1 (under complete_statement) 13.13.2 (under row_factory and text_factory) 13.13.3 (4 instances) 13.13.4 (5 instances) 13.13.6 (1 instance) I'm attaching PDFs of the start of section 13.13.3 for comparison purposes: one copy from the PDF from http://docs.python.org/ftp/python/doc/2.5/pdf-letter-2.5.zip and one copy from the HTML at http://docs.python.org/lib/sqlite3-Cursor-Objects.html ---------------------------------------------------------------------- >Comment By: Terry Carroll (tcarroll) Date: 2007-06-26 20:31 Message: Logged In: YES user_id=755895 Originator: YES Just a little bit more info: this also is present in the A4-version of the PDF (i.e., both PDF version), as well as both the US-Letter and A4 versions of the Postscript. The HTML ZIP file appears okay. I don't have LaTeX installed and have no way of checking that one. ---------------------------------------------------------------------- Comment By: Terry Carroll (tcarroll) Date: 2007-06-26 20:21 Message: Logged In: YES user_id=755895 Originator: YES Adding copy from HTML version,illustrating how it should look. File Added: Lib-13-13-3-HTML.pdf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 From noreply at sourceforge.net Tue Jun 26 22:45:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 13:45:32 -0700 Subject: [ python-Bugs-1743846 ] Examples dropped from PDF version of SQLite docs Message-ID: Bugs item #1743846, was opened at 2007-06-26 20:20 Message generated for change (Settings changed) made by tcarroll You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 Please note that this 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 Private: No Submitted By: Terry Carroll (tcarroll) Assigned to: Nobody/Anonymous (nobody) >Summary: Examples dropped from PDF version of SQLite docs Initial Comment: In section 13.13 of the PDF version Python Library Reference (on SQLite), a number of examples are dropped and instead have what looks like a statement that should have had the examples imported. The HTML pages look fine, however. For example, in section 13.13.3, in the PDF file it reads: """ This example shows how to use parameters with qmark style: 1.py This example shows how to use the named style: 2.py """ In the HTML, it reads, correctly: """ This example shows how to use parameters with qmark style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=? and age=?", (who, age)) print cur.fetchone() Download as text (original file name: sqlite3/execute_1.py). This example shows how to use the named style: import sqlite3 con = sqlite3.connect("mydb") cur = con.cursor() who = "Yeltsin" age = 72 cur.execute("select name_last, age from people where name_last=:who and age=:age", {"who": who, "age": age}) print cur.fetchone() Download as text (original file name: sqlite3/execute_2.py). """ I've only looked at Chapter 13.13 (because I'm starting to use SQLite) and have found this in the following sections: 13.13.1 (under complete_statement) 13.13.2 (under row_factory and text_factory) 13.13.3 (4 instances) 13.13.4 (5 instances) 13.13.6 (1 instance) I'm attaching PDFs of the start of section 13.13.3 for comparison purposes: one copy from the PDF from http://docs.python.org/ftp/python/doc/2.5/pdf-letter-2.5.zip and one copy from the HTML at http://docs.python.org/lib/sqlite3-Cursor-Objects.html ---------------------------------------------------------------------- Comment By: Terry Carroll (tcarroll) Date: 2007-06-26 20:31 Message: Logged In: YES user_id=755895 Originator: YES Just a little bit more info: this also is present in the A4-version of the PDF (i.e., both PDF version), as well as both the US-Letter and A4 versions of the Postscript. The HTML ZIP file appears okay. I don't have LaTeX installed and have no way of checking that one. ---------------------------------------------------------------------- Comment By: Terry Carroll (tcarroll) Date: 2007-06-26 20:21 Message: Logged In: YES user_id=755895 Originator: YES Adding copy from HTML version,illustrating how it should look. File Added: Lib-13-13-3-HTML.pdf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743846&group_id=5470 From noreply at sourceforge.net Tue Jun 26 23:53:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 14:53:33 -0700 Subject: [ python-Bugs-1732145 ] python 2.6 latest fails test_socketserver.py Message-ID: Bugs item #1732145, was opened at 2007-06-06 10:41 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732145&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.6 latest fails test_socketserver.py Initial Comment: test_socket_ssl test_socketserver test test_socketserver crashed -- : (104, 'Connection reset by peer') test_softspace test_sort Exception in thread Thread-63: Traceback (most recent call last): File "/build/work/python-2.6/Lib/threading.py", line 465, in __bootstrap self.run() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 93, in run svr.serve_a_few() File "/build/work/python-2.6/Lib/test/test_socketserver.py", line 35, in serve_a_few self.handle_request() File "/build/work/python-2.6/Lib/SocketServer.py", line 224, in handle_request self.handle_error(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/build/work/python-2.6/Lib/SocketServer.py", line 429, in process_request self.collect_children() File "/build/work/python-2.6/Lib/SocketServer.py", line 425, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list ---------------------------------------------------------------------- >Comment By: David Favor (dfavor) Date: 2007-06-26 16:53 Message: Logged In: YES user_id=370230 Originator: YES This was run on latest Fedora FC6 with all latest patches. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-06-26 12:47 Message: Logged In: YES user_id=1115903 Originator: NO Could you provide some details of the environment in which this failed (platform, command used to run the tests, etc.)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732145&group_id=5470 From noreply at sourceforge.net Wed Jun 27 10:28:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 01:28:51 -0700 Subject: [ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata Message-ID: Bugs item #1743795, was opened at 2007-06-26 20:45 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 Please note that this 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 Private: No Submitted By: admindomeny (admindomeny) Assigned to: M.-A. Lemburg (lemburg) Summary: Some incorrect national characters (Polish) in unicodedata Initial Comment: Hello, This problem regards pythonwin (I haven't checked whether unix/commandline python is affected), Python 2.5.1. Examples on attached screenshot. E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character (latin small a with some caret above it it seems) as well as print unicodedata.name( / latin small letter a with circumflex, typed in Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE', which is obviously incorrect. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 10:28 Message: Logged In: YES user_id=38388 Originator: NO This sounds more like a problem with entry of Unicode characters in pythonwin than the unicodedata module. Please create a test.py file with the character using e.g. UTF-8 as source code encoding and run that through the Python interpreter directly to see if the problem persists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 From noreply at sourceforge.net Wed Jun 27 12:00:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 03:00:22 -0700 Subject: [ python-Bugs-1636950 ] Newline skipped in "for line in file" Message-ID: Bugs item #1636950, was opened at 2007-01-16 17:56 Message generated for change (Comment added) made by runedevik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 Please note that this 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 Private: No Submitted By: Andy Monthei (amonthei) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: When processing huge fixed block files of about 7000 bytes wide and several hundred thousand lines long some pairs of lines get read as one long line with no line break when using "for line in file:". The problem is even worse when using the fileinput module and reading in five or six huge files consisting of 4.8 million records causes several hundred pairs of lines to be read as single lines. When a newline is skipped it is usually followed by several more in the next few hundred lines. I have not noticed any other characters being skipped, only the line break. O.S. Windows (5, 1, 2600, 2, 'Service Pack 2') Python 2.5 ---------------------------------------------------------------------- Comment By: Rune Devik (runedevik) Date: 2007-06-27 12:00 Message: Logged In: YES user_id=1212666 Originator: NO Hi I have the same problem with a huge file (8GB) containing long lines. Sometimes two lines are merged into one and rerunning the test script that reads the file it's always the same lines that are merged. Also the merging happens more frequently towards the end of the file it seems. I tried to reproduce with a smaller data set (10 lines before the two lines that get merged, the two lines that gets merged and the 10 lines after that) but I was not able to reproduce on this smaller data set. However if you open this huge file in "rb" mode instead of "r" mode everything works as it should and no lines are merged at all! If I copy the file over to linux and rerun the test script no lines are merged (regardless if mode is "r" or "rb") so this is windows specific and might have something todo with the adding of \r\n if only \n is found when you open the file in "r" mode maybe? Also I have reproduced it on both python 2.3.5 and 2.5c1 on both windows XP and windows 2003. More stats on the input file in both "r" mode and "rb" mode below: Input file size: 8 695 828 KB fp = open(file, "r"): - total number of lines read: 668909 - length of the longest line: 13179792 - length of the shortest line: 89 - 56 lines contains the content of two lines - Always just two lines that are merged into one! - Always the same lines that are merged rerunning the test on the same file. open(file, "rb"): - total number of lines read: 668965 - length of the longest line: 13179793 - length of the shortest line: 90 - no lines merged Regards, Rune Devik ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-01-21 01:46 Message: Logged In: YES user_id=357491 Originator: NO Well, with Andy saying he can't reproduce the problem I am going to close as invalid. Andy, if you ever happen to be able to upload data that triggers it, then please re-open this bug. ---------------------------------------------------------------------- Comment By: Andy Monthei (amonthei) Date: 2007-01-20 23:53 Message: Logged In: YES user_id=1693612 Originator: YES I have had no luck creating random data to reproduce the problem which leaves me to come to the conclusion that it was the data itself. Using a hex editor I find no problem with the line breaks. The data that triggers this bug is transferred several time before it gets to me. It originates on a Unix box, then goes to an IBM mainframe, then to my Windows machine and through many updates along the way. It may be an EBCDIC/ASCII conversion or possibly something to do with the mainframe to PC transfer. Whatever it is, it's in the data itself. The only thing that bothers me is that Java somehow is not affected by this bad data. ---------------------------------------------------------------------- Comment By: Andy Monthei (amonthei) Date: 2007-01-18 16:34 Message: Logged In: YES user_id=1693612 Originator: YES I am using open() for reading the file, no other features. I have also had fileinput.input(fileList) compound the problem. Each file that this has happened to is a fixed block file of either 6990 or 7700 bytes wide but this I think is insignificant. When looking at the file in a hex editor everything looks fine and a small Java program using a buffered reader will give me the correct line count when Python does not. Using something like fp.read(8192) I'm sure might temporarily solve my problem but I will keep working on getting a file I can upload. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-01-18 10:23 Message: Logged In: YES user_id=89016 Originator: NO Are you using any of the unicode reading features (i.e. codecs.EncodedFile etc.) or are you using plain open() for reading the file? ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-18 08:12 Message: Logged In: YES user_id=1591633 Originator: NO I don't know if this helps: I spent the last little while creating / reading random files that all (seemingly) matched the description you gave us. None of these files failed to read properly. (e.g., have the right amount of rows with a line length that seemingly was the right line. Definitely no doubling lines). Perusing the file source code found a detailed discussion of fgets vs fgetc for finding the next line in the file. Have you tried reading the file with fp.read(8192) or similar? Hopefully you're able to reproduce the bug with scrubbed data (because I couldn't construct random data to do so). Good luck. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-18 06:24 Message: Logged In: YES user_id=1591633 Originator: NO How wide are the min and max widths of the lines? This problem is of particular interest to me. ---------------------------------------------------------------------- Comment By: Andy Monthei (amonthei) Date: 2007-01-17 22:58 Message: Logged In: YES user_id=1693612 Originator: YES I can not upload the files that trigger this because of the data that is in them but I am working on getting around that. In my data line 617391 in a fixed block file of 6990 bytes wide gets read in with the next line after it. The line break is 0d0a (same as the others) where the bug happens so I am wondering if it is a buffer issue where the linebreak falls at the edge, however no other characters are ever missed. The total file is 888420 lines and this happens in four spots. I will hopefully have a file to send soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-01-16 23:33 Message: Logged In: YES user_id=357491 Originator: NO Do you happen to have a sample you could upload that triggers the bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 From noreply at sourceforge.net Wed Jun 27 13:29:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 04:29:43 -0700 Subject: [ python-Bugs-1668295 ] Strange unicode behaviour Message-ID: Bugs item #1668295, was opened at 2007-02-25 06:10 Message generated for change (Comment added) made by massysett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 Please note that this 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 Private: No Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Strange unicode behaviour Initial Comment: I know that python is very funny WRT unicode processing, but this defies all my knowledge. I use the es_ES.UTF-8 encoding on linux. The script: python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line. However, if I redirect it to less or to a file, like python -c "print unicode('? %s' % '??','utf8') " >test Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases? ---------------------------------------------------------------------- Comment By: Omari Norman (massysett) Date: 2007-06-27 07:29 Message: Logged In: YES user_id=1764292 Originator: NO The fix given by gbrandl, which is to use sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') does not work. EncodedFile expects to receive encoded strings, so if you try to use it with Unicode strings, you get errors. I could of course I tried sys.stdout = codecs.open(sys.stdout, 'w', 'utf-8') but that gives me "Type Error: coercing to Unicode: need string or buffer, file found." Since this was (absurdly) closed as invalid, are there any good fixes that actually work? ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-03 08:22 Message: Logged In: YES user_id=178886 Originator: YES >This is not magic. "print" looks for an "encoding" attribute on the file >it is printing to. This is the terminal encoding for sys.stdout and None >for other files. I'll correct you: "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout *if sys.stdout is a terminal* and None when sys.stdout is not a terminal. After all, the bug reported is that *the same program* behaved different when used standalone than when piped to less: $ python -c "import sys; print sys.stdout.encoding" UTF-8 $ python -c "import sys; print sys.stdout.encoding" | cat None If you say that this is intended, not a bug, that an external process is altering the behavior of a python program, I'd just leave it written to warn other naive people like myself, that thinks that an external program should not influence python behavior (with *the same environment*): $ locale LANG=es_ES.UTF-8 LC_CTYPE="es_ES.UTF-8" LC_NUMERIC="es_ES.UTF-8" LC_TIME="es_ES.UTF-8" LC_COLLATE="es_ES.UTF-8" LC_MONETARY="es_ES.UTF-8" LC_MESSAGES="es_ES.UTF-8" LC_PAPER="es_ES.UTF-8" LC_NAME="es_ES.UTF-8" LC_ADDRESS="es_ES.UTF-8" LC_TELEPHONE="es_ES.UTF-8" LC_MEASUREMENT="es_ES.UTF-8" LC_IDENTIFICATION="es_ES.UTF-8" LC_ALL=es_ES.UTF-8 But I take it as a design flaw, and against all pythonic principles, probably coming from the fact that a lot of python developers/users are windows people that don't care about stdout at all. IMO, the behavior should be either: - use always None for sys.stdout - use always LC_CTYPE or LANG for sys.stdout I prefer the second one, as when I pipe stdout, after all, I expect it to be honoring my locale settings. Don't forget that the same person that types "|" after a call to python can type LC_ALL=blah before, while s/he can't sometimes modify the script because it is out of their permission set. The implementation logic would be simpler too, I guess. And more consistent with jython (it uses the second "always LC_CTYPE" solution). Not sure about iron-python or pypy. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 18:27 Message: Logged In: YES user_id=849994 Originator: NO > >>> sys.getfilesystemencoding() > 'UTF-8' > > so python is really dumb if print does not know my filesystemencoding, but > knows my terminal encoding. the file system encoding is the encoding of file names, not of file content. > I though breaking the least surprising behaviour was not considered > pythonic, and now you tell me that having a program running on console but > issuing an exception when redirected is intended. I would prefer an > exception in both cases. Or, even better, using > sys.getfilesystemencoding(), or allowing me to set defaultencoding() I agree that using the terminal encoding is perhaps a bit too DWIMish, but you can always get consistent results if you *do not write Unicode strings anywhere*. > Do you mean that I need to say print unicode(whatever).encode('utf8'), > like: > > >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and > understand, even in files encoded as utf8. Assume this is a literal or > input No. You can directly put Unicode literals in your files, with u'...'. For that to work, you need to tell Python the encoding your file has, using the coding cookie (see the docs). > ... > >>> print unicode(a).encode('utf8') # because a could be a number, or a > different object > > every time, instead of "a='?'; print a" > Cool, I'm starting to really love it. Concise and pythonic > Are you seriously meaning that there is no way to tell print to use a > default encoding, and it will magically try to find it and fail for > everything not being a terminal? This is not magic. "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout and None for other files. > Are you seriously telling me that this is not a bug? Even worse, that it > is "intended behaviour". BTW, jython acts differently about this, in all > the versions I tried. It *is* not a bug. This was implemented as a simplification for terminal output. > And with -S I am allowed to change the encoding, which is crippled in site > for no known good reason. > python -S -c "import sys; sys.setdefaultencoding('utf8'); print > unicode('\xc3\xa1','utf8')" >test > (works, test contains an accented a as intended Because setdefaultencoding() affects *every* conversion from unicode to string and from string to unicode, which can be very confusing if you have to handle different encodings. >>use Unicode everywhere inside the >>program, and byte strings for input and output. > Have you ever wondered that to use unicode everywhere inside the program, > one needs to decode literals (or input) to unicode (the next sentence you > complain about)? Yes, you have to decode input (for files, you can do this automatically if you use codecs.open(), not builtin open()). No, you don't have to decode literals as Unicode literals exist. > I follow this principle in my programming since about 6 years ago, so I'm > not a novice. I'm playing by the rules: > a) "decodes it to unicode" is the first step to get it into processing. > This is just a test case, so processing is zero. > b) I refuse to believe that the only way to ensure something to be printed > right is wrapping every item into unicode(var).encode('utf8') [The > redundant unicode call is because the var could be a number, or a different > object] No, that is of course not the only way. An alternative is to use an encoded file, as the codecs module offers. If you e.g. set sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') you can print Unicode strings to stdout, and they will automatically be converted using utf-8. This is clear and explicit. > c) or making my code non portable by patching site.py to get a real > encoding instead of ascii. If you still cannot live without setdefaultencoding(), you can do reload(sys) to get a sys module with this method. Closing again. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 17:27 Message: Logged In: YES user_id=178886 Originator: YES re: consistent, my experience it is that python unicode handling is consistently stupid, doing almost always the wrong thing. It remembers me of the defaults of WordPerfect, that were always exactly the opposite of what the user wanted 99% of time. I hope python 3000 comes fast and stops that real pain. I love the language, but the way it handles unicode provokes hundreds of bugs. >Python could correctly find out your terminal >encoding, the Unicode string is automatically encoded in that encoding. > >If you output to a file, Python does not know which encoding you want to >have, so all Unicode strings are converted to ascii only. >>> sys.getfilesystemencoding() 'UTF-8' so python is really dumb if print does not know my filesystemencoding, but knows my terminal encoding. I though breaking the least surprising behaviour was not considered pythonic, and now you tell me that having a program running on console but issuing an exception when redirected is intended. I would prefer an exception in both cases. Or, even better, using sys.getfilesystemencoding(), or allowing me to set defaultencoding() >Please direct further questions to the Python mailing list or newsgroup. I would if I didn't consider this behaviour a bug, and a serious one. >The basic rule when handling Unicode is: use Unicode everywhere inside the >program, and byte strings for input and output. >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. > >You should do it the other way: use Unicode literals in your code, and >when y(ou write something to a file, *encode* them in utf-8. Do you mean that I need to say print unicode(whatever).encode('utf8'), like: >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and understand, even in files encoded as utf8. Assume this is a literal or input ... >>> print unicode(a).encode('utf8') # because a could be a number, or a different object every time, instead of "a='?'; print a" Cool, I'm starting to really love it. Concise and pythonic Are you seriously meaning that there is no way to tell print to use a default encoding, and it will magically try to find it and fail for everything not being a terminal? Are you seriously telling me that this is not a bug? Even worse, that it is "intended behaviour". BTW, jython acts differently about this, in all the versions I tried. And with -S I am allowed to change the encoding, which is crippled in site for no known good reason. python -S -c "import sys; sys.setdefaultencoding('utf8'); print unicode('\xc3\xa1','utf8')" >test (works, test contains an accented a as intended >use Unicode everywhere inside the >program, and byte strings for input and output. Have you ever wondered that to use unicode everywhere inside the program, one needs to decode literals (or input) to unicode (the next sentence you complain about)? >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. I follow this principle in my programming since about 6 years ago, so I'm not a novice. I'm playing by the rules: a) "decodes it to unicode" is the first step to get it into processing. This is just a test case, so processing is zero. b) I refuse to believe that the only way to ensure something to be printed right is wrapping every item into unicode(var).encode('utf8') [The redundant unicode call is because the var could be a number, or a different object] c) or making my code non portable by patching site.py to get a real encoding instead of ascii. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 14:43 Message: Logged In: YES user_id=849994 Originator: NO First of all: Python's Unicode handling is very consistent and straightforward, if you know the basics. Sadly, most people don't know the difference between Unicode and encoded strings. What you're seeing is not a bug, it is due to the fact that if you print Unicode to the console, and Python could correctly find out your terminal encoding, the Unicode string is automatically encoded in that encoding. If you output to a file, Python does not know which encoding you want to have, so all Unicode strings are converted to ascii only. Please direct further questions to the Python mailing list or newsgroup. The basic rule when handling Unicode is: use Unicode everywhere inside the program, and byte strings for input and output. So, your code is exactly the other way round: it takes a byte string, decodes it to unicode and *then* prints it. You should do it the other way: use Unicode literals in your code, and when you write something to a file, *encode* them in utf-8. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 06:17 Message: Logged In: YES user_id=178886 Originator: YES Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn trunk Also, some people asks for repr of strings (I guess to reproduce if they can't read the caracters). Those are printed in utf-8: $python -c "print repr('? %s')" '\xc3\xa1 %s' $ python -c "print repr('?i')" '\xc3\xa9i' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 From noreply at sourceforge.net Wed Jun 27 14:04:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 05:04:22 -0700 Subject: [ python-Bugs-1668295 ] Strange unicode behaviour Message-ID: Bugs item #1668295, was opened at 2007-02-25 11:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 Please note that this 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 Private: No Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Strange unicode behaviour Initial Comment: I know that python is very funny WRT unicode processing, but this defies all my knowledge. I use the es_ES.UTF-8 encoding on linux. The script: python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line. However, if I redirect it to less or to a file, like python -c "print unicode('? %s' % '??','utf8') " >test Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-27 12:04 Message: Logged In: YES user_id=849994 Originator: NO Yes, I'm sorry my fix is bad, you should rather use sys.stdout = codecs.getwriter('utf-8')(sys.stdout) ---------------------------------------------------------------------- Comment By: Omari Norman (massysett) Date: 2007-06-27 11:29 Message: Logged In: YES user_id=1764292 Originator: NO The fix given by gbrandl, which is to use sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') does not work. EncodedFile expects to receive encoded strings, so if you try to use it with Unicode strings, you get errors. I could of course I tried sys.stdout = codecs.open(sys.stdout, 'w', 'utf-8') but that gives me "Type Error: coercing to Unicode: need string or buffer, file found." Since this was (absurdly) closed as invalid, are there any good fixes that actually work? ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-03 13:22 Message: Logged In: YES user_id=178886 Originator: YES >This is not magic. "print" looks for an "encoding" attribute on the file >it is printing to. This is the terminal encoding for sys.stdout and None >for other files. I'll correct you: "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout *if sys.stdout is a terminal* and None when sys.stdout is not a terminal. After all, the bug reported is that *the same program* behaved different when used standalone than when piped to less: $ python -c "import sys; print sys.stdout.encoding" UTF-8 $ python -c "import sys; print sys.stdout.encoding" | cat None If you say that this is intended, not a bug, that an external process is altering the behavior of a python program, I'd just leave it written to warn other naive people like myself, that thinks that an external program should not influence python behavior (with *the same environment*): $ locale LANG=es_ES.UTF-8 LC_CTYPE="es_ES.UTF-8" LC_NUMERIC="es_ES.UTF-8" LC_TIME="es_ES.UTF-8" LC_COLLATE="es_ES.UTF-8" LC_MONETARY="es_ES.UTF-8" LC_MESSAGES="es_ES.UTF-8" LC_PAPER="es_ES.UTF-8" LC_NAME="es_ES.UTF-8" LC_ADDRESS="es_ES.UTF-8" LC_TELEPHONE="es_ES.UTF-8" LC_MEASUREMENT="es_ES.UTF-8" LC_IDENTIFICATION="es_ES.UTF-8" LC_ALL=es_ES.UTF-8 But I take it as a design flaw, and against all pythonic principles, probably coming from the fact that a lot of python developers/users are windows people that don't care about stdout at all. IMO, the behavior should be either: - use always None for sys.stdout - use always LC_CTYPE or LANG for sys.stdout I prefer the second one, as when I pipe stdout, after all, I expect it to be honoring my locale settings. Don't forget that the same person that types "|" after a call to python can type LC_ALL=blah before, while s/he can't sometimes modify the script because it is out of their permission set. The implementation logic would be simpler too, I guess. And more consistent with jython (it uses the second "always LC_CTYPE" solution). Not sure about iron-python or pypy. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 23:27 Message: Logged In: YES user_id=849994 Originator: NO > >>> sys.getfilesystemencoding() > 'UTF-8' > > so python is really dumb if print does not know my filesystemencoding, but > knows my terminal encoding. the file system encoding is the encoding of file names, not of file content. > I though breaking the least surprising behaviour was not considered > pythonic, and now you tell me that having a program running on console but > issuing an exception when redirected is intended. I would prefer an > exception in both cases. Or, even better, using > sys.getfilesystemencoding(), or allowing me to set defaultencoding() I agree that using the terminal encoding is perhaps a bit too DWIMish, but you can always get consistent results if you *do not write Unicode strings anywhere*. > Do you mean that I need to say print unicode(whatever).encode('utf8'), > like: > > >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and > understand, even in files encoded as utf8. Assume this is a literal or > input No. You can directly put Unicode literals in your files, with u'...'. For that to work, you need to tell Python the encoding your file has, using the coding cookie (see the docs). > ... > >>> print unicode(a).encode('utf8') # because a could be a number, or a > different object > > every time, instead of "a='?'; print a" > Cool, I'm starting to really love it. Concise and pythonic > Are you seriously meaning that there is no way to tell print to use a > default encoding, and it will magically try to find it and fail for > everything not being a terminal? This is not magic. "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout and None for other files. > Are you seriously telling me that this is not a bug? Even worse, that it > is "intended behaviour". BTW, jython acts differently about this, in all > the versions I tried. It *is* not a bug. This was implemented as a simplification for terminal output. > And with -S I am allowed to change the encoding, which is crippled in site > for no known good reason. > python -S -c "import sys; sys.setdefaultencoding('utf8'); print > unicode('\xc3\xa1','utf8')" >test > (works, test contains an accented a as intended Because setdefaultencoding() affects *every* conversion from unicode to string and from string to unicode, which can be very confusing if you have to handle different encodings. >>use Unicode everywhere inside the >>program, and byte strings for input and output. > Have you ever wondered that to use unicode everywhere inside the program, > one needs to decode literals (or input) to unicode (the next sentence you > complain about)? Yes, you have to decode input (for files, you can do this automatically if you use codecs.open(), not builtin open()). No, you don't have to decode literals as Unicode literals exist. > I follow this principle in my programming since about 6 years ago, so I'm > not a novice. I'm playing by the rules: > a) "decodes it to unicode" is the first step to get it into processing. > This is just a test case, so processing is zero. > b) I refuse to believe that the only way to ensure something to be printed > right is wrapping every item into unicode(var).encode('utf8') [The > redundant unicode call is because the var could be a number, or a different > object] No, that is of course not the only way. An alternative is to use an encoded file, as the codecs module offers. If you e.g. set sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') you can print Unicode strings to stdout, and they will automatically be converted using utf-8. This is clear and explicit. > c) or making my code non portable by patching site.py to get a real > encoding instead of ascii. If you still cannot live without setdefaultencoding(), you can do reload(sys) to get a sys module with this method. Closing again. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 22:27 Message: Logged In: YES user_id=178886 Originator: YES re: consistent, my experience it is that python unicode handling is consistently stupid, doing almost always the wrong thing. It remembers me of the defaults of WordPerfect, that were always exactly the opposite of what the user wanted 99% of time. I hope python 3000 comes fast and stops that real pain. I love the language, but the way it handles unicode provokes hundreds of bugs. >Python could correctly find out your terminal >encoding, the Unicode string is automatically encoded in that encoding. > >If you output to a file, Python does not know which encoding you want to >have, so all Unicode strings are converted to ascii only. >>> sys.getfilesystemencoding() 'UTF-8' so python is really dumb if print does not know my filesystemencoding, but knows my terminal encoding. I though breaking the least surprising behaviour was not considered pythonic, and now you tell me that having a program running on console but issuing an exception when redirected is intended. I would prefer an exception in both cases. Or, even better, using sys.getfilesystemencoding(), or allowing me to set defaultencoding() >Please direct further questions to the Python mailing list or newsgroup. I would if I didn't consider this behaviour a bug, and a serious one. >The basic rule when handling Unicode is: use Unicode everywhere inside the >program, and byte strings for input and output. >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. > >You should do it the other way: use Unicode literals in your code, and >when y(ou write something to a file, *encode* them in utf-8. Do you mean that I need to say print unicode(whatever).encode('utf8'), like: >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and understand, even in files encoded as utf8. Assume this is a literal or input ... >>> print unicode(a).encode('utf8') # because a could be a number, or a different object every time, instead of "a='?'; print a" Cool, I'm starting to really love it. Concise and pythonic Are you seriously meaning that there is no way to tell print to use a default encoding, and it will magically try to find it and fail for everything not being a terminal? Are you seriously telling me that this is not a bug? Even worse, that it is "intended behaviour". BTW, jython acts differently about this, in all the versions I tried. And with -S I am allowed to change the encoding, which is crippled in site for no known good reason. python -S -c "import sys; sys.setdefaultencoding('utf8'); print unicode('\xc3\xa1','utf8')" >test (works, test contains an accented a as intended >use Unicode everywhere inside the >program, and byte strings for input and output. Have you ever wondered that to use unicode everywhere inside the program, one needs to decode literals (or input) to unicode (the next sentence you complain about)? >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. I follow this principle in my programming since about 6 years ago, so I'm not a novice. I'm playing by the rules: a) "decodes it to unicode" is the first step to get it into processing. This is just a test case, so processing is zero. b) I refuse to believe that the only way to ensure something to be printed right is wrapping every item into unicode(var).encode('utf8') [The redundant unicode call is because the var could be a number, or a different object] c) or making my code non portable by patching site.py to get a real encoding instead of ascii. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 19:43 Message: Logged In: YES user_id=849994 Originator: NO First of all: Python's Unicode handling is very consistent and straightforward, if you know the basics. Sadly, most people don't know the difference between Unicode and encoded strings. What you're seeing is not a bug, it is due to the fact that if you print Unicode to the console, and Python could correctly find out your terminal encoding, the Unicode string is automatically encoded in that encoding. If you output to a file, Python does not know which encoding you want to have, so all Unicode strings are converted to ascii only. Please direct further questions to the Python mailing list or newsgroup. The basic rule when handling Unicode is: use Unicode everywhere inside the program, and byte strings for input and output. So, your code is exactly the other way round: it takes a byte string, decodes it to unicode and *then* prints it. You should do it the other way: use Unicode literals in your code, and when you write something to a file, *encode* them in utf-8. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 11:17 Message: Logged In: YES user_id=178886 Originator: YES Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn trunk Also, some people asks for repr of strings (I guess to reproduce if they can't read the caracters). Those are printed in utf-8: $python -c "print repr('? %s')" '\xc3\xa1 %s' $ python -c "print repr('?i')" '\xc3\xa9i' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 From noreply at sourceforge.net Wed Jun 27 19:25:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 10:25:15 -0700 Subject: [ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata Message-ID: Bugs item #1743795, was opened at 2007-06-26 18:45 Message generated for change (Comment added) made by admindomeny You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 Please note that this 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 Private: No Submitted By: admindomeny (admindomeny) Assigned to: M.-A. Lemburg (lemburg) Summary: Some incorrect national characters (Polish) in unicodedata Initial Comment: Hello, This problem regards pythonwin (I haven't checked whether unix/commandline python is affected), Python 2.5.1. Examples on attached screenshot. E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character (latin small a with some caret above it it seems) as well as print unicodedata.name( / latin small letter a with circumflex, typed in Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE', which is obviously incorrect. ---------------------------------------------------------------------- >Comment By: admindomeny (admindomeny) Date: 2007-06-27 17:25 Message: Logged In: YES user_id=1829093 Originator: YES You were correct, the attached test file for Polish national characters shows correctt character encodings when ran in Pythonwin and edited correctly Unicode with Polish characters from Unicode Unicode. The problem of entering characters in Pythonwin remains, however (OS: Win XP SP2, Polish edition): I have tried changing fonts to what are Unicode fonts as far as I know (Times New Roman, Arial, etc), including CE fonts as well. It doesn't work. I made sure that Polish Programmer's Keyboard is turned on which gives me correct encoding in almost all Windows applications, including Unicode editors like UniRed. Still, Pythonwin shell in particular thinks that AltGr+a (standard way of entering 'LATIN SMALL LETTER A WITH OGONEK') is actually 'SUPERSCRIPT ONE' for example. So, to summarize: 1. IDLE edits the text in Unicode correctly provided there's a #-*- coding: utf-8 -*- header in first line. 2. Pythonwin executes that file correctly. 3. Pythonwin enters national characters INCORRECTLY (at least as far Polish is concerned, but I suspect it's also the case with other languages). File Added: test.py ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 08:28 Message: Logged In: YES user_id=38388 Originator: NO This sounds more like a problem with entry of Unicode characters in pythonwin than the unicodedata module. Please create a test.py file with the character using e.g. UTF-8 as source code encoding and run that through the Python interpreter directly to see if the problem persists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 From noreply at sourceforge.net Wed Jun 27 21:38:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 12:38:25 -0700 Subject: [ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata Message-ID: Bugs item #1743795, was opened at 2007-06-26 20:45 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 Please note that this 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 Private: No Submitted By: admindomeny (admindomeny) >Assigned to: Mark Hammond (mhammond) Summary: Some incorrect national characters (Polish) in unicodedata Initial Comment: Hello, This problem regards pythonwin (I haven't checked whether unix/commandline python is affected), Python 2.5.1. Examples on attached screenshot. E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character (latin small a with some caret above it it seems) as well as print unicodedata.name( / latin small letter a with circumflex, typed in Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE', which is obviously incorrect. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 21:38 Message: Logged In: YES user_id=38388 Originator: NO Assigning to Mark Hammond who wrote Pythonwin. ---------------------------------------------------------------------- Comment By: admindomeny (admindomeny) Date: 2007-06-27 19:25 Message: Logged In: YES user_id=1829093 Originator: YES You were correct, the attached test file for Polish national characters shows correctt character encodings when ran in Pythonwin and edited correctly Unicode with Polish characters from Unicode Unicode. The problem of entering characters in Pythonwin remains, however (OS: Win XP SP2, Polish edition): I have tried changing fonts to what are Unicode fonts as far as I know (Times New Roman, Arial, etc), including CE fonts as well. It doesn't work. I made sure that Polish Programmer's Keyboard is turned on which gives me correct encoding in almost all Windows applications, including Unicode editors like UniRed. Still, Pythonwin shell in particular thinks that AltGr+a (standard way of entering 'LATIN SMALL LETTER A WITH OGONEK') is actually 'SUPERSCRIPT ONE' for example. So, to summarize: 1. IDLE edits the text in Unicode correctly provided there's a #-*- coding: utf-8 -*- header in first line. 2. Pythonwin executes that file correctly. 3. Pythonwin enters national characters INCORRECTLY (at least as far Polish is concerned, but I suspect it's also the case with other languages). File Added: test.py ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 10:28 Message: Logged In: YES user_id=38388 Originator: NO This sounds more like a problem with entry of Unicode characters in pythonwin than the unicodedata module. Please create a test.py file with the character using e.g. UTF-8 as source code encoding and run that through the Python interpreter directly to see if the problem persists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 From noreply at sourceforge.net Thu Jun 28 05:35:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 20:35:19 -0700 Subject: [ python-Feature Requests-1720992 ] automatic imports Message-ID: Feature Requests item #1720992, was opened at 2007-05-17 18:36 Message generated for change (Comment added) made by aflag You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1720992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Juan Manuel Borges Ca?o (juanmabc3) Assigned to: Nobody/Anonymous (nobody) Summary: automatic imports Initial Comment: I don't need to declare a variable but I need to declare a module, i.e import module, can this be done automatically?, so time.strftime requires import time automatically in the spirit of the python language, it saves typing and synchronization of the imports with the changes of the source code ---------------------------------------------------------------------- Comment By: Rafael Cunha de Almeida (aflag) Date: 2007-06-28 00:35 Message: Logged In: YES user_id=856271 Originator: NO I don't think this is a very good idea, if you'll be using the module name all the time, then you might as well simple import it. Besides, I think it could lead to confusion. You may have an object named fo in your script and if you mistakenly type foo a module will get imported and you won't understand anything. Specially if the module is something you don't even know about in your PYTHONPATH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1720992&group_id=5470 From noreply at sourceforge.net Thu Jun 28 05:36:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 20:36:12 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-28 05: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=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) Assigned to: Nobody/Anonymous (nobody) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Thu Jun 28 12:56:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 03:56:18 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-27 22:36 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 05:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Thu Jun 28 13:23:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 04:23:31 -0700 Subject: [ python-Bugs-1744752 ] Newline skipped in "for line in file" Message-ID: Bugs item #1744752, was opened at 2007-06-28 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=1744752&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rune Devik (runedevik) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: Creating new ticket for the bug described here since it was closed (and I was not able to reopen it): http://sourceforge.net/tracker/index.php?func=detail&aid=1636950&group_id=5470&atid=105470 The problem is that when you open a hughe file on windows with the "r" mode it will sometimes merge two lines. As I said in the ticket above (but probably ignored since I updated a closed ticket): Hi I have the same problem with a huge file (8GB) containing long lines. Sometimes two lines are merged into one and rerunning the test script that reads the file it's always the same lines that are merged. Also the merging happens more frequently towards the end of the file it seems. I tried to reproduce with a smaller data set (10 lines before the two lines that get merged, the two lines that gets merged and the 10 lines after that) but I was not able to reproduce on this smaller data set. However if you open this huge file in "rb" mode instead of "r" mode everything works as it should and no lines are merged at all! If I copy the file over to linux and rerun the test script no lines are merged (regardless if mode is "r" or "rb") so this is windows specific and might have something todo with the adding of \r\n if only \n is found when you open the file in "r" mode maybe? Also I have reproduced it on both python 2.3.5 and 2.5c1 on both windows XP and windows 2003. More stats on the input file in both "r" mode and "rb" mode below: Input file size: 8 695 828 KB fp = open(file, "r"): - total number of lines read: 668909 - length of the longest line: 13179792 - length of the shortest line: 89 - 56 lines contains the content of two lines - Always just two lines that are merged into one! - Always the same lines that are merged rerunning the test on the same file. open(file, "rb"): - total number of lines read: 668965 - length of the longest line: 13179793 - length of the shortest line: 90 - no lines merged Regards, Rune Devik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744752&group_id=5470 From noreply at sourceforge.net Thu Jun 28 13:35:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 04:35:39 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-28 13:36 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) Assigned to: Andrew McNamara (andrewmcnamara) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 21:35 Message: Logged In: YES user_id=698599 Originator: NO Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared. If you want to change a registered dialect, I suggest you do something like: csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t') This changes the dialect for new users, but doesn't disrupt the state of already running readers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 20:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Thu Jun 28 13:41:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 04:41:39 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-28 13:36 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) Assigned to: Andrew McNamara (andrewmcnamara) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 21:41 Message: Logged In: YES user_id=698599 Originator: NO I should also mention that if you simply wanted a reader of a variant of the "excel" dialect, the simplest way to achieve that is: r=csv.reader(f, dialect='excel', delimiter='\t') ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 21:35 Message: Logged In: YES user_id=698599 Originator: NO Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared. If you want to change a registered dialect, I suggest you do something like: csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t') This changes the dialect for new users, but doesn't disrupt the state of already running readers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 20:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Thu Jun 28 14:59:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 05:59:15 -0700 Subject: [ python-Bugs-1668295 ] Strange unicode behaviour Message-ID: Bugs item #1668295, was opened at 2007-02-25 12:10 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 Please note that this 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 Private: No Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Strange unicode behaviour Initial Comment: I know that python is very funny WRT unicode processing, but this defies all my knowledge. I use the es_ES.UTF-8 encoding on linux. The script: python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line. However, if I redirect it to less or to a file, like python -c "print unicode('? %s' % '??','utf8') " >test Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases? ---------------------------------------------------------------------- >Comment By: Santiago Gala (sgala) Date: 2007-06-28 14:59 Message: Logged In: YES user_id=178886 Originator: YES Still: $ python -c "import codecs,sys; sys.stdout = codecs.getwriter('utf-8')(sys.stdout); print sys.stdout.encoding" UTF-8 $ python -c "import codecs,sys; sys.stdout = codecs.getwriter('utf-8')(sys.stdout); print sys.stdout.encoding" | cat None but now, at least $ python -c "import codecs,sys; sys.stdout = codecs.getwriter('utf-8')(sys.stdout); print unicode('? %s' % '??','utf8') " ? ?? $ python -c "import codecs,sys; sys.stdout = codecs.getwriter('utf-8')(sys.stdout); print unicode('? %s' % '??','utf8') " | cat ? ?? can be piped. It still looks amazing to me that people is happy with this behavior. Waiting anxiously to see how this is dealt with in the str/unicode unification coming for python 3000... Santiago :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-27 14:04 Message: Logged In: YES user_id=849994 Originator: NO Yes, I'm sorry my fix is bad, you should rather use sys.stdout = codecs.getwriter('utf-8')(sys.stdout) ---------------------------------------------------------------------- Comment By: Omari Norman (massysett) Date: 2007-06-27 13:29 Message: Logged In: YES user_id=1764292 Originator: NO The fix given by gbrandl, which is to use sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') does not work. EncodedFile expects to receive encoded strings, so if you try to use it with Unicode strings, you get errors. I could of course I tried sys.stdout = codecs.open(sys.stdout, 'w', 'utf-8') but that gives me "Type Error: coercing to Unicode: need string or buffer, file found." Since this was (absurdly) closed as invalid, are there any good fixes that actually work? ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-03 14:22 Message: Logged In: YES user_id=178886 Originator: YES >This is not magic. "print" looks for an "encoding" attribute on the file >it is printing to. This is the terminal encoding for sys.stdout and None >for other files. I'll correct you: "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout *if sys.stdout is a terminal* and None when sys.stdout is not a terminal. After all, the bug reported is that *the same program* behaved different when used standalone than when piped to less: $ python -c "import sys; print sys.stdout.encoding" UTF-8 $ python -c "import sys; print sys.stdout.encoding" | cat None If you say that this is intended, not a bug, that an external process is altering the behavior of a python program, I'd just leave it written to warn other naive people like myself, that thinks that an external program should not influence python behavior (with *the same environment*): $ locale LANG=es_ES.UTF-8 LC_CTYPE="es_ES.UTF-8" LC_NUMERIC="es_ES.UTF-8" LC_TIME="es_ES.UTF-8" LC_COLLATE="es_ES.UTF-8" LC_MONETARY="es_ES.UTF-8" LC_MESSAGES="es_ES.UTF-8" LC_PAPER="es_ES.UTF-8" LC_NAME="es_ES.UTF-8" LC_ADDRESS="es_ES.UTF-8" LC_TELEPHONE="es_ES.UTF-8" LC_MEASUREMENT="es_ES.UTF-8" LC_IDENTIFICATION="es_ES.UTF-8" LC_ALL=es_ES.UTF-8 But I take it as a design flaw, and against all pythonic principles, probably coming from the fact that a lot of python developers/users are windows people that don't care about stdout at all. IMO, the behavior should be either: - use always None for sys.stdout - use always LC_CTYPE or LANG for sys.stdout I prefer the second one, as when I pipe stdout, after all, I expect it to be honoring my locale settings. Don't forget that the same person that types "|" after a call to python can type LC_ALL=blah before, while s/he can't sometimes modify the script because it is out of their permission set. The implementation logic would be simpler too, I guess. And more consistent with jython (it uses the second "always LC_CTYPE" solution). Not sure about iron-python or pypy. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-26 00:27 Message: Logged In: YES user_id=849994 Originator: NO > >>> sys.getfilesystemencoding() > 'UTF-8' > > so python is really dumb if print does not know my filesystemencoding, but > knows my terminal encoding. the file system encoding is the encoding of file names, not of file content. > I though breaking the least surprising behaviour was not considered > pythonic, and now you tell me that having a program running on console but > issuing an exception when redirected is intended. I would prefer an > exception in both cases. Or, even better, using > sys.getfilesystemencoding(), or allowing me to set defaultencoding() I agree that using the terminal encoding is perhaps a bit too DWIMish, but you can always get consistent results if you *do not write Unicode strings anywhere*. > Do you mean that I need to say print unicode(whatever).encode('utf8'), > like: > > >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and > understand, even in files encoded as utf8. Assume this is a literal or > input No. You can directly put Unicode literals in your files, with u'...'. For that to work, you need to tell Python the encoding your file has, using the coding cookie (see the docs). > ... > >>> print unicode(a).encode('utf8') # because a could be a number, or a > different object > > every time, instead of "a='?'; print a" > Cool, I'm starting to really love it. Concise and pythonic > Are you seriously meaning that there is no way to tell print to use a > default encoding, and it will magically try to find it and fail for > everything not being a terminal? This is not magic. "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout and None for other files. > Are you seriously telling me that this is not a bug? Even worse, that it > is "intended behaviour". BTW, jython acts differently about this, in all > the versions I tried. It *is* not a bug. This was implemented as a simplification for terminal output. > And with -S I am allowed to change the encoding, which is crippled in site > for no known good reason. > python -S -c "import sys; sys.setdefaultencoding('utf8'); print > unicode('\xc3\xa1','utf8')" >test > (works, test contains an accented a as intended Because setdefaultencoding() affects *every* conversion from unicode to string and from string to unicode, which can be very confusing if you have to handle different encodings. >>use Unicode everywhere inside the >>program, and byte strings for input and output. > Have you ever wondered that to use unicode everywhere inside the program, > one needs to decode literals (or input) to unicode (the next sentence you > complain about)? Yes, you have to decode input (for files, you can do this automatically if you use codecs.open(), not builtin open()). No, you don't have to decode literals as Unicode literals exist. > I follow this principle in my programming since about 6 years ago, so I'm > not a novice. I'm playing by the rules: > a) "decodes it to unicode" is the first step to get it into processing. > This is just a test case, so processing is zero. > b) I refuse to believe that the only way to ensure something to be printed > right is wrapping every item into unicode(var).encode('utf8') [The > redundant unicode call is because the var could be a number, or a different > object] No, that is of course not the only way. An alternative is to use an encoded file, as the codecs module offers. If you e.g. set sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') you can print Unicode strings to stdout, and they will automatically be converted using utf-8. This is clear and explicit. > c) or making my code non portable by patching site.py to get a real > encoding instead of ascii. If you still cannot live without setdefaultencoding(), you can do reload(sys) to get a sys module with this method. Closing again. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 23:27 Message: Logged In: YES user_id=178886 Originator: YES re: consistent, my experience it is that python unicode handling is consistently stupid, doing almost always the wrong thing. It remembers me of the defaults of WordPerfect, that were always exactly the opposite of what the user wanted 99% of time. I hope python 3000 comes fast and stops that real pain. I love the language, but the way it handles unicode provokes hundreds of bugs. >Python could correctly find out your terminal >encoding, the Unicode string is automatically encoded in that encoding. > >If you output to a file, Python does not know which encoding you want to >have, so all Unicode strings are converted to ascii only. >>> sys.getfilesystemencoding() 'UTF-8' so python is really dumb if print does not know my filesystemencoding, but knows my terminal encoding. I though breaking the least surprising behaviour was not considered pythonic, and now you tell me that having a program running on console but issuing an exception when redirected is intended. I would prefer an exception in both cases. Or, even better, using sys.getfilesystemencoding(), or allowing me to set defaultencoding() >Please direct further questions to the Python mailing list or newsgroup. I would if I didn't consider this behaviour a bug, and a serious one. >The basic rule when handling Unicode is: use Unicode everywhere inside the >program, and byte strings for input and output. >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. > >You should do it the other way: use Unicode literals in your code, and >when y(ou write something to a file, *encode* them in utf-8. Do you mean that I need to say print unicode(whatever).encode('utf8'), like: >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and understand, even in files encoded as utf8. Assume this is a literal or input ... >>> print unicode(a).encode('utf8') # because a could be a number, or a different object every time, instead of "a='?'; print a" Cool, I'm starting to really love it. Concise and pythonic Are you seriously meaning that there is no way to tell print to use a default encoding, and it will magically try to find it and fail for everything not being a terminal? Are you seriously telling me that this is not a bug? Even worse, that it is "intended behaviour". BTW, jython acts differently about this, in all the versions I tried. And with -S I am allowed to change the encoding, which is crippled in site for no known good reason. python -S -c "import sys; sys.setdefaultencoding('utf8'); print unicode('\xc3\xa1','utf8')" >test (works, test contains an accented a as intended >use Unicode everywhere inside the >program, and byte strings for input and output. Have you ever wondered that to use unicode everywhere inside the program, one needs to decode literals (or input) to unicode (the next sentence you complain about)? >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. I follow this principle in my programming since about 6 years ago, so I'm not a novice. I'm playing by the rules: a) "decodes it to unicode" is the first step to get it into processing. This is just a test case, so processing is zero. b) I refuse to believe that the only way to ensure something to be printed right is wrapping every item into unicode(var).encode('utf8') [The redundant unicode call is because the var could be a number, or a different object] c) or making my code non portable by patching site.py to get a real encoding instead of ascii. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 20:43 Message: Logged In: YES user_id=849994 Originator: NO First of all: Python's Unicode handling is very consistent and straightforward, if you know the basics. Sadly, most people don't know the difference between Unicode and encoded strings. What you're seeing is not a bug, it is due to the fact that if you print Unicode to the console, and Python could correctly find out your terminal encoding, the Unicode string is automatically encoded in that encoding. If you output to a file, Python does not know which encoding you want to have, so all Unicode strings are converted to ascii only. Please direct further questions to the Python mailing list or newsgroup. The basic rule when handling Unicode is: use Unicode everywhere inside the program, and byte strings for input and output. So, your code is exactly the other way round: it takes a byte string, decodes it to unicode and *then* prints it. You should do it the other way: use Unicode literals in your code, and when you write something to a file, *encode* them in utf-8. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 12:17 Message: Logged In: YES user_id=178886 Originator: YES Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn trunk Also, some people asks for repr of strings (I guess to reproduce if they can't read the caracters). Those are printed in utf-8: $python -c "print repr('? %s')" '\xc3\xa1 %s' $ python -c "print repr('?i')" '\xc3\xa9i' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 From noreply at sourceforge.net Thu Jun 28 16:38:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 07:38:34 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-27 22:36 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) Assigned to: Andrew McNamara (andrewmcnamara) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 09:38 Message: Logged In: YES user_id=44345 Originator: NO Would it have made sense to save the class when registering then return a new instance from get_dialect()? I believe the current scheme instantiates the dialect being registered, then returns that object anytime get_dialect is called. That would have allowed the user to modify the returned dialect to their heart's content without messing up the registered dialect. At the very least I think this change needs to be documented. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 06:41 Message: Logged In: YES user_id=698599 Originator: NO I should also mention that if you simply wanted a reader of a variant of the "excel" dialect, the simplest way to achieve that is: r=csv.reader(f, dialect='excel', delimiter='\t') ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 06:35 Message: Logged In: YES user_id=698599 Originator: NO Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared. If you want to change a registered dialect, I suggest you do something like: csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t') This changes the dialect for new users, but doesn't disrupt the state of already running readers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 05:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Thu Jun 28 21:44:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 12:44:15 -0700 Subject: [ python-Bugs-1745035 ] DoS smtpd vulnerability Message-ID: Bugs item #1745035, was opened at 2007-06-28 21:44 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=1745035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 From noreply at sourceforge.net Thu Jun 28 21:45:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 12:45:47 -0700 Subject: [ python-Bugs-1745035 ] DoS smtpd vulnerability Message-ID: Bugs item #1745035, was opened at 2007-06-28 21:44 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-06-28 21:45 Message: Logged In: YES user_id=1357589 Originator: YES --- malicious script import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 8025)) while 1: s.sendall('x' * 1024) --- proposed smtpd.py patch 124a125 > self.__in_buffer_len = 0 135a137,139 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 From noreply at sourceforge.net Thu Jun 28 21:46:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 12:46:18 -0700 Subject: [ python-Bugs-1745035 ] DoS smtpd vulnerability Message-ID: Bugs item #1745035, was opened at 2007-06-28 21:44 Message generated for change (Settings changed) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 Please note that this 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: 9 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-28 21:45 Message: Logged In: YES user_id=1357589 Originator: YES --- malicious script import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 8025)) while 1: s.sendall('x' * 1024) --- proposed smtpd.py patch 124a125 > self.__in_buffer_len = 0 135a137,139 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 From noreply at sourceforge.net Fri Jun 29 01:32:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 16:32:24 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-28 13:36 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Kristukat (ckkart) Assigned to: Andrew McNamara (andrewmcnamara) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-29 09:32 Message: Logged In: YES user_id=698599 Originator: NO The user already has a number of entirely satisfactory ways to "modify" the dialect - the module is implemented as it is to keep the code simple and obvious (from a maintenance point of view). As far as I'm concerned the old behaviour was undocumented and accidental. I don't mind if you want to document the new behaviour, but I'm afraid I don't have time to do it at the moment. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 00:38 Message: Logged In: YES user_id=44345 Originator: NO Would it have made sense to save the class when registering then return a new instance from get_dialect()? I believe the current scheme instantiates the dialect being registered, then returns that object anytime get_dialect is called. That would have allowed the user to modify the returned dialect to their heart's content without messing up the registered dialect. At the very least I think this change needs to be documented. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 21:41 Message: Logged In: YES user_id=698599 Originator: NO I should also mention that if you simply wanted a reader of a variant of the "excel" dialect, the simplest way to achieve that is: r=csv.reader(f, dialect='excel', delimiter='\t') ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 21:35 Message: Logged In: YES user_id=698599 Originator: NO Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared. If you want to change a registered dialect, I suggest you do something like: csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t') This changes the dialect for new users, but doesn't disrupt the state of already running readers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 20:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Fri Jun 29 02:13:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 17:13:53 -0700 Subject: [ python-Bugs-1745108 ] 2.5.1 curses panel segfault in new_panel on aix 5.3 Message-ID: Bugs item #1745108, was opened at 2007-06-29 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=1745108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mattias Wadenstein (maswan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 curses panel segfault in new_panel on aix 5.3 Initial Comment: I've compiled python 2.5.1 on AIX 5.3 with ncurses 5.6 and I get segmentation faults as soon as any curses.panel tries to make a new panel. The following test program gives a segmentation fault for me (remove the new_panel line and it works fine): import curses from curses import panel def mkpanel(scr): win = curses.newwin(8,8,1,1) pan = panel.new_panel(win) curses.wrapper(mkpanel) Also the test_curses program triggers this segfault. A traceback puts the problem in: root_panel(), line 57 in "p_new.c" new_panel(win = 0x0000000110246dc0), line 90 in "p_new.c" PyCurses_new_panel(self = (nil), args = 0x0000000110246dc0), line 396 in "_curses_panel.c" PyCFunction_Call(func = 0x000000011024a368, arg = 0x0000000110246dc0, kw = (nil)), line 73 in "methodobject.c" Note that the ncurses I've compiled works fine with the shipped test programs, so it seems to be an issue with the python interaction. Please let me know if there is anything else that I can provide to help track this bug down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745108&group_id=5470 From noreply at sourceforge.net Fri Jun 29 04:46:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 19:46:15 -0700 Subject: [ python-Bugs-1744580 ] cvs.get_dialect() return a class object Message-ID: Bugs item #1744580, was opened at 2007-06-27 22:36 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 Please note that this 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 Private: No Submitted By: Christian Kristukat (ckkart) >Assigned to: Skip Montanaro (montanaro) Summary: cvs.get_dialect() return a class object Initial Comment: With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes. % python2.4 Python 2.4.1 (#3, Jul 28 2005, 22:08:40) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> d = csv.get_dialect("excel") >>> d <_csv.Dialect object at 0x137fac0> ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 21:46 Message: Logged In: YES user_id=44345 Originator: NO Grabbing this. I'll try to come up with some wording about the change. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 18:32 Message: Logged In: YES user_id=698599 Originator: NO The user already has a number of entirely satisfactory ways to "modify" the dialect - the module is implemented as it is to keep the code simple and obvious (from a maintenance point of view). As far as I'm concerned the old behaviour was undocumented and accidental. I don't mind if you want to document the new behaviour, but I'm afraid I don't have time to do it at the moment. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 09:38 Message: Logged In: YES user_id=44345 Originator: NO Would it have made sense to save the class when registering then return a new instance from get_dialect()? I believe the current scheme instantiates the dialect being registered, then returns that object anytime get_dialect is called. That would have allowed the user to modify the returned dialect to their heart's content without messing up the registered dialect. At the very least I think this change needs to be documented. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 06:41 Message: Logged In: YES user_id=698599 Originator: NO I should also mention that if you simply wanted a reader of a variant of the "excel" dialect, the simplest way to achieve that is: r=csv.reader(f, dialect='excel', delimiter='\t') ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2007-06-28 06:35 Message: Logged In: YES user_id=698599 Originator: NO Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared. If you want to change a registered dialect, I suggest you do something like: csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t') This changes the dialect for new users, but doesn't disrupt the state of already running readers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-28 05:56 Message: Logged In: YES user_id=44345 Originator: NO I took a brief look at the code. get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5. There is a new static function, _call_dialect, though. It is called from several places, most notably from csv_register_dialect. The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect. I suspect there was some sort of regression there. Assigning to Andrew since he's the primary author of the code as well as the author of this particular change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744580&group_id=5470 From noreply at sourceforge.net Fri Jun 29 09:14:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 00:14:26 -0700 Subject: [ python-Bugs-1745178 ] pdtri gives wrong results Message-ID: Bugs item #1745178, was opened at 2007-06-29 10:14 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=1745178&group_id=5470 Please note that this 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 Private: No Submitted By: Nikke Knatterton (funke_) Assigned to: Nobody/Anonymous (nobody) Summary: pdtri gives wrong results Initial Comment: pdtri function, aka inverse of Poisson cumulative distribution gives wrong results when I use it. For example when expected count is 20: >>> pdtri(20,0.001) 38.041881353850023 when in Matlab: >> poissinv(0.999, 20) ans = 35 I checked the value from http://stattrek.com/Tables/Poisson.aspx where cumulative probability for 35 is 0.999196 and for 38 it is 0.999891...clearly the latter is wrong. Or don't I use the function correctly? (For some reason the probability 0.999 is given as 0.001 in python) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745178&group_id=5470 From noreply at sourceforge.net Fri Jun 29 09:33:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 00:33:04 -0700 Subject: [ python-Bugs-1745178 ] pdtri gives wrong results Message-ID: Bugs item #1745178, was opened at 2007-06-29 07:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745178&group_id=5470 Please note that this 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 Private: No Submitted By: Nikke Knatterton (funke_) Assigned to: Nobody/Anonymous (nobody) Summary: pdtri gives wrong results Initial Comment: pdtri function, aka inverse of Poisson cumulative distribution gives wrong results when I use it. For example when expected count is 20: >>> pdtri(20,0.001) 38.041881353850023 when in Matlab: >> poissinv(0.999, 20) ans = 35 I checked the value from http://stattrek.com/Tables/Poisson.aspx where cumulative probability for 35 is 0.999196 and for 38 it is 0.999891...clearly the latter is wrong. Or don't I use the function correctly? (For some reason the probability 0.999 is given as 0.001 in python) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-29 07:33 Message: Logged In: YES user_id=849994 Originator: NO There is no "pdtri" function in the Python core and standard library. If this function is coming from SciPy, you should report or discuss that issue with them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745178&group_id=5470 From noreply at sourceforge.net Fri Jun 29 20:00:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 11:00:38 -0700 Subject: [ python-Bugs-1745035 ] DoS smtpd vulnerability Message-ID: Bugs item #1745035, was opened at 2007-06-28 21:44 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 Please note that this 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: 9 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-06-29 20:00 Message: Logged In: YES user_id=1357589 Originator: YES Sorry, I realized I've forgotten to reset to zero the bytes counter. Here's the patch of the patch: 124a125 > self.__in_buffer_len = 0 135a137,140 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] > self.__in_buffer_len = 0 141a147 > self.__in_buffer_len = 0 ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-28 21:45 Message: Logged In: YES user_id=1357589 Originator: YES --- malicious script import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 8025)) while 1: s.sendall('x' * 1024) --- proposed smtpd.py patch 124a125 > self.__in_buffer_len = 0 135a137,139 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 From noreply at sourceforge.net Fri Jun 29 21:11:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 12:11:40 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 18:02 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 19:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 20:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 14:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 20:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 17:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 18:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Fri Jun 29 23:05:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 14:05:53 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-29 14: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=1745533&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Damian (atagar) Assigned to: Nobody/Anonymous (nobody) Summary: Filename providing cross platform capability Initial Comment: The help section for the open method should note that a Unix style filename work in a cross platform fashion (like Java). After scouring several resources including two O'Reilly texts on Python, a dozen web pages, all reliant help pages, I finally got my answer from a mailing list. -Damian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 From noreply at sourceforge.net Sat Jun 30 01:37:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 16:37:47 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 18:02 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 23:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 19:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 20:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 14:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 20:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 17:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 18:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 04:39:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 19:39:22 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 18:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 14:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 04:45:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 19:45:36 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 18:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 14:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 05:32:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 20:32:02 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 18:02 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-30 03:32 Message: Logged In: YES user_id=703403 Originator: NO I think your minor(?) data point is a major data point. I'm using the Macports version of sqlite3. Furthermore, after hiding the /usr/lib version with fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib libsqlite3.0.dylib.temp I can't reproduce the problem any more. I tried sprinkling a few printf statements through the sqlite3 source to see what was going on. Bizarrely, it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being called from the Macports createCollation(); or at least that's the only way that I can understand the results I'm getting. Is this possible? Mark ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 02:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 02:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 23:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 19:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 20:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 14:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 20:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 17:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 18:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 05:56:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 20:56:14 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 18:02 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-30 03:56 Message: Logged In: YES user_id=703403 Originator: NO It looks as though GLUT is a red herring. I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData, as in the following lines. import ctypes ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData') import sqlite3 sqlite3.connect(":memory:") Furthermore, I notice that the GLUT framework has a library dependency on the AppKit framework, AppKit on CoreData, and CoreData depends on the Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately depend on libsqlite3. Coincidence? I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is unnecessary.) ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-30 03:32 Message: Logged In: YES user_id=703403 Originator: NO I think your minor(?) data point is a major data point. I'm using the Macports version of sqlite3. Furthermore, after hiding the /usr/lib version with fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib libsqlite3.0.dylib.temp I can't reproduce the problem any more. I tried sprinkling a few printf statements through the sqlite3 source to see what was going on. Bizarrely, it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being called from the Macports createCollation(); or at least that's the only way that I can understand the results I'm getting. Is this possible? Mark ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 02:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 02:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 23:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 19:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 20:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 14:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 20:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 17:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 18:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 12:42:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 03:42:08 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 05:42 Message: Logged In: YES user_id=44345 Originator: YES I'll be damned... Based on your last response I ran Python under ktrace then looked at the kdump output. As it's marching along it sees a mention of /usr/lib/libsqlite3.so in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData then just a few lines later I see 20023 python NAMI "/usr/lib/libsqlite3.0.dylib" 20023 python RET open 3 20023 python CALL fstat(0x3,0xbfffc770) 20023 python RET fstat 0 20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0) then a bit later I see what I had wanted to see: 20023 python NAMI "/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff9c00) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfffa060,0x1000,0) ... 20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff99b0) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfff9e10,0x1000,0) I can't execute the CDLL call if I've renamed /usr/lib/libsqlite.3.0.dylib. (I suppose that stands to reason.) Now the question becomes whether or not the Apple-provided library can be replaced with something more modern. Presumably every application that uses CoreData (most Apple things) gets it if during startup. Thomas, for the purposes of the Python regression test suite do you think you can find something other than GLUT to dynamically load? Mark, thanks for the sleuthing. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:56 Message: Logged In: YES user_id=703403 Originator: NO It looks as though GLUT is a red herring. I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData, as in the following lines. import ctypes ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData') import sqlite3 sqlite3.connect(":memory:") Furthermore, I notice that the GLUT framework has a library dependency on the AppKit framework, AppKit on CoreData, and CoreData depends on the Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately depend on libsqlite3. Coincidence? I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is unnecessary.) ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:32 Message: Logged In: YES user_id=703403 Originator: NO I think your minor(?) data point is a major data point. I'm using the Macports version of sqlite3. Furthermore, after hiding the /usr/lib version with fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib libsqlite3.0.dylib.temp I can't reproduce the problem any more. I tried sprinkling a few printf statements through the sqlite3 source to see what was going on. Bizarrely, it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being called from the Macports createCollation(); or at least that's the only way that I can understand the results I'm getting. Is this possible? Mark ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 18:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 14:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 13:15:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 04:15:30 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 06:15 Message: Logged In: YES user_id=44345 Originator: YES I submitted a bug report to Apple about the problem, though I don't really expect a response. (The other bug I filed in 2004 has never received any response as far as I can tell.) Maybe a more recent version of SQLite will be delivered with Leopard... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 05:42 Message: Logged In: YES user_id=44345 Originator: YES I'll be damned... Based on your last response I ran Python under ktrace then looked at the kdump output. As it's marching along it sees a mention of /usr/lib/libsqlite3.so in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData then just a few lines later I see 20023 python NAMI "/usr/lib/libsqlite3.0.dylib" 20023 python RET open 3 20023 python CALL fstat(0x3,0xbfffc770) 20023 python RET fstat 0 20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0) then a bit later I see what I had wanted to see: 20023 python NAMI "/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff9c00) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfffa060,0x1000,0) ... 20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff99b0) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfff9e10,0x1000,0) I can't execute the CDLL call if I've renamed /usr/lib/libsqlite.3.0.dylib. (I suppose that stands to reason.) Now the question becomes whether or not the Apple-provided library can be replaced with something more modern. Presumably every application that uses CoreData (most Apple things) gets it if during startup. Thomas, for the purposes of the Python regression test suite do you think you can find something other than GLUT to dynamically load? Mark, thanks for the sleuthing. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:56 Message: Logged In: YES user_id=703403 Originator: NO It looks as though GLUT is a red herring. I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData, as in the following lines. import ctypes ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData') import sqlite3 sqlite3.connect(":memory:") Furthermore, I notice that the GLUT framework has a library dependency on the AppKit framework, AppKit on CoreData, and CoreData depends on the Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately depend on libsqlite3. Coincidence? I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is unnecessary.) ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:32 Message: Logged In: YES user_id=703403 Originator: NO I think your minor(?) data point is a major data point. I'm using the Macports version of sqlite3. Furthermore, after hiding the /usr/lib version with fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib libsqlite3.0.dylib.temp I can't reproduce the problem any more. I tried sprinkling a few printf statements through the sqlite3 source to see what was going on. Bizarrely, it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being called from the Macports createCollation(); or at least that's the only way that I can understand the results I'm getting. Is this possible? Mark ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 18:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 14:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 14:24:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 05:24:48 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-30 02:35 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Damian (atagar) Assigned to: Nobody/Anonymous (nobody) Summary: Filename providing cross platform capability Initial Comment: The help section for the open method should note that a Unix style filename work in a cross platform fashion (like Java). After scouring several resources including two O'Reilly texts on Python, a dozen web pages, all reliant help pages, I finally got my answer from a mailing list. -Damian ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-30 17:54 Message: Logged In: YES user_id=942711 Originator: NO I am not getting as what you are indicating Damian. You mean to say use '/' forward slashes in all documentation as they can work cross platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 From noreply at sourceforge.net Sat Jun 30 15:17:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 06:17:25 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 08:17 Message: Logged In: YES user_id=44345 Originator: YES Thomas, Here's a possible modification to ctypes.test.test_find which appears to be the only place that OpenGL (and thus CoreData on the Mac?) is accessed. On Darwin I replace the GL find stuff with Tcl find stuff. It's a bit ugly, but it might solve the problem. Skip File Added: test_find.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 06:15 Message: Logged In: YES user_id=44345 Originator: YES I submitted a bug report to Apple about the problem, though I don't really expect a response. (The other bug I filed in 2004 has never received any response as far as I can tell.) Maybe a more recent version of SQLite will be delivered with Leopard... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 05:42 Message: Logged In: YES user_id=44345 Originator: YES I'll be damned... Based on your last response I ran Python under ktrace then looked at the kdump output. As it's marching along it sees a mention of /usr/lib/libsqlite3.so in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData then just a few lines later I see 20023 python NAMI "/usr/lib/libsqlite3.0.dylib" 20023 python RET open 3 20023 python CALL fstat(0x3,0xbfffc770) 20023 python RET fstat 0 20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0) then a bit later I see what I had wanted to see: 20023 python NAMI "/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff9c00) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfffa060,0x1000,0) ... 20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff99b0) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfff9e10,0x1000,0) I can't execute the CDLL call if I've renamed /usr/lib/libsqlite.3.0.dylib. (I suppose that stands to reason.) Now the question becomes whether or not the Apple-provided library can be replaced with something more modern. Presumably every application that uses CoreData (most Apple things) gets it if during startup. Thomas, for the purposes of the Python regression test suite do you think you can find something other than GLUT to dynamically load? Mark, thanks for the sleuthing. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:56 Message: Logged In: YES user_id=703403 Originator: NO It looks as though GLUT is a red herring. I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData, as in the following lines. import ctypes ctypes.CDLL('/System/Library/Frameworks/CoreData.framework/CoreData') import sqlite3 sqlite3.connect(":memory:") Furthermore, I notice that the GLUT framework has a library dependency on the AppKit framework, AppKit on CoreData, and CoreData depends on the Apple-supplied libsqlite3, and that Quartz and Cocoa similarly ultimately depend on libsqlite3. Coincidence? I can reproduce the problem with a variety of frameworks in place of GLUT, for example Quartz, Cocoa, AppKit, CoreData. (The .glutWireTetrahedron is unnecessary.) ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 22:32 Message: Logged In: YES user_id=703403 Originator: NO I think your minor(?) data point is a major data point. I'm using the Macports version of sqlite3. Furthermore, after hiding the /usr/lib version with fibonacci:/usr/lib dickinsm$ sudo mv libsqlite3.0.dylib libsqlite3.0.dylib.temp I can't reproduce the problem any more. I tried sprinkling a few printf statements through the sqlite3 source to see what was going on. Bizarrely, it looks as though the Apple-supplied sqlite3SafetyCheck() routine is being called from the Macports createCollation(); or at least that's the only way that I can understand the results I'm getting. Is this possible? Mark ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:45 Message: Logged In: YES user_id=44345 Originator: YES One other minor(?) data point. I am using a version of sqlite3 which I compiled and installed, not Apple's older version: >>> sqlite3.version, sqlite3.sqlite_version ('2.3.3', '3.3.8') ... % pwd /Users/skip/local/lib/python2.6/lib-dynload % otool -L _sqlite3.so _sqlite3.so: /Users/skip/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7) It appears those of us who can reproduce the problem all have slightly different installs (2.5 v. 2.6, Apple's GCC v. DarwinPorts, Apple's sqlite3 v. DarwinPorts v. homebuilt, G4 v. G5 v. Intel architecture). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-29 21:39 Message: Logged In: YES user_id=44345 Originator: YES Fails for me as well (Python 2.6a0, PowerBook G4, 10.4.10, Apple's GCC 4.0.1). Thomas, can you reproduce with the lines marketdickinson used? I don't see any directory changing going on: % python Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.getcwd() '/Users/skip' >>> from ctypes import CDLL>>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron<_FuncPtr object at 0x106c6c0> >>> os.getcwd() '/Users/skip' >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in ProgrammingError: library routine called out of sequence >>> os.getcwd() '/Users/skip' Pass it back if you still can't reproduce the problem. Meanwhile I've subscribed to the pysqlite mailing list and will ask there. Skip ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 18:37 Message: Logged In: YES user_id=703403 Originator: NO And also on Python 2.5, compiled under Apple's GCC. (Still OS X 10.4.10/G4) The following four lines of Python code are enough to cause the problem for me. Interestingly, if the second and third lines are exchanged (so that the two import commands come first), then no exception is raised. Python 2.5.1 (r251:54863, May 10 2007, 20:59:25) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import CDLL >>> CDLL('/System/Library/Frameworks/GLUT.framework/GLUT').glutWireTetrahedron <_FuncPtr object at 0x514500> >>> import sqlite3 >>> sqlite3.connect(":memory:") Traceback (most recent call last): File "", line 1, in sqlite3.ProgrammingError: library routine called out of sequence ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-29 14:11 Message: Logged In: YES user_id=703403 Originator: NO I've just noticed the same failure on an iBook G4, with OS X 10.4.10, sqlite version 3.4.0, and Python built with gcc 4.2.0 (from macports). (Python 2.6a0 (trunk:56123M, Jun 29 2007, 13:22:18) [GCC 4.2.0] on darwin) ---------------------------------------------------------------------- Comment By: ted pollari (incongruity) Date: 2007-06-13 15:19 Message: Logged In: YES user_id=1375728 Originator: NO FWIW, I'm getting an identical error on a MacBook Pro with a Core Duo processor ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 09:04 Message: Logged In: YES user_id=11105 Originator: NO FYI, this PyOpenGL bug may be related: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1712741&group_id=5988 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-22 15:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sat Jun 30 15:31:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 06:31:58 -0700 Subject: [ python-Feature Requests-1745722 ] please add wsgi to SimpleXMLRPCServer Message-ID: Feature Requests item #1745722, was opened at 2007-06-30 13:31 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=1745722&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Helmut Grohne (gnarfk) Assigned to: Nobody/Anonymous (nobody) Summary: please add wsgi to SimpleXMLRPCServer Initial Comment: There should be a simple wsgi xmlrpc application and in fact it is not difficult. You could for instance take this one and append it to SimpleXMLRPCServer.py. class WSGIXMLRPCRequestHandler(SimpleXMLRPCDispatcher): def __init__(self, allow_none=False, encoding=None): SimpleXMLRPCDispatcher.__init__(self, allow_none, encoding) def __call__(self, environ, start_response): """WSGI interface""" if environ["REQUEST_METHOD"] != "POST": status = "400 Bad request" headers = [("Content-type", "text/html")] data = "400 Bad request

400 Bad request

" headers.append(("Content-length", str(len(data)))) start_response(status, headers) if environ["REQUEST_METHOD"] == "HEAD": return [] return [data] l = int(environ["CONTENT_LENGTH"]) request = environ["wsgi.input"].read(l) response = self._marshaled_dispatch(request) headers = [("Content-type", "text/xml")] headers.append(("Content-length", str(len(response)))) start_response("200 OK", headers) return [response] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&group_id=5470 From noreply at sourceforge.net Sat Jun 30 16:59:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 07:59:58 -0700 Subject: [ python-Feature Requests-1745722 ] please add wsgi to SimpleXMLRPCServer Message-ID: Feature Requests item #1745722, was opened at 2007-06-30 13:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Helmut Grohne (gnarfk) >Assigned to: Fredrik Lundh (effbot) Summary: please add wsgi to SimpleXMLRPCServer Initial Comment: There should be a simple wsgi xmlrpc application and in fact it is not difficult. You could for instance take this one and append it to SimpleXMLRPCServer.py. class WSGIXMLRPCRequestHandler(SimpleXMLRPCDispatcher): def __init__(self, allow_none=False, encoding=None): SimpleXMLRPCDispatcher.__init__(self, allow_none, encoding) def __call__(self, environ, start_response): """WSGI interface""" if environ["REQUEST_METHOD"] != "POST": status = "400 Bad request" headers = [("Content-type", "text/html")] data = "400 Bad request

400 Bad request

" headers.append(("Content-length", str(len(data)))) start_response(status, headers) if environ["REQUEST_METHOD"] == "HEAD": return [] return [data] l = int(environ["CONTENT_LENGTH"]) request = environ["wsgi.input"].read(l) response = self._marshaled_dispatch(request) headers = [("Content-type", "text/xml")] headers.append(("Content-length", str(len(response)))) start_response("200 OK", headers) return [response] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-30 14:59 Message: Logged In: YES user_id=849994 Originator: NO Assigned to Fredrik. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1745722&group_id=5470 From noreply at sourceforge.net Sat Jun 30 18:38:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 09:38:49 -0700 Subject: [ python-Bugs-1745761 ] Bad attributes/data handling in SGMLib Message-ID: Bugs item #1745761, was opened at 2007-06-30 16: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=1745761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alvaro Lopez (wolfete) Assigned to: Nobody/Anonymous (nobody) Summary: Bad attributes/data handling in SGMLib Initial Comment: When feeding an parser with a tag in which its arguments contain a < (as in example the SGMLParsers doesn't handle the data/arguments correcly. For example, with the above string I get: Fed: example Tag opened: a Arg href -> http://www.example.org/">; Arg escaped 'http://www.example.org/">;' Data: ;'>example Tag closed: a I have attached a small example. I'm using python2.5.1 Cheers, ?lvaro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745761&group_id=5470 From noreply at sourceforge.net Sat Jun 30 19:31:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 10:31:05 -0700 Subject: [ python-Bugs-1745035 ] DoS smtpd vulnerability Message-ID: Bugs item #1745035, was opened at 2007-06-28 21:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 Please note that this 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: 7 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS smtpd vulnerability Initial Comment: Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). Without truncating such buffer a simple malicious script sending extremely long lines without "\r\n" terminator could easily saturate system resources. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-29 20:00 Message: Logged In: YES user_id=1357589 Originator: YES Sorry, I realized I've forgotten to reset to zero the bytes counter. Here's the patch of the patch: 124a125 > self.__in_buffer_len = 0 135a137,140 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] > self.__in_buffer_len = 0 141a147 > self.__in_buffer_len = 0 ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-28 21:45 Message: Logged In: YES user_id=1357589 Originator: YES --- malicious script import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 8025)) while 1: s.sendall('x' * 1024) --- proposed smtpd.py patch 124a125 > self.__in_buffer_len = 0 135a137,139 > self.__in_buffer_len += len(data) > if self.__in_buffer_len > 4096: > self.__line = [] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745035&group_id=5470 From noreply at sourceforge.net Sat Jun 30 19:34:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 10:34:06 -0700 Subject: [ python-Bugs-1743795 ] Some incorrect national characters (Polish) in unicodedata Message-ID: Bugs item #1743795, was opened at 2007-06-26 20:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: admindomeny (admindomeny) Assigned to: Mark Hammond (mhammond) Summary: Some incorrect national characters (Polish) in unicodedata Initial Comment: Hello, This problem regards pythonwin (I haven't checked whether unix/commandline python is affected), Python 2.5.1. Examples on attached screenshot. E.g. print u'\N{LATIN SMALL LETTER A WITH CIRCUMFLEX}' prints wrong character (latin small a with some caret above it it seems) as well as print unicodedata.name( / latin small letter a with circumflex, typed in Windows using Polish "programmer's keyboard" / ) produces 'SUPERSCRIPT ONE', which is obviously incorrect. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-30 19:34 Message: Logged In: YES user_id=21627 Originator: NO Actually, we should close this here. Please report it through the PythonWin bugtracker. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 21:38 Message: Logged In: YES user_id=38388 Originator: NO Assigning to Mark Hammond who wrote Pythonwin. ---------------------------------------------------------------------- Comment By: admindomeny (admindomeny) Date: 2007-06-27 19:25 Message: Logged In: YES user_id=1829093 Originator: YES You were correct, the attached test file for Polish national characters shows correctt character encodings when ran in Pythonwin and edited correctly Unicode with Polish characters from Unicode Unicode. The problem of entering characters in Pythonwin remains, however (OS: Win XP SP2, Polish edition): I have tried changing fonts to what are Unicode fonts as far as I know (Times New Roman, Arial, etc), including CE fonts as well. It doesn't work. I made sure that Polish Programmer's Keyboard is turned on which gives me correct encoding in almost all Windows applications, including Unicode editors like UniRed. Still, Pythonwin shell in particular thinks that AltGr+a (standard way of entering 'LATIN SMALL LETTER A WITH OGONEK') is actually 'SUPERSCRIPT ONE' for example. So, to summarize: 1. IDLE edits the text in Unicode correctly provided there's a #-*- coding: utf-8 -*- header in first line. 2. Pythonwin executes that file correctly. 3. Pythonwin enters national characters INCORRECTLY (at least as far Polish is concerned, but I suspect it's also the case with other languages). File Added: test.py ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-27 10:28 Message: Logged In: YES user_id=38388 Originator: NO This sounds more like a problem with entry of Unicode characters in pythonwin than the unicodedata module. Please create a test.py file with the character using e.g. UTF-8 as source code encoding and run that through the Python interpreter directly to see if the problem persists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1743795&group_id=5470 From noreply at sourceforge.net Sat Jun 30 23:38:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 14:38:25 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-29 14:05 Message generated for change (Comment added) made by atagar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Damian (atagar) Assigned to: Nobody/Anonymous (nobody) Summary: Filename providing cross platform capability Initial Comment: The help section for the open method should note that a Unix style filename work in a cross platform fashion (like Java). After scouring several resources including two O'Reilly texts on Python, a dozen web pages, all reliant help pages, I finally got my answer from a mailing list. -Damian ---------------------------------------------------------------------- >Comment By: Damian (atagar) Date: 2007-06-30 14:38 Message: Logged In: YES user_id=1613266 Originator: YES No, I'm talking about the documentation when entering help(file) or help(open). The filename parameter works in a cross platform fashion when given a Unix path. For instance, file = open("/path/to/content.xml", "r") # Cross platform file = open("\\path\\to\\content.xml", "r") # Win32 only This seemed to be an undocumented yet important detail (unless I'm mistaken it means its advantageous to always use the former method when coding paths). However, looking around some more I think this is largely a misunderstanding on my part in terms of where the cross platform capability came from (Windows accepting a forward slash rather than the open method translating the path for the current OS). Sorry about the confusion. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-30 05:24 Message: Logged In: YES user_id=942711 Originator: NO I am not getting as what you are indicating Damian. You mean to say use '/' forward slashes in all documentation as they can work cross platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 From noreply at sourceforge.net Sat Jun 30 23:48:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 14:48:06 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-29 14:05 Message generated for change (Comment added) made by atagar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Damian (atagar) Assigned to: Nobody/Anonymous (nobody) Summary: Filename providing cross platform capability Initial Comment: The help section for the open method should note that a Unix style filename work in a cross platform fashion (like Java). After scouring several resources including two O'Reilly texts on Python, a dozen web pages, all reliant help pages, I finally got my answer from a mailing list. -Damian ---------------------------------------------------------------------- >Comment By: Damian (atagar) Date: 2007-06-30 14:48 Message: Logged In: YES user_id=1613266 Originator: YES No, I'm talking about the documentation when entering help(file) or help(open). The filename parameter works in a cross platform fashion when given a Unix path. For instance, file = open("/path/to/content.xml", "r") # Cross platform file = open("\\path\\to\\content.xml", "r") # Win32 only This seemed to be an undocumented yet important detail (unless I'm mistaken it means its advantageous to always use the former method when coding paths). However, looking around some more I think this is largely a misunderstanding on my part in terms of where the cross platform capability came from (Windows accepting a forward slash rather than the open method translating the path for the current OS). Sorry about the confusion. ---------------------------------------------------------------------- Comment By: Damian (atagar) Date: 2007-06-30 14:38 Message: Logged In: YES user_id=1613266 Originator: YES No, I'm talking about the documentation when entering help(file) or help(open). The filename parameter works in a cross platform fashion when given a Unix path. For instance, file = open("/path/to/content.xml", "r") # Cross platform file = open("\\path\\to\\content.xml", "r") # Win32 only This seemed to be an undocumented yet important detail (unless I'm mistaken it means its advantageous to always use the former method when coding paths). However, looking around some more I think this is largely a misunderstanding on my part in terms of where the cross platform capability came from (Windows accepting a forward slash rather than the open method translating the path for the current OS). Sorry about the confusion. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-30 05:24 Message: Logged In: YES user_id=942711 Originator: NO I am not getting as what you are indicating Damian. You mean to say use '/' forward slashes in all documentation as they can work cross platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745533&group_id=5470