From noreply at sourceforge.net Sun Jul 1 10:34:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jul 2007 01:34:09 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-29 23:05 Message generated for change (Settings changed) made by loewis 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: Martin v. L?wis (loewis) Date: 2007-07-01 10:34 Message: Logged In: YES user_id=21627 Originator: NO I think that's what Damian says, but it's partially wrong. Python has not taken any specific effort to make / work on all systems; it just happens to work on Windows as well. However, it does so only in a limited manner: you still might need to specify drive letters, and you cannot easily pass a file name with forward slashes to an external program, as that may mistake the slashes as command line options. ---------------------------------------------------------------------- Comment By: Damian (atagar) Date: 2007-06-30 23: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 23: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 14: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 Sun Jul 1 11:05:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jul 2007 02:05:16 -0700 Subject: [ python-Bugs-1745533 ] Filename providing cross platform capability Message-ID: Bugs item #1745533, was opened at 2007-06-29 23:05 Message generated for change (Settings changed) made by loewis 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: Martin v. L?wis (loewis) Date: 2007-07-01 10:34 Message: Logged In: YES user_id=21627 Originator: NO I think that's what Damian says, but it's partially wrong. Python has not taken any specific effort to make / work on all systems; it just happens to work on Windows as well. However, it does so only in a limited manner: you still might need to specify drive letters, and you cannot easily pass a file name with forward slashes to an external program, as that may mistake the slashes as command line options. ---------------------------------------------------------------------- Comment By: Damian (atagar) Date: 2007-06-30 23: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 23: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 14: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 Sun Jul 1 16:49:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jul 2007 07:49:39 -0700 Subject: [ python-Bugs-1746071 ] class mutex doesn't do anything atomically Message-ID: Bugs item #1746071, was opened at 2007-07-01 10:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 From noreply at sourceforge.net Sun Jul 1 17:42:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jul 2007 08:42:45 -0700 Subject: [ python-Bugs-1746088 ] long.__str__ is quadratic time Message-ID: Bugs item #1746088, was opened at 2007-07-01 11: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=1746088&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: long.__str__ is quadratic time Initial Comment: In the 2.5.1 source code, Objects/longobject.c:long_format() is used to convert a long int to a string. When base is not a power of 2, it is quadratic time in the length of the output string. Of course, this is fine on small numbers, but is catastrophic on huge numbers. Suppose base is 10. The problem is that the algorithm basically does the following: take the number mod 10 to get a digit, stick that digit on the output, divide the number by 10, and repeat. To print an n digit number, there is an O(n log n) algorithm, using divide-and-conquer. You break the number into 2 pieces, each n/2 digits long, and iterate on both pieces. Converting string to long has the same quadratic time problem, in PyLong_FromString(). The solution is the same, in reverse: break the string in half, convert each piece to a long, and combine the two longs into one. Alternatively, Python could just use GMP (GNU MP Bignum Library, http://gmplib.org/) to provide long integers. That would make other operations, such as * and /, more efficient, too. But it would require a much bigger change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746088&group_id=5470 From noreply at sourceforge.net Mon Jul 2 05:10:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jul 2007 20:10:52 -0700 Subject: [ python-Bugs-1746071 ] class mutex doesn't do anything atomically Message-ID: Bugs item #1746071, was opened at 2007-07-01 20:19 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-02 08:40 Message: Logged In: YES user_id=942711 Originator: NO Hi David, I just fired up the docs and found this: "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks. It does not require (or imply) threading or multi-tasking, though it could be useful for those purposes." The docs dont say about threads using mutex object, but instead say if you want to use threading you can use mutex obj. How are you using mutex with threads, can you please provide some information. If muobj is an instance of mutex class. muobj.testandset() for process-a will set the lock. muobj.testandset() for process-b will be dealt with self.lock = True and wont be able to set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 From noreply at sourceforge.net Mon Jul 2 09:11:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 00:11:00 -0700 Subject: [ python-Bugs-1451466 ] reading very large files Message-ID: Bugs item #1451466, was opened at 2006-03-16 18:21 Message generated for change (Comment added) made by richardchristen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: christen (richardchristen) Assigned to: Nobody/Anonymous (nobody) Summary: reading very large files Initial Comment: I work on the human genome I extracted words from chromosomes using a suffix tree (C compiled for 64 done on a SUN with 300 Go RAM, since my suffix tree requires 150 Go RAM for chromosome 1, the largest one) this gave some >5 Go files, for example with 163763326 lines for chr 4, the one presently analyzed. Using python 2.4.2 on a windows 32-computer (1.5 Go RAM), reading this file line by line either for li in file: do something or while li!='': li=file.readline() I got problems seemingly around the 4 Go boundary (after reading the problematic first line), for some lines (not all), the li returned the correct content but with the first word of the next line also within li (see below) As a result a simple file1=open('1') file2=open('2','w') li=file1.readline() while li!='': file2.write(li) li=file1.readline() produced a second file of only 163754385 lines problem lines were "seemingly random", i.e. not in a row, with the last line being OK. The same code on the same file but on my OSX 64-dualcore machine went fine, despite the use of default Python 2.2.3 and "file Python" showing it is a Mach-0 executable ppc, i.e. a 32 bit app. Everything was run from the command line. the first file looks like that ... TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185 TCAGCCACAGCAGAAAGTGC:\t131324047 TCAGCCACAGCACTGTGTTA:\t61641912 .... the second file contains lines like these : TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA: which is 'first line'+'1rst word of next line' PS1 : no problem to read the big file with UEdit on the windows machine. Therefore the OS itself is not the problem (also I transfered the bigfile from the Windows to the Mac, if the file had had problems, it would have been corrupted on the Mac) PS2 : I tried python 2.3.5 on windows with the same problem. PS3: If needed, I can run the same test on a similar file but for chromosome 8 which is slightly below the 4 Go limit (3.99). PS4: I think I remember having done a similar parsing on a Linux Athlon 64 monoCPU a month ago, with no trouble. ---------------------------------------------------------------------- >Comment By: christen (richardchristen) Date: 2007-07-02 09:11 Message: Logged In: YES user_id=1477618 Originator: YES In 2006, I signaled a bug in windows 32 for reading very large files : python-Bugs-1451466 I have now tried with a windows 64 machines and python 2.5 I find the same bug For very large files (the two I tried were around 7-8 Go), the end of line is sometimes not taken into account The file is fine, as viewed in hexa, the end of line characters are perfectly ok at the place where the parser goes wrong. Everything seems to be ok with the same script on my Mac OSX Exemple : Original file reads: ########################### ......... Query= 10|ENSG00000203288|pseudogene|105829416|105829650|- 1|ENSE00001440927|105829519|105829650|-1|1 (132 letters) Database: Homo_sapiens.NCBI36.45.dna.chromosome17 1 sequences; 78,774,742 total letters ............... ########################### in hexa: ########################### ... c5bd3500h: 32 2E 0D 0A 0D 0A 51 75 65 72 79 3D 20 31 30 7C ; 2.....Query= 10| c5bd3510h: 45 4E 53 47 30 30 30 30 30 32 30 33 32 38 38 7C ; ENSG00000203288| c5bd3520h: 70 73 65 75 64 6F 67 65 6E 65 7C 31 30 35 38 32 ; pseudogene|10582 c5bd3530h: 39 34 31 36 7C 31 30 35 38 32 39 36 35 30 7C 2D ; 9416|105829650|- c5bd3540h: 0D 0A 31 7C 45 4E 53 45 30 30 30 30 31 34 34 30 ; ..1|ENSE00001440 c5bd3550h: 39 32 37 7C 31 30 35 38 32 39 35 31 39 7C 31 30 ; 927|105829519|10 c5bd3560h: 35 38 32 39 36 35 30 7C 2D 31 7C 31 0D 0A 20 20 ; 5829650|-1|1.. c5bd3570h: 20 20 20 20 20 20 20 28 31 33 32 20 6C 65 74 74 ; (132 lett c5bd3580h: 65 72 73 29 0D 0A 0D 0A 44 61 74 61 62 61 73 65 ; ers)....Database c5bd3590h: 3A 20 48 6F 6D 6F 5F 73 61 70 69 65 6E 73 2E 4E ; : Homo_sapiens.N c5bd35a0h: 43 42 49 33 36 2E 34 35 2E 64 6E 61 2E 63 68 72 ; CBI36.45.dna.chr c5bd35b0h: 6F 6D 6F 73 6F 6D 65 31 37 20 0D 0A 20 20 20 20 ; omosome17 .. c5bd35c0h: 20 20 20 20 20 20 20 31 20 73 65 71 75 65 6E 63 ; 1 sequenc c5bd35d0h: 65 73 3B 20 37 38 2C 37 37 34 2C 37 34 32 20 74 ; es; 78,774,742 t c5bd35e0h: 6F 74 61 6C 20 6C 65 74 74 65 72 73 0D 0A 0D 0A ; otal letters.... ... ####################################### Demo: python script : ############################# import os.path initial_dir=r'D:\human_exons\chr17' fichier=os.path.join(initial_dir, '10_17.out') fichin=open(fichier) ok=0 i=0 for li in fichin: i+=1 if li.startswith('Query= '): query=li elif li.startswith('1|ENSE00001440927|105829519|105829650|-1|1'): ok=1 if ok==1: print i print query print li fichin.close() ################################ output : 160968087 Query= 10|ENSG00000203288|pseudogene|105829416|105829650|- 1|ENSE00001440927|105829519|105829650|-1|1 (132 letters) 160968088 Query= 10|ENSG00000203288|pseudogene|105829416|105829650|- in fact line 160968087, should be 160981763 #################################### Computer Dell Precision PWS690 2 CPU dual core Intel Xeon 5160 @ 3.00GHz 2.99 GHz, 16.0 GB of RAM Microsoft Windows XP Professional x64 Edition Version 2003 Windows [Version 5.2.3790] ##################################### Richard Christen ---------------------------------------------------------------------- Comment By: christen (richardchristen) Date: 2006-03-18 08:29 Message: Logged In: YES user_id=1477618 In reply to previous comment Are you sure this is a text file? Yes I made it myself. Besides I transfered it from the UX machine to the windows one by ftp with change of the end of line character to the window's kind. I checked with type myfile, that the control character was indeed changed. Also, I mentioned that I manually checked with Uedit, both in ASCII and HEX modes for the akward lines. "windows 32-computer" is too vague." I agree, I should have been more specific: System: Microsoft Windows 2000 Professionnel Version 5.0.2195 Service Pack 4 version 2195 Mother card : ASUSTek System Model A7N8X-E BIOS Phoenix AwardBIOS v6-00PG Memory 1.5Go Swap 2.4 Go File System NTFS Best Regards ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-18 03:33 Message: Logged In: YES user_id=31435 "windows 32-computer" is too vague. Which operating system (Win95, Win98, WinME, NT, Win2K, WinXP), and which filesystem (FAT, FAT32, NTFS)? Are you sure this is a text file? If it's a binary file, then all sorts of bad things can happen opening it in text mode (which your sample code does). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-18 01:35 Message: Logged In: YES user_id=341410 Sounds like an issue with file objects on certain platforms not being able to handle offsets of 2**32 or larger. I personally have read and written files > 4gb on the windows platform, but I seem to recall having issues on 32 bit linux some time in the past. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470 From noreply at sourceforge.net Mon Jul 2 11:23:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 02:23:00 -0700 Subject: [ python-Bugs-1746071 ] class mutex doesn't do anything atomically Message-ID: Bugs item #1746071, was opened at 2007-07-01 10:49 Message generated for change (Comment added) made by dbenbenn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. ---------------------------------------------------------------------- >Comment By: David Benbennick (dbenbenn) Date: 2007-07-02 05:23 Message: Logged In: YES user_id=95581 Originator: YES > How are you using mutex with threads, can you please provide some information. I'm attaching an example program that demonstrates two threads both locking the same mutex at the same time. > If muobj is an instance of mutex class. > muobj.testandset() for process-a will set the lock. > muobj.testandset() for process-b will be dealt with self.lock = True and > wont be able to set. That isn't correct. It is possible for testandset to return True in both thread-a and thread-b. What can happen is the following: 1) Thread a calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 2) The OS switches threads. 3) Thread b calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 4) Thread b sets "self.locked = 1" and returns True 5) Thread a sets "self.locked = 1" and returns True File Added: ex.py ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-01 23:10 Message: Logged In: YES user_id=942711 Originator: NO Hi David, I just fired up the docs and found this: "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks. It does not require (or imply) threading or multi-tasking, though it could be useful for those purposes." The docs dont say about threads using mutex object, but instead say if you want to use threading you can use mutex obj. How are you using mutex with threads, can you please provide some information. If muobj is an instance of mutex class. muobj.testandset() for process-a will set the lock. muobj.testandset() for process-b will be dealt with self.lock = True and wont be able to set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 From noreply at sourceforge.net Tue Jul 3 01:39:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 16:39:32 -0700 Subject: [ python-Bugs-1706815 ] socket.error exceptions not subclass of StandardError Message-ID: Bugs item #1706815, was opened at 2007-04-24 11:09 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470 Please note that this message 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: Gregory P. Smith (greg) Summary: socket.error exceptions not subclass of StandardError Initial Comment: The "socket.error" exception is a subclass of Exception, but not of StandardError. It needs to be placed properly in the exception hierarchy, presumably somewhere under IOError. Socket errors have some known problems. See also: [ 805194 ] Inappropriate error received using socket timeout [ 1019808 ] wrong socket error returned [ 1571878 ] Improvements to socket module exceptions [ 708927 ] socket timeouts produce wrong errors in win32 Just figuring out what exceptions can be raised from the socket module is tough. I've seen exceptions derived from "socket.error", exceptions from IOError, and exceptions from the SSL layer, which patches the sockets module when loaded. These are non-bug exceptions; that is, the problem is out in the network, external to the program. Some are retryable, some indicate that a different approach (different port, different protocol) should be tried, and some mean that some named resource doesn't exist. Programs need to make those distinctions reliably. The most important distinction with sockets is "external network problem" vs. "local program program". To resolve this, I suggest a "NetworkException" in the exception hierarchy, with all the things that can go wrong due to conditions external to the local machine under that exception. I'd suggest the following: 1. Add "NetworkError" under "IOError" in the exception hierarchy. 2. Put the existing "socket.error" under "NetworkError". Since "socket.error" needs to be reparented anyway (it's currently a direct descendant of "Exception") this provides a good place for it. 3. Find any places where the socket module can raise IOError or OSError due to an external network condition, and make them raise something under NetworkError instead. Code that catches IOError will still work. 4. Put all errors in the various SSL modules (SSLError, etc.) which can be raised due to external network conditions under "NetworkError" 5. Move "urllib2.URLError", which is currently under IOError, down a level under NetworkError. 6. Move the misc. errors from "urllib", like "ContentTooShortError", which are currently under IOError, down a level under NetworkError. 7. URL translation errors from the IDNA (Unicode URL encoding) module probably should raise an error similar to that for an incorrect URL, rather than raising a UnicodeError. Then, programs that catch NetworkError could be sure of catching all network trouble conditions, but not local code bugs. With these changes, any exception that's being caught now will still be caught. I'd suggest doing 1) above immediately, since that's a clear bug, but the others need to be discussed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2007-07-02 16:39 Message: Logged In: YES user_id=413 Originator: NO agreed! the above suggestions sound good. for number (3) if there are any places that raise OSError, that could lead to code upgrade headaches as the new NetworkError would not be a subclass of OSError. imho thats fine but others may disagree. i am looking at implementing the immediate (1) and (2) as a starting point. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2007-04-24 11:12 Message: Logged In: YES user_id=5571 Originator: YES (See also PEP 352). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470 From noreply at sourceforge.net Tue Jul 3 04:02:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 19:02:31 -0700 Subject: [ python-Bugs-1746880 ] AMD64 installer does not place python25.dll in system dir Message-ID: Bugs item #1746880, was opened at 2007-07-02 21:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: AMD64 installer does not place python25.dll in system dir Initial Comment: Even with All Users selected, the 2.5.1 AMD64 msi installer puts python25.dll in the base python directory. Attaching install log. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 From noreply at sourceforge.net Tue Jul 3 04:17:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 19:17:53 -0700 Subject: [ python-Bugs-1746880 ] AMD64 installer does not place python25.dll in system dir Message-ID: Bugs item #1746880, was opened at 2007-07-02 21:02 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: AMD64 installer does not place python25.dll in system dir Initial Comment: Even with All Users selected, the 2.5.1 AMD64 msi installer puts python25.dll in the base python directory. Attaching install log. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2007-07-02 21:17 Message: Logged In: YES user_id=771074 Originator: YES This looks like a simple typo in msi.py: if msilib.Win64: SystemFolderName = "[SystemFolder64]" It should be System64Folder instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 From noreply at sourceforge.net Tue Jul 3 04:49:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 19:49:39 -0700 Subject: [ python-Bugs-1746880 ] AMD64 installer does not place python25.dll in system dir Message-ID: Bugs item #1746880, was opened at 2007-07-03 11:02 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) >Assigned to: Martin v. L?wis (loewis) Summary: AMD64 installer does not place python25.dll in system dir Initial Comment: Even with All Users selected, the 2.5.1 AMD64 msi installer puts python25.dll in the base python directory. Attaching install log. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2007-07-03 11:49 Message: Logged In: YES user_id=671362 Originator: NO Martin, can you take a look? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-07-03 11:17 Message: Logged In: YES user_id=771074 Originator: YES This looks like a simple typo in msi.py: if msilib.Win64: SystemFolderName = "[SystemFolder64]" It should be System64Folder instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 From noreply at sourceforge.net Tue Jul 3 07:49:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 22:49:45 -0700 Subject: [ python-Bugs-1746880 ] AMD64 installer does not place python25.dll in system dir Message-ID: Bugs item #1746880, was opened at 2007-07-03 04:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Martin v. L?wis (loewis) Summary: AMD64 installer does not place python25.dll in system dir Initial Comment: Even with All Users selected, the 2.5.1 AMD64 msi installer puts python25.dll in the base python directory. Attaching install log. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-07-03 07:49 Message: Logged In: YES user_id=21627 Originator: NO Will do. Most likely, rupole is right with his analysis. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2007-07-03 04:49 Message: Logged In: YES user_id=671362 Originator: NO Martin, can you take a look? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-07-03 04:17 Message: Logged In: YES user_id=771074 Originator: YES This looks like a simple typo in msi.py: if msilib.Win64: SystemFolderName = "[SystemFolder64]" It should be System64Folder instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746880&group_id=5470 From noreply at sourceforge.net Tue Jul 3 08:21:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jul 2007 23:21:27 -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-28 17:13 Message generated for change (Comment added) made by nnorwitz 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. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-02 23:21 Message: Logged In: YES user_id=33168 Originator: NO No python developer has access to AIX AFAIK. So you will likely need to debug this problem yourself or provide access to an AIX box. Here are some questions to get you started: * Does this problem happen as a 32-bit exe rather than 64-bit? * Did you use xlc, gcc, or some other compiler? * What happens if you switch compilers? * Does this happen if you disable optimization? * What happens if you build a debug version of python (./configure --with-pydebug)? * Do you have any memory debugging tool that you can use to track this down? It looks like there is a problem derefencing a function pointer. I don't know why that might happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745108&group_id=5470 From noreply at sourceforge.net Tue Jul 3 10:12:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 01:12:49 -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 (Comment added) made by maswan 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. ---------------------------------------------------------------------- >Comment By: Mattias Wadenstein (maswan) Date: 2007-07-03 08:12 Message: Logged In: YES user_id=1831392 Originator: YES We'll look into the issue of temporarily giving someone access, but it is somewhat problematic. Some answers until then: * Same behaviour on both 32-bit and 64-bit * Compiled with xlc v8.0 * I will try and set gcc up * Same behaviour with or without optimization, debug flags, etc (just slightly different backtraces, less verbose without debug symbols) * Same thing --with-pydebug or without, just slightly different output * I'll look, but nothing comes to mind right now ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-03 06:21 Message: Logged In: YES user_id=33168 Originator: NO No python developer has access to AIX AFAIK. So you will likely need to debug this problem yourself or provide access to an AIX box. Here are some questions to get you started: * Does this problem happen as a 32-bit exe rather than 64-bit? * Did you use xlc, gcc, or some other compiler? * What happens if you switch compilers? * Does this happen if you disable optimization? * What happens if you build a debug version of python (./configure --with-pydebug)? * Do you have any memory debugging tool that you can use to track this down? It looks like there is a problem derefencing a function pointer. I don't know why that might happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1745108&group_id=5470 From noreply at sourceforge.net Tue Jul 3 16:22:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 07:22:31 -0700 Subject: [ python-Bugs-1746088 ] long.__str__ is quadratic time Message-ID: Bugs item #1746088, was opened at 2007-07-01 15:42 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746088&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: long.__str__ is quadratic time Initial Comment: In the 2.5.1 source code, Objects/longobject.c:long_format() is used to convert a long int to a string. When base is not a power of 2, it is quadratic time in the length of the output string. Of course, this is fine on small numbers, but is catastrophic on huge numbers. Suppose base is 10. The problem is that the algorithm basically does the following: take the number mod 10 to get a digit, stick that digit on the output, divide the number by 10, and repeat. To print an n digit number, there is an O(n log n) algorithm, using divide-and-conquer. You break the number into 2 pieces, each n/2 digits long, and iterate on both pieces. Converting string to long has the same quadratic time problem, in PyLong_FromString(). The solution is the same, in reverse: break the string in half, convert each piece to a long, and combine the two longs into one. Alternatively, Python could just use GMP (GNU MP Bignum Library, http://gmplib.org/) to provide long integers. That would make other operations, such as * and /, more efficient, too. But it would require a much bigger change. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-07-03 14:22 Message: Logged In: YES user_id=703403 Originator: NO I'd call this a feature request rather than a bug. If I understand correctly, an O(n^(1+epsilon)) printing algorithm would rely on having an FFT-based fast multiplication algorithm, together with some form of divide-and-conquer division---is this right? These algorithms are nontrivial to implement efficiently, and even then the crossover point (where the FFT-based method becomes faster than the quadratic method) is likely to be in the thousands of digits. So I can't imagine there's much demand for this---even a 4096-bit RSA key is only 1233 (or 1234) digits long. If you just want subquadratic printing (O(n^1.585) or so) then you'd still need a subquadratic division (Python already has Karatsuba multiplication for large integers); here I guess the crossover would be smaller. A subquadratic division for Python might well be of interest to the developers, if someone could be persuaded to write and test one, and demonstrate a significant positive impact on performance. What's your use-case for printing huge integers fast? It doesn't seem like a very common need. Regarding GMP, I believe there are licensing issues: it's not legal to include GMP in core Python and release Python under its current non-GPL license, or something like that---I don't know anything about the details. But have you encountered Martelli's gmpy? http://code.google.com/p/gmpy/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746088&group_id=5470 From noreply at sourceforge.net Tue Jul 3 20:23:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 11:23:52 -0700 Subject: [ python-Bugs-1746088 ] long.__str__ is quadratic time Message-ID: Bugs item #1746088, was opened at 2007-07-01 11:42 Message generated for change (Comment added) made by dbenbenn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746088&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: long.__str__ is quadratic time Initial Comment: In the 2.5.1 source code, Objects/longobject.c:long_format() is used to convert a long int to a string. When base is not a power of 2, it is quadratic time in the length of the output string. Of course, this is fine on small numbers, but is catastrophic on huge numbers. Suppose base is 10. The problem is that the algorithm basically does the following: take the number mod 10 to get a digit, stick that digit on the output, divide the number by 10, and repeat. To print an n digit number, there is an O(n log n) algorithm, using divide-and-conquer. You break the number into 2 pieces, each n/2 digits long, and iterate on both pieces. Converting string to long has the same quadratic time problem, in PyLong_FromString(). The solution is the same, in reverse: break the string in half, convert each piece to a long, and combine the two longs into one. Alternatively, Python could just use GMP (GNU MP Bignum Library, http://gmplib.org/) to provide long integers. That would make other operations, such as * and /, more efficient, too. But it would require a much bigger change. ---------------------------------------------------------------------- >Comment By: David Benbennick (dbenbenn) Date: 2007-07-03 14:23 Message: Logged In: YES user_id=95581 Originator: YES > rely on having an FFT-based fast multiplication algorithm, together with > some form of divide-and-conquer division---is this right? Yes, that's true: fast str() relies on fast division. I had assumed Python already had fast division; if it doesn't, I'd consider that a bug, too. > What's your use-case for printing huge integers fast? Note that it's not a question of printing them *fast*. With a quadratic time algorithm, it's infeasible to print huge numbers *at all*. My personal use case is doing computations in Thompson's group F; an element of F is a list of humongous fractions. But I expect it's a problem that often comes up in mathematical programming. I'll admit it isn't a very important bug, since anyone who is harmed by it will either use a different language, or use gmpy, or print in hex. But it's still a bug. > Regarding GMP, I believe there are licensing issues: it's not legal to > include GMP in core Python and release Python under its current non-GPL > license, or something like that---I don't know anything about the details. I don't see what the problem would be. Python's LICENSE file says that Python's license is GPL compatible. And in any case, GMP is LGPL, not GPL, so any program can link to it. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-07-03 10:22 Message: Logged In: YES user_id=703403 Originator: NO I'd call this a feature request rather than a bug. If I understand correctly, an O(n^(1+epsilon)) printing algorithm would rely on having an FFT-based fast multiplication algorithm, together with some form of divide-and-conquer division---is this right? These algorithms are nontrivial to implement efficiently, and even then the crossover point (where the FFT-based method becomes faster than the quadratic method) is likely to be in the thousands of digits. So I can't imagine there's much demand for this---even a 4096-bit RSA key is only 1233 (or 1234) digits long. If you just want subquadratic printing (O(n^1.585) or so) then you'd still need a subquadratic division (Python already has Karatsuba multiplication for large integers); here I guess the crossover would be smaller. A subquadratic division for Python might well be of interest to the developers, if someone could be persuaded to write and test one, and demonstrate a significant positive impact on performance. What's your use-case for printing huge integers fast? It doesn't seem like a very common need. Regarding GMP, I believe there are licensing issues: it's not legal to include GMP in core Python and release Python under its current non-GPL license, or something like that---I don't know anything about the details. But have you encountered Martelli's gmpy? http://code.google.com/p/gmpy/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746088&group_id=5470 From noreply at sourceforge.net Tue Jul 3 21:36:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 12:36:40 -0700 Subject: [ python-Bugs-1746071 ] class mutex doesn't do anything atomically Message-ID: Bugs item #1746071, was opened at 2007-07-01 20:19 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-04 01:06 Message: Logged In: YES user_id=942711 Originator: NO Thanks David, there is something 'interesting' being observed here. At a point: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Resetting, trying again Another place: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Thread 1 locked Hah, all these threads locked at the same time: [0, 1] My doubts are still with threading, but am unable to derive anything. Should someone more experienced look into? Or mind taking this for suggestions to c.l.p? ---------------------------------------------------------------------- Comment By: David Benbennick (dbenbenn) Date: 2007-07-02 14:53 Message: Logged In: YES user_id=95581 Originator: YES > How are you using mutex with threads, can you please provide some information. I'm attaching an example program that demonstrates two threads both locking the same mutex at the same time. > If muobj is an instance of mutex class. > muobj.testandset() for process-a will set the lock. > muobj.testandset() for process-b will be dealt with self.lock = True and > wont be able to set. That isn't correct. It is possible for testandset to return True in both thread-a and thread-b. What can happen is the following: 1) Thread a calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 2) The OS switches threads. 3) Thread b calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 4) Thread b sets "self.locked = 1" and returns True 5) Thread a sets "self.locked = 1" and returns True File Added: ex.py ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-02 08:40 Message: Logged In: YES user_id=942711 Originator: NO Hi David, I just fired up the docs and found this: "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks. It does not require (or imply) threading or multi-tasking, though it could be useful for those purposes." The docs dont say about threads using mutex object, but instead say if you want to use threading you can use mutex obj. How are you using mutex with threads, can you please provide some information. If muobj is an instance of mutex class. muobj.testandset() for process-a will set the lock. muobj.testandset() for process-b will be dealt with self.lock = True and wont be able to set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 From noreply at sourceforge.net Tue Jul 3 23:26:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 14:26:15 -0700 Subject: [ python-Bugs-1746071 ] class mutex doesn't do anything atomically Message-ID: Bugs item #1746071, was opened at 2007-07-01 10:49 Message generated for change (Comment added) made by dbenbenn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 Please note that this message 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: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. ---------------------------------------------------------------------- >Comment By: David Benbennick (dbenbenn) Date: 2007-07-03 17:26 Message: Logged In: YES user_id=95581 Originator: YES I've attached a patch to mutex.py that fixes the bug by acquiring a lock in testandset() and unlock(). After you apply the patch, the previous attachment will run forever. File Added: patch.txt ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-03 15:36 Message: Logged In: YES user_id=942711 Originator: NO Thanks David, there is something 'interesting' being observed here. At a point: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Resetting, trying again Another place: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Thread 1 locked Hah, all these threads locked at the same time: [0, 1] My doubts are still with threading, but am unable to derive anything. Should someone more experienced look into? Or mind taking this for suggestions to c.l.p? ---------------------------------------------------------------------- Comment By: David Benbennick (dbenbenn) Date: 2007-07-02 05:23 Message: Logged In: YES user_id=95581 Originator: YES > How are you using mutex with threads, can you please provide some information. I'm attaching an example program that demonstrates two threads both locking the same mutex at the same time. > If muobj is an instance of mutex class. > muobj.testandset() for process-a will set the lock. > muobj.testandset() for process-b will be dealt with self.lock = True and > wont be able to set. That isn't correct. It is possible for testandset to return True in both thread-a and thread-b. What can happen is the following: 1) Thread a calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 2) The OS switches threads. 3) Thread b calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 4) Thread b sets "self.locked = 1" and returns True 5) Thread a sets "self.locked = 1" and returns True File Added: ex.py ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-01 23:10 Message: Logged In: YES user_id=942711 Originator: NO Hi David, I just fired up the docs and found this: "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks. It does not require (or imply) threading or multi-tasking, though it could be useful for those purposes." The docs dont say about threads using mutex object, but instead say if you want to use threading you can use mutex obj. How are you using mutex with threads, can you please provide some information. If muobj is an instance of mutex class. muobj.testandset() for process-a will set the lock. muobj.testandset() for process-b will be dealt with self.lock = True and wont be able to set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&group_id=5470 From noreply at sourceforge.net Wed Jul 4 05:25:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 20:25:15 -0700 Subject: [ python-Bugs-1706815 ] socket.error exceptions not subclass of StandardError Message-ID: Bugs item #1706815, was opened at 2007-04-24 11:09 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470 Please note that this message 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: Gregory P. Smith (greg) Summary: socket.error exceptions not subclass of StandardError Initial Comment: The "socket.error" exception is a subclass of Exception, but not of StandardError. It needs to be placed properly in the exception hierarchy, presumably somewhere under IOError. Socket errors have some known problems. See also: [ 805194 ] Inappropriate error received using socket timeout [ 1019808 ] wrong socket error returned [ 1571878 ] Improvements to socket module exceptions [ 708927 ] socket timeouts produce wrong errors in win32 Just figuring out what exceptions can be raised from the socket module is tough. I've seen exceptions derived from "socket.error", exceptions from IOError, and exceptions from the SSL layer, which patches the sockets module when loaded. These are non-bug exceptions; that is, the problem is out in the network, external to the program. Some are retryable, some indicate that a different approach (different port, different protocol) should be tried, and some mean that some named resource doesn't exist. Programs need to make those distinctions reliably. The most important distinction with sockets is "external network problem" vs. "local program program". To resolve this, I suggest a "NetworkException" in the exception hierarchy, with all the things that can go wrong due to conditions external to the local machine under that exception. I'd suggest the following: 1. Add "NetworkError" under "IOError" in the exception hierarchy. 2. Put the existing "socket.error" under "NetworkError". Since "socket.error" needs to be reparented anyway (it's currently a direct descendant of "Exception") this provides a good place for it. 3. Find any places where the socket module can raise IOError or OSError due to an external network condition, and make them raise something under NetworkError instead. Code that catches IOError will still work. 4. Put all errors in the various SSL modules (SSLError, etc.) which can be raised due to external network conditions under "NetworkError" 5. Move "urllib2.URLError", which is currently under IOError, down a level under NetworkError. 6. Move the misc. errors from "urllib", like "ContentTooShortError", which are currently under IOError, down a level under NetworkError. 7. URL translation errors from the IDNA (Unicode URL encoding) module probably should raise an error similar to that for an incorrect URL, rather than raising a UnicodeError. Then, programs that catch NetworkError could be sure of catching all network trouble conditions, but not local code bugs. With these changes, any exception that's being caught now will still be caught. I'd suggest doing 1) above immediately, since that's a clear bug, but the others need to be discussed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2007-07-03 20:25 Message: Logged In: YES user_id=413 Originator: NO heres a patch against 2.6a0 svn HEAD implementing items 1 thru 6 (attached). I didn't look deeply to see if 4 is really implemented or not but the SSL errors were derived from socket.error so if they all use that as their base then they should be covered. test suites pass. File Added: python-bug-1706815.diff ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2007-07-02 16:39 Message: Logged In: YES user_id=413 Originator: NO agreed! the above suggestions sound good. for number (3) if there are any places that raise OSError, that could lead to code upgrade headaches as the new NetworkError would not be a subclass of OSError. imho thats fine but others may disagree. i am looking at implementing the immediate (1) and (2) as a starting point. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2007-04-24 11:12 Message: Logged In: YES user_id=5571 Originator: YES (See also PEP 352). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1706815&group_id=5470 From noreply at sourceforge.net Wed Jul 4 07:16:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jul 2007 22:16:00 -0700 Subject: [ python-Bugs-1744752 ] Newline skipped in "for line in file" Message-ID: Bugs item #1744752, was opened at 2007-06-28 04:23 Message generated for change (Comment added) made by nnorwitz 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 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-03 22:16 Message: Logged In: YES user_id=33168 Originator: NO Without a reproducible test case, there's really nothing we can do. You will need to debug this on your own. Try setting a breakpoint in the debugger in the file object, probably in get_line(). If you can make a self contained test case, then we can help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1744752&group_id=5470 From noreply at sourceforge.net Wed Jul 4 16:21:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 07:21:37 -0700 Subject: [ python-Bugs-1747858 ] chown broken on 64bit Message-ID: Bugs item #1747858, was opened at 2007-07-04 10:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 Please note that this message 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 D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: chown broken on 64bit Initial Comment: python-2.5 on fedora fc7 x86_64: os.stat returns uid > 32bit: os.stat ('shit') (33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517) os.chown doesn't like that: os.chown ('shit', 4294967294, 4294967294) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 From noreply at sourceforge.net Wed Jul 4 17:04:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 08:04:22 -0700 Subject: [ python-Bugs-1747858 ] chown broken on 64bit Message-ID: Bugs item #1747858, was opened at 2007-07-04 10:21 Message generated for change (Comment added) made by owsla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 Please note that this message 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 D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: chown broken on 64bit Initial Comment: python-2.5 on fedora fc7 x86_64: os.stat returns uid > 32bit: os.stat ('shit') (33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517) os.chown doesn't like that: os.chown ('shit', 4294967294, 4294967294) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-04 11:04 Message: Logged In: YES user_id=19094 Originator: NO Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which are mapped to 'unsigned int' on at least some Unix platforms (I haven't checked extensively.) The wrinkle here is that chown() needs to be able to handle the case of uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1, -1) is valid, but so is os.chown(4294967294, 4294967294). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 From noreply at sourceforge.net Wed Jul 4 21:53:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 12:53:11 -0700 Subject: [ python-Bugs-1748015 ] Module-level stack scopes have incorrect bindings. Message-ID: Bugs item #1748015, was opened at 2007-07-04 19: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=1748015&group_id=5470 Please note that this message 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: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Module-level stack scopes have incorrect bindings. Initial Comment: For a variable defined in a module scope, and stack frame object's locals and globals scope dictionaries each contain that variables name mapped to None. This confuses python code which inspects the bindings, such as pdb. Such code incorrectly reports the value as None. It may be that the binding values are correct at the time of exception generation, but altered by the time the exception traceback is caught. This problem may also be related to module imports. Here's are two simple examples, the first does not trigger this problem, the second does. Both use this module called "buggy.py": # Begin buggy.py whatKnightsSay = 'Ni!' print 'We are the Knights who say: %r' % (whatKnightsSay,) 42 + whatKnightsSay # End buggy.py # Begin a non-failing example: $ pdb buggy.py > /home/n/sandbox/python-module-binding-bug-src/buggy.py(1)() -> whatKnightsSay = 'Ni!' (Pdb) print whatKnightsSay *** NameError: name 'whatKnightsSay' is not defined (Pdb) next > /home/n/sandbox/python-module-binding-bug-src/buggy.py(2)() -> print 'We are the Knights who say: %r' % (whatKnightsSay,) (Pdb) print whatKnightsSay Ni! (Pdb) next We are the Knights who say: 'Ni!' > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next --Return-- > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)()->None -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > (1)()->None (Pdb) print whatKnightsSay Ni! # End succeeding example. And here's a simple failing example, which relies on a second module: # Begin triggerPdb.py import pdb pdb.set_trace() import buggy # End triggerPdb.py Now pdb get's confused about the module level binding: # Begin failure example: $ python triggerPdb.py > /home/n/sandbox/python-module-binding-bug-src/triggerPdb.py(3)() -> import buggy (Pdb) next We are the Knights who say: 'Ni!' TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > /home/n/sandbox/python-module-binding-bug-src/triggerPdb.py(3)() -> import buggy (Pdb) down > /home/n/sandbox/python-module-binding-bug/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) list 1 whatKnightsSay = 'Ni!' 2 print 'We are the Knights who say: %r' % (whatKnightsSay,) 3 -> 42 + whatKnightsSay [EOF] (Pdb) p whatKnightsSay None # End failing example. I've included these two simple sources, as well as another that does traceback inspection in an except clause (which fails like the second example here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748015&group_id=5470 From noreply at sourceforge.net Wed Jul 4 22:01:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 13:01:26 -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 20:02 Message generated for change (Comment added) made by theller 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: Thomas Heller (theller) Date: 2007-07-04 22:01 Message: Logged In: YES user_id=11105 Originator: NO Skip, thanks for the analysis and test patch. IMO loading the GLUT library does not add significant value to the ctypes tests, so wouldn't it be best to skip the GLUT lib on OSX? See the attached patch "test_find without GLUT on OSX" (note that I didn't actually test the patch, and I don't have access to OSX G5 anyway). Maybe the problem and the analysis should be reported to the PyOpenGL project... File Added: test_find-no-osx-glut.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 15: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 13: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 12: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-30 05: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 05: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 04: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 04: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-30 01: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 21: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 22: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 16: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 21: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 18: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 20: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 Wed Jul 4 23:22:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 14:22:07 -0700 Subject: [ python-Bugs-1748064 ] inspect.getargspec fails on built-in or slot wrapper methods Message-ID: Bugs item #1748064, was opened at 2007-07-04 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748064&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael A. Hawker (hawkerm) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec fails on built-in or slot wrapper methods Initial Comment: Hi, I'm new here, but I'm running into a little trouble with complex introspection techniques. I'm using Windows XP SP2 on an AMD64 chip. Tying to do some introspection on base types provides little information about the function as getargspec will not accept the slot wrapper or a built-in function as an argument (see attached interpreter trace). i.e. when trying to analyze functions such as list.remove, list.__getitem__, len, etc... This seems like abnormal behavior as it seems contrary as these are methods and functions, and the help function (while only providing the doc string) still provides information about the function, only in a different harder to parse format. Do I need to make a stronger argument? It would be very useful for the work I'm doing. Attached is a trace of various scenarios involving this issue and how it seems contrary to the expected behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748064&group_id=5470 From noreply at sourceforge.net Thu Jul 5 03:31:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jul 2007 18:31:13 -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-07-04 20:31 Message: Logged In: YES user_id=44345 Originator: YES Certainly the patch is simpler. ;-) If loading GLUT doesn't add any value on OSX, would it add any value on other platforms? Do other tests have to find libraries successfully to pass? If so, maybe test_find should be dispensed with altogether, however if test_find has value we should figure out a library to load on OSX. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-07-04 15:01 Message: Logged In: YES user_id=11105 Originator: NO Skip, thanks for the analysis and test patch. IMO loading the GLUT library does not add significant value to the ctypes tests, so wouldn't it be best to skip the GLUT lib on OSX? See the attached patch "test_find without GLUT on OSX" (note that I didn't actually test the patch, and I don't have access to OSX G5 anyway). Maybe the problem and the analysis should be reported to the PyOpenGL project... File Added: test_find-no-osx-glut.diff ---------------------------------------------------------------------- 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 Thu Jul 5 12:10:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jul 2007 03:10:38 -0700 Subject: [ python-Bugs-1748292 ] str.join() intercepts UnicodeDecodeError raised by iterator Message-ID: Bugs item #1748292, was opened at 2007-07-05 12: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=1748292&group_id=5470 Please note that this 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: Christoph Zwerschke (cito) Assigned to: M.-A. Lemburg (lemburg) Summary: str.join() intercepts UnicodeDecodeError raised by iterator Initial Comment: This is somewhat similar to #905389 which has already been fixed. If you run the following two lines, def gen(): raise UnicodeDecodeError ''.join(gen()) then instead of UnicodeDecodeError, you get: TypeError: function takes exactly 5 arguments (0 given) I found this bug in Python 2.3.5, 2.4.4 and 2.5.1 on Windows and Linux. The bug appears exactly for UnicodeDecodeError, UnicodeEncodeError, UnicodeTranslateError; all other exceptions work as expected. You can verify this with the following program: import exceptions def gen(e): raise e for e in dir(exceptions): e = getattr(exceptions, e) if type(e) != type(Exception): continue try: ''.join(gen(e)) except BaseException, f: e = e.__name__ f = f.__class__.__name__ if e != f: print e, f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 From noreply at sourceforge.net Thu Jul 5 13:07:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jul 2007 04:07:43 -0700 Subject: [ python-Bugs-1748292 ] str.join() intercepts UnicodeDecodeError raised by iterator Message-ID: Bugs item #1748292, was opened at 2007-07-05 12:10 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 Please note that this 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: Christoph Zwerschke (cito) Assigned to: M.-A. Lemburg (lemburg) Summary: str.join() intercepts UnicodeDecodeError raised by iterator Initial Comment: This is somewhat similar to #905389 which has already been fixed. If you run the following two lines, def gen(): raise UnicodeDecodeError ''.join(gen()) then instead of UnicodeDecodeError, you get: TypeError: function takes exactly 5 arguments (0 given) I found this bug in Python 2.3.5, 2.4.4 and 2.5.1 on Windows and Linux. The bug appears exactly for UnicodeDecodeError, UnicodeEncodeError, UnicodeTranslateError; all other exceptions work as expected. You can verify this with the following program: import exceptions def gen(e): raise e for e in dir(exceptions): e = getattr(exceptions, e) if type(e) != type(Exception): continue try: ''.join(gen(e)) except BaseException, f: e = e.__name__ f = f.__class__.__name__ if e != f: print e, f ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-07-05 13:07 Message: Logged In: YES user_id=89016 Originator: NO This has nothing to do with str.join(). The following script raises the same exception: def gen(): raise UnicodeDecodeError() gen() The problem is exactly what the exception message states: the UnicodeDecodeError constructor expects five arguments. The following version raises the expected UnicodeDecodeError: def gen(): raise UnicodeDecodeError('ascii', 'bytes', 0, 1, 'ouch') gen() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 From noreply at sourceforge.net Thu Jul 5 14:26:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jul 2007 05:26:57 -0700 Subject: [ python-Bugs-1748292 ] str.join() intercepts UnicodeDecodeError raised by iterator Message-ID: Bugs item #1748292, was opened at 2007-07-05 12:10 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: M.-A. Lemburg (lemburg) Summary: str.join() intercepts UnicodeDecodeError raised by iterator Initial Comment: This is somewhat similar to #905389 which has already been fixed. If you run the following two lines, def gen(): raise UnicodeDecodeError ''.join(gen()) then instead of UnicodeDecodeError, you get: TypeError: function takes exactly 5 arguments (0 given) I found this bug in Python 2.3.5, 2.4.4 and 2.5.1 on Windows and Linux. The bug appears exactly for UnicodeDecodeError, UnicodeEncodeError, UnicodeTranslateError; all other exceptions work as expected. You can verify this with the following program: import exceptions def gen(e): raise e for e in dir(exceptions): e = getattr(exceptions, e) if type(e) != type(Exception): continue try: ''.join(gen(e)) except BaseException, f: e = e.__name__ f = f.__class__.__name__ if e != f: print e, f ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-07-05 13:07 Message: Logged In: YES user_id=89016 Originator: NO This has nothing to do with str.join(). The following script raises the same exception: def gen(): raise UnicodeDecodeError() gen() The problem is exactly what the exception message states: the UnicodeDecodeError constructor expects five arguments. The following version raises the expected UnicodeDecodeError: def gen(): raise UnicodeDecodeError('ascii', 'bytes', 0, 1, 'ouch') gen() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 From noreply at sourceforge.net Thu Jul 5 15:11:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jul 2007 06:11:17 -0700 Subject: [ python-Bugs-1748292 ] str.join() intercepts UnicodeDecodeError raised by iterator Message-ID: Bugs item #1748292, was opened at 2007-07-05 12:10 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: M.-A. Lemburg (lemburg) Summary: str.join() intercepts UnicodeDecodeError raised by iterator Initial Comment: This is somewhat similar to #905389 which has already been fixed. If you run the following two lines, def gen(): raise UnicodeDecodeError ''.join(gen()) then instead of UnicodeDecodeError, you get: TypeError: function takes exactly 5 arguments (0 given) I found this bug in Python 2.3.5, 2.4.4 and 2.5.1 on Windows and Linux. The bug appears exactly for UnicodeDecodeError, UnicodeEncodeError, UnicodeTranslateError; all other exceptions work as expected. You can verify this with the following program: import exceptions def gen(e): raise e for e in dir(exceptions): e = getattr(exceptions, e) if type(e) != type(Exception): continue try: ''.join(gen(e)) except BaseException, f: e = e.__name__ f = f.__class__.__name__ if e != f: print e, f ---------------------------------------------------------------------- >Comment By: Christoph Zwerschke (cito) Date: 2007-07-05 15:11 Message: Logged In: YES user_id=193957 Originator: YES Thanks for the quick analysis. You're completely right, it has nothing to do with ''.join(). You get the same error if you simply raise UnicodeDecodeError which I think is a bit confusing nevertheless. I had naively assumed that you can instantiate every Exception with no or a single string argument only, so I did not consider this could be the cause. Sorry. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-07-05 13:07 Message: Logged In: YES user_id=89016 Originator: NO This has nothing to do with str.join(). The following script raises the same exception: def gen(): raise UnicodeDecodeError() gen() The problem is exactly what the exception message states: the UnicodeDecodeError constructor expects five arguments. The following version raises the expected UnicodeDecodeError: def gen(): raise UnicodeDecodeError('ascii', 'bytes', 0, 1, 'ouch') gen() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748292&group_id=5470 From noreply at sourceforge.net Fri Jul 6 00:07:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jul 2007 15:07:47 -0700 Subject: [ python-Bugs-1733943 ] Tkinter is not working on trunk (2.6) Message-ID: Bugs item #1733943, was opened at 2007-06-09 00:35 Message generated for change (Comment added) made by kbk 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: Closed >Resolution: Fixed >Priority: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) >Assigned to: Kurt B. Kaiser (kbk) 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: Kurt B. Kaiser (kbk) Date: 2007-07-05 18:07 Message: Logged In: YES user_id=149084 Originator: NO Fixed at rev 56176. Ref Patch 1496952. Issue was arglists containing a single tuple which were unpacked differently using the METH_OLDARG flag compared to the METH_VARARGS flag now used. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-09 03: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 Fri Jul 6 15:27:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jul 2007 06:27:16 -0700 Subject: [ python-Feature Requests-735515 ] urllib / urllib2 should cache 301 redirections Message-ID: Feature Requests item #735515, was opened at 2003-05-10 05:51 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=735515&group_id=5470 Please note that this message 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 J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib / urllib2 should cache 301 redirections Initial Comment: urllib / urllib2 should cache the results of 301 (permanent) redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC (2616, section 10.3.2, first para) says SHOULD happen. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-06 18:57 Message: Logged In: YES user_id=942711 Originator: NO Hi gbrandll/jjlee, I am trying to understand the actual requirements here. Should the original url be avaiable to the user upon request as urllib automatically calls the redirect_request and provides the redirected url only? Please provide some details on this bug. I shall try to write a patch. Thanks, Senthil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=735515&group_id=5470 From noreply at sourceforge.net Sat Jul 7 09:52:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 00:52:45 -0700 Subject: [ python-Bugs-1749512 ] imaplib cannot handle mailboxes with ACL: lrs Message-ID: Bugs item #1749512, was opened at 2007-07-07 09: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=1749512&group_id=5470 Please note that this 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: Florian Friesdorf (chaoflow) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib cannot handle mailboxes with ACL: lrs Initial Comment: The imaplib in python 2.4 and 2.5 is not able to handle a mailbox with ACL set to lrs correctly, as it treats it the same as a mailbox opened with EXAMINE. A mailbox with lrs can save \Seen flags, a mailbox opened with EXAMINE cannot. The attached patch is giving a proposal on how to fix it. The current select raises an exception, in case the server tells READ-ONLY in a response. However, for lrs this is the case, but nevertheless, it is possible to save per-use state information. With the patch this is not the case anymore. A readonly exception is only raised in case of an lr mailbox, as that is an equivalent to a mailbox opened with EXAMINE, i.e. select(..., readonly=True). A READ-ONLY in the response to a select is saved in self.is_readonly. Programs who relied on an exception being raised during select, would now need to query that variable. In case the state was not READ-ONLY during select, but becomes at some later point during command execution, still a readonly exception is raised. The patched imaplib was tested successfully with a slightly adapted offlineimap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749512&group_id=5470 From noreply at sourceforge.net Sat Jul 7 13:34:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 04:34:23 -0700 Subject: [ python-Bugs-1749567 ] PLATFORM macro in PC/pyconfig.h already defined by Apache Message-ID: Bugs item #1749567, was opened at 2007-07-07 14:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749567&group_id=5470 Please note that this message 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PLATFORM macro in PC/pyconfig.h already defined by Apache Initial Comment: Both pyconfig.h from Python and os.h from Apache define the PLATFORM macro ("win32" vs. "Win32"). For projects which include both (like mod_wsgi) this generates a level 1 warning in Visual Studio. Maybe the PLATFORM define could be renamed to PY_PLATFORM? There are a few other macros which could potentially collide with other libraries like COMPILER. Obviously this problem is shared by Python and Apache. I'm not implying that Python is the one which should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749567&group_id=5470 From noreply at sourceforge.net Sat Jul 7 13:35:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 04:35:40 -0700 Subject: [ python-Bugs-1749567 ] PLATFORM macro in PC/pyconfig.h already defined by Apache Message-ID: Bugs item #1749567, was opened at 2007-07-07 14:34 Message generated for change (Settings changed) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749567&group_id=5470 Please note that this message 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: 3 Private: No Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PLATFORM macro in PC/pyconfig.h already defined by Apache Initial Comment: Both pyconfig.h from Python and os.h from Apache define the PLATFORM macro ("win32" vs. "Win32"). For projects which include both (like mod_wsgi) this generates a level 1 warning in Visual Studio. Maybe the PLATFORM define could be renamed to PY_PLATFORM? There are a few other macros which could potentially collide with other libraries like COMPILER. Obviously this problem is shared by Python and Apache. I'm not implying that Python is the one which should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749567&group_id=5470 From noreply at sourceforge.net Sat Jul 7 14:44:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 05:44:10 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 08: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=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sat Jul 7 21:08:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 12:08:51 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 05:44 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:08 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sat Jul 7 21:10:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 12:10:06 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 05:44 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:08 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sat Jul 7 21:10:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 12:10:49 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 05:44 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:08 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sat Jul 7 21:11:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 12:11:37 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 05:44 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:11 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 12:08 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sat Jul 7 22:00:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jul 2007 13:00:07 -0700 Subject: [ python-Bugs-1749583 ] expanduser("~") on Windows looks for HOME first Message-ID: Bugs item #1749583, was opened at 2007-07-07 08:44 Message generated for change (Comment added) made by eldiener You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 Please note that this message 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: Edward Diener (eldiener) Assigned to: Nobody/Anonymous (nobody) Summary: expanduser("~") on Windows looks for HOME first Initial Comment: On Windows, using expanduser("~") the home directory is replaced either first by the environment variable HOME or, if that is not found, by a combination of HOMEDRIVE and HOMEPATH." But HOME is almost never the home directory for Windows, although it is under Linux/Unix, only the combination of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is installed under Windows, where HOME must be set to the MSYS home directory for a given user in order to emulate Linux/Unix, attempting to use os.path.expanduser("~") will incorrectly return the MSYS home directory for a given user rather than the Windows home directory for the logged in user. So I think the os.path.expanduser("~") works incorrectly in this case and needs to be fixed, else you are telling users never to use MSYS under Windows. There may be other Linux/Unix emulation packages which can be installed under Windows, and my guess is that if there is then the HOME environment variable gets set to some user home directory under that emulation package, just like it does for MSYS. The correct order under Windows is to look for the environment variable combination HOMEDRIVE/HOMEPATH first and only if that is not found ( very unlikely ) should expanduser("~") look for the environment variable HOME. ---------------------------------------------------------------------- >Comment By: Edward Diener (eldiener) Date: 2007-07-07 16:00 Message: Logged In: YES user_id=490593 Originator: YES Let me just correct my original report to say that the fix should be HOMEDRIVE+HOMEPATH, which is probably already known. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 15:11 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 15:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 15:10 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2007-07-07 15:08 Message: Logged In: YES user_id=1185570 Originator: NO This has been fixed as of Rev 54419 in trunk, perhaps someone would be kind enough to backport it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1749583&group_id=5470 From noreply at sourceforge.net Sun Jul 8 12:29:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 03:29:10 -0700 Subject: [ python-Bugs-1747858 ] chown broken on 64bit Message-ID: Bugs item #1747858, was opened at 2007-07-04 16:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 Please note that this message 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 D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: chown broken on 64bit Initial Comment: python-2.5 on fedora fc7 x86_64: os.stat returns uid > 32bit: os.stat ('shit') (33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517) os.chown doesn't like that: os.chown ('shit', 4294967294, 4294967294) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-07-08 12:29 Message: Logged In: YES user_id=21627 Originator: NO Notice that the value really is -2. It's important to find out how uid_t is defined on the platform; it may be that the return value of stat is already incorrect. Merely changing the variables to uid_t and gid_t is not enough, since then ParseTuple would stop working correctly. Is anybody interested in providing a patch? ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-04 17:04 Message: Logged In: YES user_id=19094 Originator: NO Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which are mapped to 'unsigned int' on at least some Unix platforms (I haven't checked extensively.) The wrinkle here is that chown() needs to be able to handle the case of uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1, -1) is valid, but so is os.chown(4294967294, 4294967294). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 From noreply at sourceforge.net Sun Jul 8 15:51:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 06:51:00 -0700 Subject: [ python-Bugs-1747858 ] chown broken on 64bit Message-ID: Bugs item #1747858, was opened at 2007-07-04 10:21 Message generated for change (Comment added) made by owsla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 Please note that this message 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 D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: chown broken on 64bit Initial Comment: python-2.5 on fedora fc7 x86_64: os.stat returns uid > 32bit: os.stat ('shit') (33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517) os.chown doesn't like that: os.chown ('shit', 4294967294, 4294967294) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-08 09:51 Message: Logged In: YES user_id=19094 Originator: NO No, the return value of stat is correct. For that it does: PyInt_FromLong((long)st->st_uid) in _pystat_fromstructstat(STRUCT_STAT *st) (same file, posixmodule.c). Fedora has been defining the UID of the nfsnobody user on 32-bit to be 65534 (USHRT_MAX - 1) and on 64-bit to be 4294967294 (UINT_MAX - 1), assuming 32-bit ints. So, yes, this absurdly high UID is real. So that chown('foo', -1, -1) makes sense, the UID that would be "(uid_t) -1" is reserved. That's why Fedora went for "(uid_t) -2". I think a patch should look something like: $ diff -p posixmodule.c.orig posixmodule.c *** posixmodule.c.orig Sun Jul 8 09:43:50 2007 --- posixmodule.c Sun Jul 8 09:48:27 2007 *************** static PyObject * *** 1826,1834 **** posix_chown(PyObject *self, PyObject *args) { char *path = NULL; ! int uid, gid; int res; ! if (!PyArg_ParseTuple(args, "etii:chown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) return NULL; --- 1826,1834 ---- posix_chown(PyObject *self, PyObject *args) { char *path = NULL; ! unsigned int uid, gid; int res; ! if (!PyArg_ParseTuple(args, "etII:chown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) return NULL; ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-07-08 06:29 Message: Logged In: YES user_id=21627 Originator: NO Notice that the value really is -2. It's important to find out how uid_t is defined on the platform; it may be that the return value of stat is already incorrect. Merely changing the variables to uid_t and gid_t is not enough, since then ParseTuple would stop working correctly. Is anybody interested in providing a patch? ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-04 11:04 Message: Logged In: YES user_id=19094 Originator: NO Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which are mapped to 'unsigned int' on at least some Unix platforms (I haven't checked extensively.) The wrinkle here is that chown() needs to be able to handle the case of uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1, -1) is valid, but so is os.chown(4294967294, 4294967294). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 From noreply at sourceforge.net Sun Jul 8 15:58:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 06:58:58 -0700 Subject: [ python-Bugs-1747858 ] chown broken on 64bit Message-ID: Bugs item #1747858, was opened at 2007-07-04 10:21 Message generated for change (Comment added) made by owsla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 Please note that this message 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 D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: chown broken on 64bit Initial Comment: python-2.5 on fedora fc7 x86_64: os.stat returns uid > 32bit: os.stat ('shit') (33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507, 1183558517) os.chown doesn't like that: os.chown ('shit', 4294967294, 4294967294) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-08 09:58 Message: Logged In: YES user_id=19094 Originator: NO Reformatted sample patch: --- posixmodule.c.orig 2007-07-08 09:43:50.000000000 -0400 +++ posixmodule.c 2007-07-08 09:48:27.000000000 -0400 @@ -1826,9 +1826,9 @@ posix_chown(PyObject *self, PyObject *args) { char *path = NULL; - int uid, gid; + unsigned int uid, gid; int res; - if (!PyArg_ParseTuple(args, "etii:chown", + if (!PyArg_ParseTuple(args, "etII:chown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) return NULL; ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-08 09:51 Message: Logged In: YES user_id=19094 Originator: NO No, the return value of stat is correct. For that it does: PyInt_FromLong((long)st->st_uid) in _pystat_fromstructstat(STRUCT_STAT *st) (same file, posixmodule.c). Fedora has been defining the UID of the nfsnobody user on 32-bit to be 65534 (USHRT_MAX - 1) and on 64-bit to be 4294967294 (UINT_MAX - 1), assuming 32-bit ints. So, yes, this absurdly high UID is real. So that chown('foo', -1, -1) makes sense, the UID that would be "(uid_t) -1" is reserved. That's why Fedora went for "(uid_t) -2". I think a patch should look something like: $ diff -p posixmodule.c.orig posixmodule.c *** posixmodule.c.orig Sun Jul 8 09:43:50 2007 --- posixmodule.c Sun Jul 8 09:48:27 2007 *************** static PyObject * *** 1826,1834 **** posix_chown(PyObject *self, PyObject *args) { char *path = NULL; ! int uid, gid; int res; ! if (!PyArg_ParseTuple(args, "etii:chown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) return NULL; --- 1826,1834 ---- posix_chown(PyObject *self, PyObject *args) { char *path = NULL; ! unsigned int uid, gid; int res; ! if (!PyArg_ParseTuple(args, "etII:chown", Py_FileSystemDefaultEncoding, &path, &uid, &gid)) return NULL; ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-07-08 06:29 Message: Logged In: YES user_id=21627 Originator: NO Notice that the value really is -2. It's important to find out how uid_t is defined on the platform; it may be that the return value of stat is already incorrect. Merely changing the variables to uid_t and gid_t is not enough, since then ParseTuple would stop working correctly. Is anybody interested in providing a patch? ---------------------------------------------------------------------- Comment By: Andrew Ferguson (owsla) Date: 2007-07-04 11:04 Message: Logged In: YES user_id=19094 Originator: NO Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which are mapped to 'unsigned int' on at least some Unix platforms (I haven't checked extensively.) The wrinkle here is that chown() needs to be able to handle the case of uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1, -1) is valid, but so is os.chown(4294967294, 4294967294). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470 From noreply at sourceforge.net Sun Jul 8 22:02:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 13:02:21 -0700 Subject: [ python-Bugs-1750013 ] os.getlogin should use the DISPLAY and not the tty Message-ID: Bugs item #1750013, was opened at 2007-07-08 22:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750013&group_id=5470 Please note that this 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: Serge Noiraud (snoiraud) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin should use the DISPLAY and not the tty Initial Comment: Hi, I have the following with gramps on kubuntu ( KDE ). My terminals are "konsole". They don't register their pty in utmp and I think they are correct. We are already logged. so if we register again for each konsole, we have a bad user count. In these case, os.getlogin() return : OSError: [Errno 2] No such file or directory I think getlogin should use the DISPLAY instead of the tty when we get this error. to correct this problem I use : try: user=os.getlogin() except: user=os.environ.get("USER") but I'm not sure os.environ.get return the good value on every OSes ... I have tested too : except: user = pwd.getpwuid(os.getuid())[0] What is the best solution to this problem. I looked at all bugs about getlogin and I saw we should avoid this function. What is in this case the function we should use and which works correctly on every OS ( Linux, Unices, Windows, MAC OS/X, ... ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750013&group_id=5470 From noreply at sourceforge.net Mon Jul 9 01:24:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 16:24:30 -0700 Subject: [ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers Message-ID: Bugs item #1750076, was opened at 2007-07-08 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=1750076&group_id=5470 Please note that this 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: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 From noreply at sourceforge.net Mon Jul 9 01:32:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 16:32:41 -0700 Subject: [ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers Message-ID: Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 Please note that this 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: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. ---------------------------------------------------------------------- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 From noreply at sourceforge.net Mon Jul 9 01:35:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 16:35:45 -0700 Subject: [ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers Message-ID: Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 Please note that this 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: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. ---------------------------------------------------------------------- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:35 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.5, the breakpoint is met once then passed over, leading straight to the final print statement -- chris at feathers:~/development/playground$ python2.5 -m pdb simple.py > /home/chris/development/playground/simple.py(3)() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)() -> while a > 0: (Pdb) r Fin! --Return-- > /home/chris/development/playground/simple.py(8)()->None -> print "Fin!" (Pdb) ---------------------------------------------------------------------- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 From noreply at sourceforge.net Mon Jul 9 01:37:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jul 2007 16:37:44 -0700 Subject: [ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers Message-ID: Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 Please note that this 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: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. ---------------------------------------------------------------------- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:37 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.4, the breakpoint is honored through each iteration through the while loop. -- chris at feathers:~/development/playground$ python2.4 -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 10 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 9 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 8 (Pdb) ---------------------------------------------------------------------- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:35 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.5, the breakpoint is met once then passed over, leading straight to the final print statement -- chris at feathers:~/development/playground$ python2.5 -m pdb simple.py > /home/chris/development/playground/simple.py(3)() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)() -> while a > 0: (Pdb) r Fin! --Return-- > /home/chris/development/playground/simple.py(8)()->None -> print "Fin!" (Pdb) ---------------------------------------------------------------------- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:32:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:32:06 -0700 Subject: [ python-Bugs-1508369 ] logging module formatter problem with %(filename)s Message-ID: Bugs item #1508369, was opened at 2006-06-19 04:08 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Hess (david_k_hess) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:32 Message: Logged In: YES user_id=580910 Originator: NO Closing because this is fixed in 2.5 and beyond and 2.4 is closed for maintainance ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 09:46 Message: Logged In: YES user_id=1326842 Originator: NO The 2.4 branch is not maintained anymore. Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:16 Message: Logged In: YES user_id=580910 Fixed in revision #47093 for python2.5. I'm not closing the bug yet because I haven't backported this to 2.4 yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:35:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:35:28 -0700 Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils Message-ID: Bugs item #1530142, was opened at 2006-07-28 08:02 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Richard Jones (richard) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac Universal Build of Python confuses distutils Initial Comment: I'm sorry I can't provide a fully-detailed report here, but I'm not in a position to be able to reproduce the problem. In short, I installed the Universal build of Python 2.4.3 for the Mac downloaded from: http://pythonmac.org/packages/py24-fat/index.html I don't know whether this is the same as the download from: http://www.python.org/download/releases/2.4.3/ Once installed, I attempted to build ctypes. The build failed due to an assembly error (unknown instruction). I'm not familiar with the PPC or x86 assembler code so couldn't do a thorough analysis. I needed Python2.4 to work, so I found an older PPC-only installer and used that. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:35 Message: Logged In: YES user_id=580910 Originator: NO I'm closing this bug, the problem is in ctypes installer you used. For the record: you can build a ppc/intel only version of an extension by patching the setup.py of the project your building and adding ('-arch', 'i386') or ('-arch', 'ppc') to the extra_compile_args and extra_link_args of Extension objects (I'm typing this without looking at the documention and have probably misspelled these argument names) ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2006-11-28 22:56 Message: Logged In: YES user_id=6405 Originator: YES I just successfully built ctypes 1.0.1 on a MacBook (ie. x86) OS X machine. I don't know whether it builds on a PPC machine. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2006-08-16 23:52 Message: Logged In: YES user_id=6405 I successfully built ctypes on PPC OSX using a non-universal build. Also, I wasn't running on x86 OSX so it shouldn't have tried to build that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:25 Message: Logged In: YES user_id=21627 This might be a ctypes limitation: it might be that ctypes doesn't support x86-OSX (atleast in this release). ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2006-07-28 08:47 Message: Logged In: YES user_id=6405 0.9.9.6 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-28 08:28 Message: Logged In: YES user_id=580910 Which version of ctypes did you try to build? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:40:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:40:12 -0700 Subject: [ python-Feature Requests-1563046 ] MacPython ignores user-installed Tcl/Tk Message-ID: Feature Requests item #1563046, was opened at 2006-09-21 19:55 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1563046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Macintosh >Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython ignores user-installed Tcl/Tk Initial Comment: MacPython ignores any user-installed Framework Tcl/Tk. This is a significant issue for Tcl/Tk users because the Tcl/Tk included with Tiger is buggy and really shouldn't be used. Bob Ippolito supplied me a recipe to fix _tkinter.so: install_name_tool \ -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/ Tcl \ /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \ -change /System/Library/Frameworks/Tk.framework/Versions/8.4/ Tk \ /Library/Frameworks/Tk.framework/Versions/8.4/Tk \ _tkinter.so I encapsulated this recipe into the attached python script "fixtkinter.py", which modifies _tkinter.so to use the user's Tcl/Tk, if found. Please consider running this script while installing MacPython. If you want any refinements to the script, I am happy to provide them (or feel free to modify it yourself of course). Subtleties: - The script uses Carbon.Folder.FSFindFolder to find the "/Library/ Framework" directory, so it should work in any country. - The script fixes the _tkinter.so for the python that executes the script (finding it relative to the "os" module). - The script silently exits without doing anything if no /Library/ Framework Tcl/Tk is found. Thus it is safe to run for all MacPython installations. - It can safely be run more than once; it silently does not modify _tkinter.so file the second time. - It finds the link using ...Tcl.Framework/Versions/Current but resolves the link before modifying _tkinter.so. So if a user upgrades a major Tcl/ Tk version the _tkinter.so file will keep using the old version. I think this is a good thing, since compatilibility is likely to be an issue. - It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it does NOT look in the user's private library (~/Library). This was intentional, but I'm not sure it was the right decision. I'm happy to change it, but will want some advice on the best algorithm. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:40 Message: Logged In: YES user_id=580910 Originator: NO Current builds of python look in /Library and /System/Library (in that order). IMHO that is good enough(tm), as that's where one would expect Tcl/Tk to be unless a really savy user did a manual install from source. I don't like shipping the proposed fix module, IMHO it would be better to publish that somewhere else (such as the python cookbook) as scripts like this will otherwise likely be overlooked. Changing the link path should also not be necessary with current builds of python. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2006-09-25 22:43 Message: Logged In: YES user_id=431773 I see what you mean about different installations. I think the following might work better: - Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. This will fall back to the built in /System/Library/Frameworks if the user has not installed an 8.4 of their own. It avoids a few of the issues you bring up and is simpler and more robust than what I originally suggested. Advantages: - All installations would be the same. - If the user installs a new Tcl/Tk after installing Python, it would be used (unless it's 8.5, which would not be safe to try with Python). It still does not address your concern than a user might accidentally have a Tcl/Tk that they don't want to use. I'd personally be happier if users could easily upgrade their Tcl/Tk (since the installed one is so bad), so I see this as more of an advantage than a disadvantage. Users aren't going to typically install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've seen more requests for help than I have over the years. I'm not keen on including a Tcl/Tk for several reasons: - It can be tricky to add needed additions (my app uses the "snack" sound library, for example). A standard Tcl/Tk makes this much easier (and in fact ActiveState Tcl/Tk already includes all additions most folks would want). - There is no universal Tcl/Tk yet (though one is planned). I personally don't want to try to build one. - Which version would you use? Even 8.4.11 has some important known bugs, and 8.4.13 has different ones (at least one of which is very nasty for my application, so I stick with 8.4.11 for now). So my personal suggestion is that we modify _tkinter.so using Bob Ippolito's recipe unchanged (no fancy script that hunts for an installed Tcl/Tk). It will be completely compatible with the built in Tcl/Tk but gives any real users of Tcl/ Tk (anyone who isn't just writing "hello world") a trivial way to get a decent version. I also suggest ditching the python script (or simplifying it to just institute Bob's recipe, but a shell script probably makes more sense for that job). Note that Bob's recipe is in the comments at the top of my python script. Thanks for the note about /Library/Frameworks. I had no idea it was a universal name. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-23 20:52 Message: Logged In: YES user_id=580910 If this gets used (and that's a big if at the moment) it should not look in the users private library folder, because the system might be used by multiple users and a system wide install should not use files that happen to be in the home directory of one of them. I don't like using this script during installation but would prefer a slightly different solution: ship this script in /Applications/MacPython 2.5 and tell users about it in our documentation (the installer documentation, the pythonmac.org FAQ and possibly the tkinter docs). If Tiger's copy of Tk is really bad enough to avoid using it completely we should find a way to ship a minimal copy of Tcl/Tk with our installer (installed into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/ {Tcl,Tk}.framework), again with your script installed in the applications folder for people that want to use a bleeding edge copy of Tk. I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks because of the support issue this raises: it is hard enough to debug problems as it is without users haveing slightly different library versions. BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, / Library/Frameworks is named like that in all languages, the name you see in the Finder might be different but that's because the Finder localizes the names of a number of folders (hence the ".localized" file in a number of folders). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1563046&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:44:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:44:03 -0700 Subject: [ python-Feature Requests-1555501 ] Please include pliblist for all plattforms Message-ID: Feature Requests item #1555501, was opened at 2006-09-09 22:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido Guenther (guidog) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:44 Message: Logged In: YES user_id=580910 Originator: NO assigning to me to help me remember that I should write documentation. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-12 11:08 Message: Logged In: YES user_id=580910 As an aside: adding plistlib to the standard library seems to be a good idea. I've discussed this with Jack Jansen and Bob Ippolito and they agree. The only thing that's missing at the moment is documentation. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:05 Message: Logged In: YES user_id=849994 Currently, there is no documentation for plistlib. Would you be willing to help writing one? ---------------------------------------------------------------------- Comment By: Guido Guenther (guidog) Date: 2006-09-17 22:27 Message: Logged In: YES user_id=696207 That's sad since it looks unproblematic. Please add it to 2.6 then. Thanks a lot, -- Guido ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1555501&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:48:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:48:28 -0700 Subject: [ python-Bugs-1738250 ] Universal MacPython 2.5.1 installation fails Message-ID: Bugs item #1738250, was opened at 2007-06-16 10:03 Message generated for change (Comment added) made by ronaldoussoren 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: Ronald Oussoren (ronaldoussoren) 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. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:48 Message: Logged In: YES user_id=580910 Originator: NO What version of OSX are you using and on what CPU-type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:52:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:52:47 -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 (Comment added) made by ronaldoussoren 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. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:52 Message: Logged In: YES user_id=580910 Originator: NO Which configure arguments are you using? Are you building a framework or a plain unix install? IMHO the call to libtool in Makefile.pre.in is correct, but that's only used when building a framework. The call to libtool is supposed to be a call to Apple's libtool, not the GNU tool with the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 From noreply at sourceforge.net Mon Jul 9 09:53:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 00:53:40 -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 (Comment added) made by swachi 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: Ronald Oussoren (ronaldoussoren) 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. ---------------------------------------------------------------------- >Comment By: Shinichiro Wachi (swachi) Date: 2007-07-09 00:53 Message: Logged In: YES user_id=279950 Originator: YES Sorry, I forgot to specify those: 1) OSX ver. 10.4.9 2) Processor: 1.5 GHz PPC G4 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 00:48 Message: Logged In: YES user_id=580910 Originator: NO What version of OSX are you using and on what CPU-type? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738250&group_id=5470 From noreply at sourceforge.net Mon Jul 9 10:09:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 01:09:02 -0700 Subject: [ python-Bugs-1627543 ] Status bar on OSX garbled Message-ID: Bugs item #1627543, was opened at 2007-01-04 05:49 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: sigzero (sigzero) Assigned to: Nobody/Anonymous (nobody) Summary: Status bar on OSX garbled Initial Comment: The way that OSX windows work there is always a resizing handle in the lower right hand corner of windows. The way that IDLE currently does the statusbar is: |Ln: 13|Col: 4 This cause the Col number to be placed over the resizer. Something along the lines of: |Ln: 13|Col: 4| would probably ensure that the resizer is not overlayed. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 10:09 Message: Logged In: YES user_id=580910 Originator: NO Don't run OSX GUI applications outside of an application bundle, that is unsupported behaviour as far as the OS is concerned. Python has a workaround that makes it possible to do this, but that's mostly meant to be used during development only. If you want to open a file in idle from the command-line use 'open -a IDLE somefile.py'. I'm closing this bug as wont-fix because of this. ---------------------------------------------------------------------- Comment By: Gus Tabares (gtabares) Date: 2007-04-17 17:04 Message: Logged In: YES user_id=834009 Originator: NO This is only reproducible when invoking IDLE from the Terminal. Invoking IDLE from the Finder is not affected. Here is the broken code in question: Line 299 EditorWindow.py if macosxSupport.runningAsOSXApp(): This will always return False from the Terminal because IDLE.app is not in sys.argv[0] (see macosxSupport.py line 9). ---------------------------------------------------------------------- Comment By: sigzero (sigzero) Date: 2007-01-04 05:49 Message: Logged In: YES user_id=1339209 Originator: YES This is for IDLE 1.1.4 and I am using Python 2.4.4 on OSX Tiger. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 From noreply at sourceforge.net Mon Jul 9 10:15:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 01:15:28 -0700 Subject: [ python-Bugs-1590864 ] import deadlocks when using PyObjC threads Message-ID: Bugs item #1590864, was opened at 2006-11-05 17:06 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Tsai (michaeltsai) Assigned to: Nobody/Anonymous (nobody) Summary: import deadlocks when using PyObjC threads Initial Comment: When I use subprocess.py from a child thread, sometimes it deadlocks. I determined that the new process is blocked during an import: #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90028414 in pthread_cond_wait () #2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1) at Python/thread_pthread.h:452 #3 0x004ae2a6 in lock_import () at Python/import.c:266 #4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno", globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at Python/import.c:2054 #5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90, kwds=0x0) at Python/bltinmodule.c:47 #6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90, kw=0x0) at Objects/abstract.c:1860 and that the code in question is in os.py: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR I think the problem is that since exec (the C function) hasn't yet been called in the new process, it's inherited from the fork a lock that's already held. The main process will eventually release its copy of the lock, but this will not unlock it in the new process, so it deadlocks. If I change os.py so that it imports the constants outside of _execvpe, the new process no longer blocks in this way. This is on Mac OS X 10.4.8. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 10:15 Message: Logged In: YES user_id=580910 Originator: NO Do you have sample code that reproduces this problem? (Not necessarily code that has this problem 100% of the time) ---------------------------------------------------------------------- Comment By: Kosuha (kosuha) Date: 2007-02-27 17:54 Message: Logged In: YES user_id=1684258 Originator: NO I confirm that problem with deadlock on execution of PyImport_ImportModuleLevel exists. Here is a working example: 1) Python was embbeded with C++ application using Python for scripting support: ------------------------------------------------------------------ PyThreadState * InitThreadScripting() { ASSERT_KOBOLD( g_pyMainThreadState ); // get the global lock PyEval_AcquireLock(); // get a reference to the PyInterpreterState PyInterpreterState * mainInterpreterState = g_pyMainThreadState->interp; ASSERT_KOBOLD( mainInterpreterState ); // create a thread state object for this thread PyThreadState * myThreadState = PyThreadState_New(mainInterpreterState); // free the lock PyEval_ReleaseLock(); return myThreadState; } --------------------------------------------------------------------- void DeadLock() { Py_Initialize(); PyEval_InitThreads(); g_AiGlobals = new Py::Dict(); g_pyInterpState = PyInterpreterState_New(); // save a pointer to the main PyThreadState object g_pyMainThreadState = PyThreadState_Get(); ASSERT_KOBOLD( g_pyMainThreadState ); // release the lock PyEval_ReleaseLock(); g_pyWorldThreadState = InitThreadScripting(); // import sys // sys.path.append ("./scripts") // PyObject *p = PyImport_ImportModuleEx ("sys", **g_AiGlobals, NULL, NULL); Py::Module mod_sys (p); Py::List path = mod_sys.getAttr ("path"); path.append (Py::String ("scripts")); path.append (Py::String ("scripts/sys")); path.append (Py::String ("../../scripts")); path.append (Py::String ("../../scripts/sys")); Py_XDECREF (p); // HERE IT OCCURS // Log.ScriptsSrc("Python", "Running startup python scripts..."); PyObject *p = PyImport_ImportModuleEx ("startup", **g_AiGlobals, NULL, NULL); // <<< Here if (reload) PyImport_ReloadModule (p); Py::Module module (p); Py_XDECREF (p); } Execution locks right on PyImport_ImportModuleEx. Code from sturtup.py: ------------------------------------------------------------------------------------ # This module is sturtup script. # Here we are redirecting output and checking for server version. ################################################################################ import sys from consts import * # Import of constants import config as cfg # Import of configuration constants reload(cfg) ################################################################################ # ---------------------------------------------------------------------------------------------------------------------------------------------------------------- class OurLogStdErr: def write (self, txt): printLog (txt, PRINT_ERROR) # ---------------------------------------------------------------------------------------------------------------------------------------------------------------- class OurLogStdOut: def write (self, txt): printLog (txt) # ---------------------------------------------------------------------------------------------------------------------------------------------------------------- def CheckServerVersion(): # Checking for server build if GetServerBuild() < MIN_SERVER_BUILD: printLog( "YOU ARE TRYING TO RUN PYTHON SCRIPTS ON OUTDATED SERVER BUILD!\ \nREQUIRED SERVER BUILD: %s\ \nPlease Update your server core before running server!\ \nScripting Engine will be Shut Down!"\ % (MIN_SERVER_BUILD), PRINT_ERROR ) killScripting() # ---------------------------------------------------------------------------------------------------------------------------------------------------------------- def GetScriptsVersion(): return SCRIPTS_VERSION ################################################################################ # Startup code here: # Redirecting errors: sys.stderr = OurLogStdErr() # Redirecting output: sys.stdout = OurLogStdOut() --------------------------------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-01-13 23:42 Message: Logged In: YES user_id=344921 Originator: NO Since both the reporter and I believes that this is not a bug in the subprocess module, I'm stepping back. ---------------------------------------------------------------------- Comment By: Michael Tsai (michaeltsai) Date: 2007-01-07 18:09 Message: Logged In: YES user_id=817528 Originator: YES I don't have time at the moment to write sample code that reproduces this. But, FYI, I was using PyObjC to create the threads. It might not happen with "threading" threads. And second, I think it's a bug in os.py, not in subprocess.py. Sorry for the confusion. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-01-07 15:10 Message: Logged In: YES user_id=344921 Originator: NO Can you provide a test case or sample code that demonstrates this problem? I'm a bit unsure of if this really is a subprocess bug or a more general Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 From noreply at sourceforge.net Mon Jul 9 22:57:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 13:57:30 -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 (Comment added) made by jackjansen 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: Closed >Resolution: Works For Me 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. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2007-07-09 22:57 Message: Logged In: YES user_id=45365 Originator: YES Tried it again ("../configure --enable-framework" on an Intel mac) and the problem does not occur. Assume the last time it was a pilot error, sorry! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:52 Message: Logged In: YES user_id=580910 Originator: NO Which configure arguments are you using? Are you building a framework or a plain unix install? IMHO the call to libtool in Makefile.pre.in is correct, but that's only used when building a framework. The call to libtool is supposed to be a call to Apple's libtool, not the GNU tool with the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 From noreply at sourceforge.net Tue Jul 10 03:55:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 18:55:28 -0700 Subject: [ python-Bugs-1694950 ] Bad documentation of SMTPException Message-ID: Bugs item #1694950, was opened at 2007-04-05 21:48 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694950&group_id=5470 Please note that this 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: None Priority: 2 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Bad documentation of SMTPException Initial Comment: The documentation of the SMTP object http://docs.python.org/lib/SMTP-objects.html lists "SMTPError" as a possible exception. It should be "SMTPException" instead of "SMTPError". Also, the "SMTPAuthenticationError" needs to be listed on the first page of the smtlib documentation http://docs.python.org/lib/module-smtplib.html ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2007-07-10 10:55 Message: Logged In: YES user_id=671362 Originator: NO > "SMTPException" instead of "SMTPError". This one was fixed in r53370. > the "SMTPAuthenticationError" needs to be listed This one was fixed in r56129. You can check them in development version documentation. http://docs.python.org/dev/lib/module-smtplib.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694950&group_id=5470 From noreply at sourceforge.net Tue Jul 10 05:48:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 20:48:47 -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 15:29 Message generated for change (Comment added) made by dhuang 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: David Huang (dhuang) Date: 2007-07-10 11:48 Message: Logged In: YES user_id=97663 Originator: NO I've just installed this package on 2 CentOS 4.5 Server without any problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-23 19: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 21: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 20: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 Jul 10 07:36:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jul 2007 22:36:09 -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: Closed >Resolution: Fixed 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-07-10 07:36 Message: Logged In: YES user_id=21627 Originator: NO Closing as "fixed" then. ---------------------------------------------------------------------- Comment By: David Huang (dhuang) Date: 2007-07-10 05:48 Message: Logged In: YES user_id=97663 Originator: NO I've just installed this package on 2 CentOS 4.5 Server without any problem. ---------------------------------------------------------------------- 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 Tue Jul 10 10:45:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 01:45:31 -0700 Subject: [ python-Bugs-1750013 ] os.getlogin should use the DISPLAY and not the tty Message-ID: Bugs item #1750013, was opened at 2007-07-08 22:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750013&group_id=5470 Please note that this 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: Serge Noiraud (snoiraud) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin should use the DISPLAY and not the tty Initial Comment: Hi, I have the following with gramps on kubuntu ( KDE ). My terminals are "konsole". They don't register their pty in utmp and I think they are correct. We are already logged. so if we register again for each konsole, we have a bad user count. In these case, os.getlogin() return : OSError: [Errno 2] No such file or directory I think getlogin should use the DISPLAY instead of the tty when we get this error. to correct this problem I use : try: user=os.getlogin() except: user=os.environ.get("USER") but I'm not sure os.environ.get return the good value on every OSes ... I have tested too : except: user = pwd.getpwuid(os.getuid())[0] What is the best solution to this problem. I looked at all bugs about getlogin and I saw we should avoid this function. What is in this case the function we should use and which works correctly on every OS ( Linux, Unices, Windows, MAC OS/X, ... ) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-07-10 10:45 Message: Logged In: YES user_id=21627 Originator: NO os.getlogin is a wrapper around the getlogin(3) POSIX function. It is important that Python exposes the function as-is, rather than trying to be more clever than the operating system designers. getlogin(3) is specified as "getlogin() returns a pointer to a string containing the name of the user logged in on the controlling terminal of the process, or a null pointer if this information cannot be determined." See the man page for the precise list of error conditions; ENOENT is returned if there is no utmp entry. Whether konsole is correct in not listing the controlling terminal in utmp, I don't know. Notice that xterm (which should be considered an authority in such matters) *does* create an utmp entry. It's not clear to me how DISPLAY could be used at all, but even if it could, using it here would be incorrect. Closing as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750013&group_id=5470 From noreply at sourceforge.net Tue Jul 10 13:10:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 04:10:26 -0700 Subject: [ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial Message-ID: Feature Requests item #1637365, was opened at 2007-01-17 06:11 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470 Please note that this 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: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: if __name__=='__main__' missing in tutorial Initial Comment: I could not find any reference to the big idiom: if __name__=="__main__": xxx() inside the Python tutorial. Of course it is documented in the Library Reference and the Reference Manual, but such an important idiom should be on the Tutorial for beginners to see. I can't provide a patch, and English is not my native language, but I think a short text like the following would suffice (in section More on Modules, before the paragraph "Modules can import other modules..."): Sometimes it is convenient to invoke a module as it were a script, either for testing purposes, or to provide a convenient user interfase to the functions contained in the module. But you don't want to run such code when the module is imported into another program, only when it's used as a standalone script. The way of differentiate both cases is checking the \code{__name__} attribute: as seen on the previous section, it usually holds the module name, but when the module is invoked directly, it's always \samp{__main__} regardless of the script name. Add this at the end of \file{fibo.py}: \begin{verbatim} if __name__=="__main__": import sys fib(int(sys.argv[1])) \end{verbatim} and then you can execute it using: \begin{verbatim} python fibo.py 50 1 1 2 3 5 8 13 21 34 \end{verbatim} ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-07-10 13:10 Message: Logged In: YES user_id=51702 Originator: NO I just ran into this "problem" today, when teaching someone python. It is definitely a glaring omission and needs to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470 From noreply at sourceforge.net Tue Jul 10 17:04:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 08:04:08 -0700 Subject: [ python-Bugs-1751245 ] Popen pipe file descriptor leak on OSError in init Message-ID: Bugs item #1751245, was opened at 2007-07-10 11: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=1751245&group_id=5470 Please note that this message 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: Justin Francis (justinfrancis) Assigned to: Nobody/Anonymous (nobody) Summary: Popen pipe file descriptor leak on OSError in init Initial Comment: OS: Gentoo Linux 2.6.12-r6 Python: 2.5 r25:51908 When creating a Popen object that refers to a file that does not exist, the pipes that are created are not closed, and remain in the system. In long-running processes, this will eventually use up all the file descriptors available. >> import os, subprocess >> os.system('/usr/sbin/lsof | grep python | grep -i pipe') ... python 18822 jfrancis 6r FIFO 0,5 56188 pipe python 18822 jfrancis 7r FIFO 0,5 56190 pipe >> p = subprocess.Popen('doesnotexist', stdout=subprocess.PIPE) OSError: [Errno 2] No such file or directory >> os.system('/usr/sbin/lsof | grep python | grep -i pipe') ... python 18822 jfrancis 6r FIFO 0,5 56188 pipe python 18822 jfrancis 7r FIFO 0,5 56190 pipe python 18822 jfrancis 8r FIFO 0,5 56713 pipe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751245&group_id=5470 From noreply at sourceforge.net Tue Jul 10 17:38:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 08:38:04 -0700 Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads Message-ID: Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message 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: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.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 P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 From noreply at sourceforge.net Tue Jul 10 18:00:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 09:00:48 -0700 Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads Message-ID: Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message 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: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 18:00 Message: Logged In: YES user_id=769182 Originator: NO As an additional note, I have also reproduced the popen problem using Python 2.4.4, though only once. It seems to occur more frequently in subprocess.py. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.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 P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 From noreply at sourceforge.net Tue Jul 10 23:50:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 14:50:29 -0700 Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads Message-ID: Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message 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: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-07-10 23:50 Message: Logged In: YES user_id=21627 Originator: NO If you are seeing a bug in subprocess, please report it separately. This one has been fixed. Please don't assume that it is the "same" problem as the one reported here, unless you have a working patch that proves that it is indeed a similar problem. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 18:00 Message: Logged In: YES user_id=769182 Originator: NO As an additional note, I have also reproduced the popen problem using Python 2.4.4, though only once. It seems to occur more frequently in subprocess.py. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.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 P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 From noreply at sourceforge.net Wed Jul 11 03:48:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 18:48:05 -0700 Subject: [ python-Bugs-1751598 ] struni: str() doesn't call __str__() of subclasses of str Message-ID: Bugs item #1751598, was opened at 2007-07-11 03:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470 Please note that this message 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: struni: str() doesn't call __str__() of subclasses of str Initial Comment: In the py3k-struni branch the str() constructor doesn't use __str__ when the argument is an instance of a subclass of str. A user defined string can't change __str__(). It works in Python 2.5 and in the p3yk branch. Python 3.0x (py3k-struni:56245, Jul 10 2007, 23:34:56) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'x' # <- SHOULD RETURN 'v' Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'v' Python 3.0x (p3yk:56180, Jul 6 2007, 23:35:08) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'v' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470 From noreply at sourceforge.net Wed Jul 11 14:46:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 05:46:38 -0700 Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads Message-ID: Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message 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: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-11 14:46 Message: Logged In: YES user_id=769182 Originator: NO >From the original description: "Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this." I can be confident it is the same problem as I have used the exact same script to reproduce it, and got the exact same stack trace. As I added, I have also reproduced the "popen" problem using Python 2.4.4 once, though this is much harder to reproduce. So I claim this is not in fact fixed in all cases. I can report separately if you really want, but it seems odd when the symptoms and test case are the same. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-07-10 23:50 Message: Logged In: YES user_id=21627 Originator: NO If you are seeing a bug in subprocess, please report it separately. This one has been fixed. Please don't assume that it is the "same" problem as the one reported here, unless you have a working patch that proves that it is indeed a similar problem. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 18:00 Message: Logged In: YES user_id=769182 Originator: NO As an additional note, I have also reproduced the popen problem using Python 2.4.4, though only once. It seems to occur more frequently in subprocess.py. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.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 P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 From noreply at sourceforge.net Wed Jul 11 15:34:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 06:34:27 -0700 Subject: [ python-Bugs-1751885 ] struni: Three ctypes tests are SEGFAULTing Message-ID: Bugs item #1751885, was opened at 2007-07-11 15:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 Please note that this message 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: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: struni: Three ctypes tests are SEGFAULTing Initial Comment: Three test modules of the ctypes package are causing a seg fault in the py3k-struni branch. for MOD in Lib/ctypes/test/test_*.py; do echo $MOD; ./python $MOD >>results 2>&1; done ... Lib/ctypes/test/test_functions.py Segmentation fault Lib/ctypes/test/test_python_api.py Segmentation fault Lib/ctypes/test/test_slicing.py Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 From noreply at sourceforge.net Wed Jul 11 15:36:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 06:36:31 -0700 Subject: [ python-Bugs-1751885 ] struni: Three ctypes tests are SEGFAULTing Message-ID: Bugs item #1751885, was opened at 2007-07-11 15:34 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 Please note that this message 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: Christian Heimes (tiran) >Assigned to: Thomas Heller (theller) Summary: struni: Three ctypes tests are SEGFAULTing Initial Comment: Three test modules of the ctypes package are causing a seg fault in the py3k-struni branch. for MOD in Lib/ctypes/test/test_*.py; do echo $MOD; ./python $MOD >>results 2>&1; done ... Lib/ctypes/test/test_functions.py Segmentation fault Lib/ctypes/test/test_python_api.py Segmentation fault Lib/ctypes/test/test_slicing.py Segmentation fault ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-07-11 15:36 Message: Logged In: YES user_id=560817 Originator: YES Oh I forgot to mention my system: Ubuntu Linux 7.04 on an i386 compatible machine (Intel P3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 From noreply at sourceforge.net Wed Jul 11 16:27:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 07:27:41 -0700 Subject: [ python-Bugs-1751932 ] struni: help() is broken Message-ID: Bugs item #1751932, was opened at 2007-07-11 16: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=1751932&group_id=5470 Please note that this message 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: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: struni: help() is broken Initial Comment: The help() system doesn't work any more in the py3k-struni branch. >>> help(str) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/py3k-struni/Lib/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1686, in __call__ self.help(request) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1730, in help else: doc(request, 'Help on %s:') File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1513, in doc pager(render_doc(thing, title, forceload)) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1491, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1203, in docclass lambda t: t[1] == 'method') File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1151, in spill name, mod, object)) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 321, in document if inspect.isroutine(object): return self.docroutine(*args) File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 1271, in docroutine return decl + '\n' + (doc and self.indent(doc).rstrip() + '\n') File "/home/heimes/dev/python/py3k-struni/Lib/pydoc.py", line 991, in indent if lines: lines[-1] = lines[-1].rstrip() TypeError: 'itertools.imap' object is unsubscriptable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751932&group_id=5470 From noreply at sourceforge.net Wed Jul 11 16:28:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 07:28:08 -0700 Subject: [ python-Bugs-1751885 ] struni: Three ctypes tests are SEGFAULTing Message-ID: Bugs item #1751885, was opened at 2007-07-11 15:34 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 Please note that this message 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: Christian Heimes (tiran) Assigned to: Thomas Heller (theller) Summary: struni: Three ctypes tests are SEGFAULTing Initial Comment: Three test modules of the ctypes package are causing a seg fault in the py3k-struni branch. for MOD in Lib/ctypes/test/test_*.py; do echo $MOD; ./python $MOD >>results 2>&1; done ... Lib/ctypes/test/test_functions.py Segmentation fault Lib/ctypes/test/test_python_api.py Segmentation fault Lib/ctypes/test/test_slicing.py Segmentation fault ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-07-11 16:28 Message: Logged In: YES user_id=11105 Originator: NO Thanks for finding out (and apologies that I've made it so difficult to find crashing tests). Further investigation shows that the crashing test cases are: in test_functions.py: test_stringresult in test_python_api.py: test_PyOS_snprintf in test_slicing.py: test_char_ptr and test_char_ptr_with_free All in all, there are quite some char problems in the struni branch, but I'm working on them. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-07-11 15:36 Message: Logged In: YES user_id=560817 Originator: YES Oh I forgot to mention my system: Ubuntu Linux 7.04 on an i386 compatible machine (Intel P3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 From noreply at sourceforge.net Wed Jul 11 20:27:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 11:27:13 -0700 Subject: [ python-Bugs-1751885 ] struni: Three ctypes tests are SEGFAULTing Message-ID: Bugs item #1751885, was opened at 2007-07-11 15:34 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 Please note that this message 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: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Thomas Heller (theller) Summary: struni: Three ctypes tests are SEGFAULTing Initial Comment: Three test modules of the ctypes package are causing a seg fault in the py3k-struni branch. for MOD in Lib/ctypes/test/test_*.py; do echo $MOD; ./python $MOD >>results 2>&1; done ... Lib/ctypes/test/test_functions.py Segmentation fault Lib/ctypes/test/test_python_api.py Segmentation fault Lib/ctypes/test/test_slicing.py Segmentation fault ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-07-11 20:27 Message: Logged In: YES user_id=560817 Originator: YES Yeah it wasn't easy to find the faulty tests. Your last commit fixed the segfault problem for me. About 20 to 25 tests are still failing but at least I can run the regression tests again w/o removing test_ctypes.py. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-07-11 16:28 Message: Logged In: YES user_id=11105 Originator: NO Thanks for finding out (and apologies that I've made it so difficult to find crashing tests). Further investigation shows that the crashing test cases are: in test_functions.py: test_stringresult in test_python_api.py: test_PyOS_snprintf in test_slicing.py: test_char_ptr and test_char_ptr_with_free All in all, there are quite some char problems in the struni branch, but I'm working on them. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-07-11 15:36 Message: Logged In: YES user_id=560817 Originator: YES Oh I forgot to mention my system: Ubuntu Linux 7.04 on an i386 compatible machine (Intel P3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751885&group_id=5470 From noreply at sourceforge.net Thu Jul 12 00:06:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 15:06:34 -0700 Subject: [ python-Bugs-1752252 ] tkFileDialog closes Python when used Message-ID: Bugs item #1752252, was opened at 2007-07-11 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752252&group_id=5470 Please note that this 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: ferrari24 (ferrari24) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog closes Python when used Initial Comment: Whenever I use tkFileDialog, after a couple of seconds of the File Dialog window being open, Python closes. The entire application just closes, and there is no error reporting screen. I am using Python 2.5.1 on Microsoft Windows XP Pro. SP2 (x86). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752252&group_id=5470 From noreply at sourceforge.net Thu Jul 12 02:15:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 17:15:47 -0700 Subject: [ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes. Message-ID: Bugs item #971965, was opened at 2004-06-13 05:00 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&group_id=5470 Please note that this message 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: Ed Watkeys (edw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises exception with non-200 success codes. Initial Comment: If a server returns a code other than 200, specifically 201 (Created), urllib2.urlopen will raise an HTTPError exception. I ran into this while implementing an Atom API client, which solicits 201 responses from the server when submitting a blog post. File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open return self.parent.error('http', req, fp, code, msg, hdrs) File "/usr/local/lib/python2.3/urllib2.py", line 352, in error return self._call_chain(*args) File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 412, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 201: Created ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-07-12 01:15 Message: Logged In: YES user_id=261020 Originator: NO Duplicate of 912845, please close. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-12 00:11 Message: Logged In: YES user_id=261020 Originator: NO Whether 206 and 201 are HTTP success responses is not the question at hand. Given that the 206 behaviour was changed, I agree that other success responses should also be considered (certainly seems a mistake that e.g. 203 was not added at the same time as 206), and indeed nobody has done that. But I think backwards compatibility, the semantics of the various response codes and of urllib2, and ease of understanding, are more important than you seem to assume. I don't see a patch. In what way exactly do you propose urllib2 should be changed? Note that it's not completely obvious: e.g. a 201 received by a plain-urllib2 client would be an erroneous server response, because urllib2 is designed only for retrieving URLs, and is not intended to be a generic HTTP client. Also note that clients based on urllib2 that do support PUT, such as the Atom client you refer to, can easily implement the modified 201 handling themselves. So on the face of it, the particular issue you raise is a bug in that code, and not in urllib2. Of course, your derogatory remarks about authors / bug-fixers won't persuade anybody of anything, or get any work done. ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2007-03-11 21:23 Message: Logged In: YES user_id=282299 Originator: NO Fixing this issue is not "maybe OK", it's the correct thing to do. Having an HTTP success response raise an exception is faulty behavior, and urllib2 users should not have to do silly things to work around it. It really seems like the authors of urllib2 only understood about 10% of the HTTP protocol. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:05 Message: Logged In: YES user_id=261020 Before bug 912845 (CVS rev 1.69) added 206 to the list of response codes considered "successful" by urllib2, I'd assumed this would never be altered, for backwards-compatibility reasons. Note that this behaviour can be configured by module users, since HTTPError exceptions support the urllib2 response interface. This can be done by replacing HTTPErrorProcessor, or by replacing HTTPDefaultErrorHandler, or catching the exception "manually". But maybe since the 206 issue was considered a valid bug fix, this is OK too. If so, it would be best if the other 20x responses were also considered at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&group_id=5470 From noreply at sourceforge.net Thu Jul 12 06:45:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 21:45:54 -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 (Comment added) made by ronaldoussoren 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: Closed Resolution: Works For Me 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. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 06:45 Message: Logged In: YES user_id=580910 Originator: NO Do you by any chance have GNU libtool on your PATH before Apple's version (that is, is 'which libtool' something else than /usr/bin/libtool)? I've recently commited a patch that replaces references to 'libtool' in the Makefile to '/usr/bin/libtool' because of someone haveing this issue. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2007-07-09 22:57 Message: Logged In: YES user_id=45365 Originator: YES Tried it again ("../configure --enable-framework" on an Intel mac) and the problem does not occur. Assume the last time it was a pilot error, sorry! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-09 09:52 Message: Logged In: YES user_id=580910 Originator: NO Which configure arguments are you using? Are you building a framework or a plain unix install? IMHO the call to libtool in Makefile.pre.in is correct, but that's only used when building a framework. The call to libtool is supposed to be a call to Apple's libtool, not the GNU tool with the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1736103&group_id=5470 From noreply at sourceforge.net Thu Jul 12 07:38:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 22:38:20 -0700 Subject: [ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin Message-ID: Bugs item #1666952, was opened at 2007-02-23 11:29 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 Please note that this 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: Jurjen N.E. Bos (jneb) >Assigned to: Jack Jansen (jackjansen) Summary: terminalcommand doesn't work under Darwin Initial Comment: The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out. I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-) Quotes, spaces and backslashes are handled properly. I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:38 Message: Logged In: YES user_id=580910 Originator: NO Are you using an Intel or PPC mac? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2007-02-23 11:31 Message: Logged In: YES user_id=446428 Originator: YES O yes: forgot to mention: The bug is for Mac only, any version of Python, OS X and up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 From noreply at sourceforge.net Thu Jul 12 07:51:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 22:51:07 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-20 00:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Treadway (treadway) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 17:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 10:38:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 01:38:31 -0700 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-05 02:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 08:38 Message: Logged In: YES user_id=849994 Originator: NO Patch was committed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-18 03:58 Message: Logged In: YES user_id=6380 Originator: NO Changing the group to 2.5; see the patch (http://python.org/sf/1673759) for an explanation. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 11:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 10:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 10:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 02:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 02:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Thu Jul 12 11:38:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 02:38:08 -0700 Subject: [ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial Message-ID: Feature Requests item #1637365, was opened at 2007-01-17 05:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: if __name__=='__main__' missing in tutorial Initial Comment: I could not find any reference to the big idiom: if __name__=="__main__": xxx() inside the Python tutorial. Of course it is documented in the Library Reference and the Reference Manual, but such an important idiom should be on the Tutorial for beginners to see. I can't provide a patch, and English is not my native language, but I think a short text like the following would suffice (in section More on Modules, before the paragraph "Modules can import other modules..."): Sometimes it is convenient to invoke a module as it were a script, either for testing purposes, or to provide a convenient user interfase to the functions contained in the module. But you don't want to run such code when the module is imported into another program, only when it's used as a standalone script. The way of differentiate both cases is checking the \code{__name__} attribute: as seen on the previous section, it usually holds the module name, but when the module is invoked directly, it's always \samp{__main__} regardless of the script name. Add this at the end of \file{fibo.py}: \begin{verbatim} if __name__=="__main__": import sys fib(int(sys.argv[1])) \end{verbatim} and then you can execute it using: \begin{verbatim} python fibo.py 50 1 1 2 3 5 8 13 21 34 \end{verbatim} ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 09:38 Message: Logged In: YES user_id=849994 Originator: NO Added a section about this in rev. 56306, 56307 (2.5). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-07-10 11:10 Message: Logged In: YES user_id=51702 Originator: NO I just ran into this "problem" today, when teaching someone python. It is definitely a glaring omission and needs to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470 From noreply at sourceforge.net Thu Jul 12 12:06:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 03:06:08 -0700 Subject: [ python-Bugs-1700865 ] PCbuild8/pcbuild.sln is missing "_socket" sub-project Message-ID: Bugs item #1700865, was opened at 2007-04-15 03:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700865&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Kristj?n Valur (krisvale) Summary: PCbuild8/pcbuild.sln is missing "_socket" sub-project Initial Comment: As the subject says, PCbuild8/pcbuild.sln is missing entry for "_socket". However, _socket.vcproj is present in the directory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-07-12 10:06 Message: Logged In: YES user_id=849994 Originator: NO This was fixed with rev. 55024. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-04-16 04:48 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700865&group_id=5470 From noreply at sourceforge.net Thu Jul 12 12:29:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 03:29:07 -0700 Subject: [ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin Message-ID: Bugs item #1666952, was opened at 2007-02-23 11:29 Message generated for change (Comment added) made by jneb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 Please note that this 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: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: terminalcommand doesn't work under Darwin Initial Comment: The "terminalcommand" library doesn't work under Darwin. It raises an obscure AppleScript error that I can't figure out. I made a tiny library that gives roughly the same API, but starts applications fine under Darwin (10.2 and up). It works using the osascript command, but Jack can probably get it too work using OSA directly :-) Quotes, spaces and backslashes are handled properly. I would recommend to extend terminalcommand to incorporate this code in the Darwin case, assuming that you still want to support OS9. ---------------------------------------------------------------------- >Comment By: Jurjen N.E. Bos (jneb) Date: 2007-07-12 12:29 Message: Logged In: YES user_id=446428 Originator: YES It is an Intel MacBook Pro. I though I ran 10.4.9 at the time, but I guess that is not an issue. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:38 Message: Logged In: YES user_id=580910 Originator: NO Are you using an Intel or PPC mac? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2007-02-23 11:31 Message: Logged In: YES user_id=446428 Originator: YES O yes: forgot to mention: The bug is for Mac only, any version of Python, OS X and up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470 From noreply at sourceforge.net Thu Jul 12 12:34:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 03:34:35 -0700 Subject: [ python-Bugs-1627952 ] plat-mac videoreader.py auido format info Message-ID: Bugs item #1627952, was opened at 2007-01-04 17:18 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Owen (ryaowe) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: plat-mac videoreader.py auido format info Initial Comment: videoreader.py in the plat-mac modules has a small bug that breaks reader.GetAudioFormat() --- videoreader.py Thu Jan 04 09:05:16 2007 +++ videoreader_fixed.py Thu Jan 04 09:05:11 2007 @@ -13,7 +13,7 @@ from Carbon import Qdoffs from Carbon import QDOffscreen from Carbon import Res try: - import MediaDescr + from Carbon import MediaDescr except ImportError: def _audiodescr(data): return None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627952&group_id=5470 From noreply at sourceforge.net Thu Jul 12 12:34:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 03:34:38 -0700 Subject: [ python-Bugs-1752539 ] RotatingFileHandler.doRollover behave wrong vs. log4j's Message-ID: Bugs item #1752539, was opened at 2007-07-12 18:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470 Please note that this message 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: Jin Qing (jinq0123) Assigned to: Nobody/Anonymous (nobody) Summary: RotatingFileHandler.doRollover behave wrong vs. log4j's Initial Comment: RotatingFileHandler.doRollover() will raise exception on rename() and cause all the subsequent log messages lost. But log4j is better. It ignore the rename() error and reset the log file. I read "[ 979252 ] Trap OSError when calling RotatingFileHandler.doRollover ( https://sourceforge.net/tracker/index.php?func=detail&aid=979252&group_id=5470&atid=105470 )", and think David London (groodude)'s solution is closer to log4j. At least, python logging implementation should follow log4j's behavior, or improve it, such as only discard the current one message. logging should be easy to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470 From noreply at sourceforge.net Thu Jul 12 12:41:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 03:41:04 -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 20:02 Message generated for change (Comment added) made by ronaldoussoren 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: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 12:41 Message: Logged In: YES user_id=580910 Originator: NO This certainly sounds like someone is fooling around with the -force_flat_namespace link flag, which could result in picking up the wrong version of symbols. I haven't checked yet if this is indeed the case here, and if so who is doing this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-07-05 03:31 Message: Logged In: YES user_id=44345 Originator: YES Certainly the patch is simpler. ;-) If loading GLUT doesn't add any value on OSX, would it add any value on other platforms? Do other tests have to find libraries successfully to pass? If so, maybe test_find should be dispensed with altogether, however if test_find has value we should figure out a library to load on OSX. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-07-04 22:01 Message: Logged In: YES user_id=11105 Originator: NO Skip, thanks for the analysis and test patch. IMO loading the GLUT library does not add significant value to the ctypes tests, so wouldn't it be best to skip the GLUT lib on OSX? See the attached patch "test_find without GLUT on OSX" (note that I didn't actually test the patch, and I don't have access to OSX G5 anyway). Maybe the problem and the analysis should be reported to the PyOpenGL project... File Added: test_find-no-osx-glut.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 15: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 13: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 12: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-30 05: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 05: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 04: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 04: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-30 01: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 21: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 22: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 16: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 21: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 18: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 20: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 Jul 12 17:32:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 08:32:44 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-20 00:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open >Resolution: Accepted >Priority: 3 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 17:32 Message: Logged In: YES user_id=580910 Originator: NO I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here. An overview of the changes: - Introduce a new header file: Include/pymacconfig.h This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode. - Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid. - mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that. Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue. I hope to prepare a patch with a full solution when I get back from Europython. NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 17:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 17:52:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 08:52:52 -0700 Subject: [ python-Bugs-1752723 ] email.message_from_string: initial line gets discarded Message-ID: Bugs item #1752723, was opened at 2007-07-12 10: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=1752723&group_id=5470 Please note that this message 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: David Webster (dwebster99) Assigned to: Nobody/Anonymous (nobody) Summary: email.message_from_string: initial line gets discarded Initial Comment: If the first line of the string passed to email.message_from_string starts with whitespace, the line gets discarded. I believe the problem is in the feed parser, but I don't have a test case to prove that. The attached file is a short program to illustrate the problem. When I run it I get the output shown below. The line count should be unchanged in both cases. leading whitespace : Body changed: lines in: 3 lines out: 2 left justified : Line count was preserved. Platform: Python 2.5.1 Windows 2000 SP4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752723&group_id=5470 From noreply at sourceforge.net Thu Jul 12 17:56:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 08:56:24 -0700 Subject: [ python-Bugs-758565 ] IDE needs to remember status of interactive window Message-ID: Bugs item #758565, was opened at 2003-06-22 00:14 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE needs to remember status of interactive window Initial Comment: the IDE needs to remember the status of the interactive window (open/closed) between runs, and when started for the very first time it needs to open that window. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 17:56 Message: Logged In: YES user_id=580910 Originator: NO Closing because the IDE that's mentioned here is no longer part of the python distribution. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-06-22 14:31 Message: Logged In: YES user_id=92689 Hm, the IDE always used to do just that. No time right now, will investigate later. Feel free to assign to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470 From noreply at sourceforge.net Thu Jul 12 18:24:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 09:24:15 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-19 15:22 Message generated for change (Comment added) made by treadway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: Accepted Priority: 3 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Thomas Treadway (treadway) Date: 2007-07-12 09:24 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 08:32 Message: Logged In: YES user_id=580910 Originator: NO I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here. An overview of the changes: - Introduce a new header file: Include/pymacconfig.h This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode. - Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid. - mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that. Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue. I hope to prepare a patch with a full solution when I get back from Europython. NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-11 22:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 08:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 18:24:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 09:24:55 -0700 Subject: [ python-Bugs-1724366 ] cPickle module doesn't work with universal line endings Message-ID: Bugs item #1724366, was opened at 2007-05-23 18:42 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470 Please note that this message 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: Geoffrey Bache (gjb1002) Assigned to: Jack Jansen (jackjansen) Summary: cPickle module doesn't work with universal line endings Initial Comment: On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings. It works fine with the pickle module but is of course slower (and I have to read lots of them) I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. On my system (RHEL4 with Python 2.4.3) I get the following output: portmoller : pickletest.py cPickle unix2dos: converting file dump to DOS format ... Traceback (most recent call last): File "pickletest.py", line 14, in ? print load(readFile) ImportError: No module named smtplib portmoller : pickletest.py pickle unix2dos: converting file dump to DOS format ... ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 18:24 Message: Logged In: YES user_id=580910 Originator: NO I can confirm that this is problem is present in python 2.5 (current svn) running on osx 10.4.10. Given the code of cPickle it is rather amazing that this script does work correctly on a linux system, as gagenellina noted cPickle shortcuts reads from real file objects and completely ignores universal newlines while doing so. IMHO Fixing this requires replicating the universal newline code in cPickle. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-29 07:14 Message: Logged In: YES user_id=21627 Originator: NO Jack, can you take a look? If not, please unassign. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-05-25 19:24 Message: Logged In: YES user_id=769182 Originator: YES Yes, I'm sure Python is trying to import "smtplib\r". For various reasons I need to use protocol 0: not least because I use the pickle files as test data and it's much easier to administer a load of text files than a load of binary files. I will experiment with reading the files in binary mode on Monday and get back to you. My current workaround is to do loads(file.read()) instead of load(file) which I guess is a performance penalty. Any idea whether this is likely to be slower than just using the pickle module? (I haven't tested this) ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 12:29 Message: Logged In: YES user_id=479790 Originator: NO The culprit is cPickle.c; it takes certain shortcuts for read() and readline() depending on which type of file you pass in. For a true file object, it uses its own implementation for those two methods, ignoring the file mode. But it appears that there is NO WAY universal line endings could work if the pickle contains any unicode object. The pickle format for Unicode quotes any \n but *not* \r so the unpickler cannot determine, when it sees a "\r", if it is a MAC end-of-line or an embedded "\r". So, the only safe end-of-line character for a pickle using protocol 0 is "\n", and that means that the file must be written in binary mode. (This may also indicate that you cannot read unicode objects with embedded \r in a MAC using protocol 0, but I don't have a MAC to test it). So, until this is fixed (either the module or the documentation), one should forget about universal line endings and write all pickle files as binary. (This way ALL lines end in \n and it should work fine on all platforms) ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 11:04 Message: Logged In: YES user_id=479790 Originator: NO I don't see any "Attach" button... Just add these lines near the top of the test script: original__import = __import__ def myimport(name, *args): print "import",repr(name) return original__import(name,*args) #end myimport __builtins__.__import__ = myimport ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 11:00 Message: Logged In: YES user_id=479790 Originator: NO Please try again with this modified version. I think you will see that Python is trying to import "smtplib\r" On Windows, trying to read a pickle file with MAC line endings gives a different error: cPickle.UnpicklingError: pickle data was truncated It seems that cPickle support for protocol 0 is broken. If you can, try to use the higher, binary, protocols, they don't have this problem. Even if you must use protocol 0, opening the file always in binary mode should not have this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470 From noreply at sourceforge.net Thu Jul 12 18:25:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 09:25:29 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-19 15:22 Message generated for change (Comment added) made by treadway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: Accepted Priority: 3 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Thomas Treadway (treadway) Date: 2007-07-12 09:25 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Thomas Treadway (treadway) Date: 2007-07-12 09:24 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 08:32 Message: Logged In: YES user_id=580910 Originator: NO I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here. An overview of the changes: - Introduce a new header file: Include/pymacconfig.h This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode. - Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid. - mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that. Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue. I hope to prepare a patch with a full solution when I get back from Europython. NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-11 22:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 08:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 18:32:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 09:32:53 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-20 00:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: Accepted Priority: 3 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 18:32 Message: Logged In: YES user_id=580910 Originator: NO treadway: do you have a reference to that? BTW. I have (legal) access to Leopard prereleases, but these are under NDA. Anyway, if you're right that just means I won't have to do more work after Leopard is released. We'll see... ---------------------------------------------------------------------- Comment By: Thomas Treadway (treadway) Date: 2007-07-12 18:25 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Thomas Treadway (treadway) Date: 2007-07-12 18:24 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 17:32 Message: Logged In: YES user_id=580910 Originator: NO I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here. An overview of the changes: - Introduce a new header file: Include/pymacconfig.h This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode. - Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid. - mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that. Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue. I hope to prepare a patch with a full solution when I get back from Europython. NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 07:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 17:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 19:56:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 10:56:47 -0700 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-19 15:22 Message generated for change (Comment added) made by treadway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: Accepted Priority: 3 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- >Comment By: Thomas Treadway (treadway) Date: 2007-07-12 10:56 Message: Logged In: YES user_id=1541276 Originator: YES I've seen a few references in mail list. I believe Apple is keeping it quiet. Cocoa will be the only 64-bit GUI At WWDC07. It was alluded to at the Mac OS X State of the Union, then explicitly stated by engineers in one of the sessions. The anouncement up set quite a few developers. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 09:32 Message: Logged In: YES user_id=580910 Originator: NO treadway: do you have a reference to that? BTW. I have (legal) access to Leopard prereleases, but these are under NDA. Anyway, if you're right that just means I won't have to do more work after Leopard is released. We'll see... ---------------------------------------------------------------------- Comment By: Thomas Treadway (treadway) Date: 2007-07-12 09:25 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Thomas Treadway (treadway) Date: 2007-07-12 09:24 Message: Logged In: YES user_id=1541276 Originator: YES Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-12 08:32 Message: Logged In: YES user_id=580910 Originator: NO I now have a fairly clear strategy for the C bits. I will upload a patch when I have a complete working solution (including testing). I can't test right now because I'm at EuroPython and don't have access to a PPC64 machine from here. An overview of the changes: - Introduce a new header file: Include/pymacconfig.h This header file does compile-time detection of a number of variables (such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time constants but only compile-time ones. This also surpressed the toolbox glue feature macro in 64-bit mode. - Patch setup.py to avoid compiling the Carbon wrappers and the toolbox glue in 64-bit mode, while still compiling them in 32-bit mode when building a 32-bit/64-bit hybrid. - mactoolboxglue.c contains some Carbon code outside of the block that's guarded by the feature macro. Also disable that. Python with these patches still builds and passes the test suite, both in 32-bit and 64-bit mode and with --enable-toolboxglue. I hope to prepare a patch with a full solution when I get back from Europython. NOTE: More work is needed once Leopard is released because the promised features of that include 64-bit support throughout the systems. Some of that work is non-trivial (see http://www.python.org/sf/779153). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2007-07-11 22:51 Message: Logged In: YES user_id=580910 Originator: NO Even two-way universal builds aren't supported in 64-bit mode. Non-universal 64-bit builds do work properly, the problem with 2-way universal 64-bit builds is that not all features that configure detects are the same on x86_64 and ppc64, the only one I've found so far is VA_LIST_IS_ARRAY (defined on one architecture but not the other). I'll pobably fix that soonish, 4-way universal builds will be more work although mostly in thinking about the right policies and especiall this issue: Will distutils in a 4-way universal build default to building? If yes, how will users be able to specify that an extension should be build in 32-bit mode only? If no, how does one build 64-bit extensions? I'm currently leaning towards: - Default to 32-bit only on Tiger and 4-way on Leopard - Patch build_ext and/or Extension to enable overriding the default without fiddling with CFLAGS/LDFLAGS (or there equivalents in distutils) (This is for a 4-way universal build only, 2-way universal builds and non-universal builds will keep behaving as they do now). BTW. 64-bit builds on any released version of OSX don't have access to anything but libSystem, which means: no GUI code and no access to Apple frameworks in general. This will change in Leopard (see Apple's website for that), but as this OS is still under NDA I won't comment on the details. Asssinged this bug to myself because I'm more likely to fix this than Jack is. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-03 08:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Thu Jul 12 21:28:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 12:28:02 -0700 Subject: [ python-Bugs-1752919 ] Exception in HTMLParser for special JavaScript code Message-ID: Bugs item #1752919, was opened at 2007-07-12 22: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=1752919&group_id=5470 Please note that this message 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: Eugine Kosenko (eugine_kosenko) Assigned to: Nobody/Anonymous (nobody) Summary: Exception in HTMLParser for special JavaScript code Initial Comment: import HTMLParser p = HTMLParser.HTMLParser() p.feed(""" """) Traceback (most recent call last): File "", line 4, in ? File "/usr/lib/python2.4/HTMLParser.py", line 108, in feed self.goahead(0) File "/usr/lib/python2.4/HTMLParser.py", line 150, in goahead k = self.parse_endtag(i) File "/usr/lib/python2.4/HTMLParser.py", line 314, in parse_endtag self.error("bad end tag: %r" % (rawdata[i:j],)) File "/usr/lib/python2.4/HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParser.HTMLParseError: bad end tag: "", at line 4, column 12 The JavaScript code is protected via HTML comment, so HTMLParser must skip it entirely, and the parsing must be successfull. Instead of this, the JavaScript code is parsed as a part of the HTML page, and incorrect end tag is detected. If one move the actual end tag up just after start tag