From noreply at sourceforge.net Wed Jun 1 05:00:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 20:00:38 -0700 Subject: [ python-Bugs-1212223 ] anydbm and 'n' flag Message-ID: Bugs item #1212223, was opened at 2005-05-31 19:32 Message generated for change (Settings changed) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jack Moffitt (jackiem) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and 'n' flag Initial Comment: When a 0 length file exists and anydbm is asked to create a new database with that file name via the anydbm.open(fn, 'n') call, the call fails as whichdb detection fails. whichdb should not be invoked with the 'n' flag, since the purpose of this flag is to always create a database, not only if it is missing. This bug prevents creating a secure temporary file with mkstemp and then uisng that file to open a database. The workaround is to unlink the file then call open, but this is leaving a small hole. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2005-06-01 03:00 Message: Logged In: YES user_id=81797 I'm torn as to what should happen here. In the documentation, it says that in the event that the file exists, the whichdb module will be used to determine the type of the database. In the case of an unrecognised database format, that function returns the empty string, and anydbm raises that as an exception. On the other hand, the documentation says that if "n" is passed a new database will always be created, which in this case it definitely is not. I'd be reluctant to change anydbm.open(), since the reason for anydbm to exist is that it determines the database type of an existing file, and in the case that it doesn't understand the database type it says so. One could imagine a "textdb" type being added later where an empty file would be a valid, empty, textdb file, but a change to anydbm here could lead to problems in the future. The real solution, I would propose, is that in the event that you're trying to create a temporary database, call mkstemp, then call "anydbm._defaultmod.open" on the resulting file name, for example. Call the module directly instead of relying on anydbm. I'm inclined to close this as Wont Fix, please re-open if you think the assessment is wrong. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&group_id=5470 From noreply at sourceforge.net Wed Jun 1 07:13:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 22:13:29 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 05:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Wed Jun 1 07:19:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 May 2005 22:19:53 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 01:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-06-01 01:19 Message: Logged In: YES user_id=31435 I expect you'll find that, e.g., Perl does the same thing: a "missing" alternative is treated as an empty string, and an empty string always matches. What basis do you have for claiming it should not match (beyond just repeating that it should not )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Wed Jun 1 09:41:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 00:41:36 -0700 Subject: [ python-Bugs-1205544 ] urllib has spurious print statement Message-ID: Bugs item #1205544, was opened at 2005-05-20 10:26 Message generated for change (Comment added) made by drcw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stuart Wray (drcw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has spurious print statement Initial Comment: In Python 2.4.1, the procedure getproxies_environment() in urllib.py has a spurious print statement on line 1188: print proxies This was presumably used for testing, but not commented out. ---------------------------------------------------------------------- >Comment By: Stuart Wray (drcw) Date: 2005-06-01 07:41 Message: Logged In: YES user_id=1282179 Oh, how embarasing. Sorry to waste your time. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 08:23 Message: Logged In: YES user_id=1188172 I can't find this line of code in urllib.py in the 2.4, 2.4.1, or 2.3.5 releases. Are you sure you didn't add it for testing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 From noreply at sourceforge.net Wed Jun 1 13:27:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 04:27:32 -0700 Subject: [ python-Bugs-779191 ] BasicModuleLoader behaviour in Python 2.3c2 Message-ID: Bugs item #779191, was opened at 2003-07-29 00:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779191&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Selim Tuvi (stuvi) Assigned to: Nobody/Anonymous (nobody) Summary: BasicModuleLoader behaviour in Python 2.3c2 Initial Comment: Hi I am using the BasicModuleLoader class from the ihooks module and noticed that it behaves differently based on whether it is used from a script vs. from the Python command line. Here is the transcript of my session: C:\projects\Online\repos>type testModule.py C:\projects\Online\repos>cd ..\testsuite C:\projects\Online\testsuite>type impTest.py from ihooks import BasicModuleLoader import os os.chdir('../repos') ml = BasicModuleLoader() modstuff = ml.find_module('testModule') print modstuff C:\projects\Online\testsuite>python impTest.py None C:\projects\Online\testsuite>python Python 2.3c2 (#45, Jul 24 2003, 21:23:54) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ihooks import BasicModuleLoader >>> import os >>> os.chdir('../repos') >>> ml = BasicModuleLoader() >>> modstuff = ml.find_module('testModule') >>> print modstuff (<open file 'testModule.py', mode 'U' at 0x008E8F20>, 'testModule.py', ('.py', ' U', 1)) >>> ^Z C:\projects\Online\testsuite>cd ..\repos C:\projects\Online\repos>python ..\testsuite\impTest.py (<open file 'C:\projects\Online\repos\testModule.py', mode 'U' at 0x008E7F20>, ' C:\projects\Online\repos\testModule.py', ('.py', 'U', 1)) C:\projects\Online\repos> Explanation of the above session: I created an empty module called testModule.py and stored it in c:\projects\Online\repos. Then I wrote the impTest.py script that tries to import it through the BasicModuleLoader. The impTest.py script resides in c:\projects\Online\testsuite directory. If I run the script from the testsuite directory it fails to find the module. If while I am in the testsuite directory I enter the contents of the impTest.py using the Python command line then it finds the module. Also if I run the impTest.py while I am in the repos directory then it finds it as well. In Python 2.2 this had worked in every case. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:27 Message: Logged In: YES user_id=1188172 This is not a fault in ihooks but in the imp module; ihooks just uses this. The difference is that in the interactive interpreter, sys.path contains an empty string (which is equivalent to the current directory), while when executing a file, sys.path contains the absolute path to the .py file. So the path you chdir'd to is not on the module search list. I don't know if that's intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779191&group_id=5470 From noreply at sourceforge.net Wed Jun 1 13:31:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 04:31:44 -0700 Subject: [ python-Bugs-779191 ] BasicModuleLoader behaviour in Python 2.3c2 Message-ID: Bugs item #779191, was opened at 2003-07-29 00:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779191&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Selim Tuvi (stuvi) Assigned to: Nobody/Anonymous (nobody) Summary: BasicModuleLoader behaviour in Python 2.3c2 Initial Comment: Hi I am using the BasicModuleLoader class from the ihooks module and noticed that it behaves differently based on whether it is used from a script vs. from the Python command line. Here is the transcript of my session: C:\projects\Online\repos>type testModule.py C:\projects\Online\repos>cd ..\testsuite C:\projects\Online\testsuite>type impTest.py from ihooks import BasicModuleLoader import os os.chdir('../repos') ml = BasicModuleLoader() modstuff = ml.find_module('testModule') print modstuff C:\projects\Online\testsuite>python impTest.py None C:\projects\Online\testsuite>python Python 2.3c2 (#45, Jul 24 2003, 21:23:54) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ihooks import BasicModuleLoader >>> import os >>> os.chdir('../repos') >>> ml = BasicModuleLoader() >>> modstuff = ml.find_module('testModule') >>> print modstuff (<open file 'testModule.py', mode 'U' at 0x008E8F20>, 'testModule.py', ('.py', ' U', 1)) >>> ^Z C:\projects\Online\testsuite>cd ..\repos C:\projects\Online\repos>python ..\testsuite\impTest.py (<open file 'C:\projects\Online\repos\testModule.py', mode 'U' at 0x008E7F20>, ' C:\projects\Online\repos\testModule.py', ('.py', 'U', 1)) C:\projects\Online\repos> Explanation of the above session: I created an empty module called testModule.py and stored it in c:\projects\Online\repos. Then I wrote the impTest.py script that tries to import it through the BasicModuleLoader. The impTest.py script resides in c:\projects\Online\testsuite directory. If I run the script from the testsuite directory it fails to find the module. If while I am in the testsuite directory I enter the contents of the impTest.py using the Python command line then it finds the module. Also if I run the impTest.py while I am in the repos directory then it finds it as well. In Python 2.2 this had worked in every case. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:31 Message: Logged In: YES user_id=1188172 This is not a fault in ihooks but in the imp module; ihooks just uses this. The difference is that in the interactive interpreter, sys.path contains an empty string (which is equivalent to the current directory), while when executing a file, sys.path contains the absolute path to the .py file. So the path you chdir'd to is not on the module search list. I don't know if that's intended behaviour. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:27 Message: Logged In: YES user_id=1188172 This is not a fault in ihooks but in the imp module; ihooks just uses this. The difference is that in the interactive interpreter, sys.path contains an empty string (which is equivalent to the current directory), while when executing a file, sys.path contains the absolute path to the .py file. So the path you chdir'd to is not on the module search list. I don't know if that's intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779191&group_id=5470 From noreply at sourceforge.net Wed Jun 1 13:36:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 04:36:55 -0700 Subject: [ python-Bugs-770997 ] memory leak in pickle/cPickle [2.2.3] Message-ID: Bugs item #770997, was opened at 2003-07-14 17:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770997&group_id=5470 Please note that this message will contain 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.2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in pickle/cPickle [2.2.3] Initial Comment: Smallest case I could come up with: import cPickle import random while 1: s = str(random.randint(1000000, 9999999)) a = cPickle.dumps(s) cPickle.loads(a) The leak happens in these cases: * Python 2.2.2 on FreeBSD 5.0. * Python 2.2.3 on WinXP. * Whether you use pickle or cPickle. The leak does NOT happen: * With Python 2.3b2 on FreeBSD 5.0 (maybe this is a dup of a bug fixed on 2.3b2 -- can we back-port the fix?) * If you use binary pickling (change to "a = cPickle.dumps(s, 1)" instead). * If you only call "dumps" or only call "loads"; somehow, it takes both to leak. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:36 Message: Logged In: YES user_id=1188172 Doesn't seem to occur in 2.3.5, or 2.4.1. Closing as Out of Date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770997&group_id=5470 From noreply at sourceforge.net Wed Jun 1 13:57:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 04:57:51 -0700 Subject: [ python-Bugs-906405 ] Build fails on XP Message-ID: Bugs item #906405, was opened at 2004-02-28 12:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470 Please note that this 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Con (shrodingersdog) Assigned to: Nobody/Anonymous (nobody) Summary: Build fails on XP Initial Comment: When trying to build the source: Modules/posixmodule.c fails to build. I'm running on XP SP1 using mingw32-make ver 3.80 Is there any known issues on XP? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 13:57 Message: Logged In: YES user_id=1188172 Is this still happening with 2.3.5 or 2.4.1? ---------------------------------------------------------------------- Comment By: Con (shrodingersdog) Date: 2004-05-01 12:52 Message: Logged In: YES user_id=986333 Sorry, crash is not the right word. I've attached the output from make. Let me know if that helps or if you need other info. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-24 10:08 Message: Logged In: YES user_id=21627 What exactly does "it crashes" mean? Do you get a blue screen? Is your hard disk making a crashing sound? ---------------------------------------------------------------------- Comment By: Con (shrodingersdog) Date: 2004-04-23 11:27 Message: Logged In: YES user_id=986333 When I run make it crashes when it gets to Modules/posixmodule.c. This is compiling with the Ming / (Cygwin?) compiler though. I have recently tried with MSVC 6 which builds without any problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-30 00:35 Message: Logged In: YES user_id=21627 In what way precisely does it fail? It builds fine for me with VC.NET 2003, which is the official build environment for Python on XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470 From noreply at sourceforge.net Wed Jun 1 14:10:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 05:10:55 -0700 Subject: [ python-Bugs-893549 ] skipitem() in getargs.c missing some types Message-ID: Bugs item #893549, was opened at 2004-02-09 18:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 Please note that this message will contain 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 From noreply at sourceforge.net Wed Jun 1 14:17:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 05:17:31 -0700 Subject: [ python-Bugs-875157 ] file.read returns reaches EOF when it shouldn't Message-ID: Bugs item #875157, was opened at 2004-01-11 23:37 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875157&group_id=5470 Please note that this message will contain 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.2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Joshua Allen (turingcomplete) Assigned to: Nobody/Anonymous (nobody) Summary: file.read returns reaches EOF when it shouldn't Initial Comment: If the first byte of a file is 0xFF file.read(size) will return an empty string. Problem found while trying to process binary file produced by another system. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:17 Message: Logged In: YES user_id=1188172 I think this can be closed due to lack of response. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-12 00:57 Message: Logged In: YES user_id=31435 turingcomplete, please say which version of Python you're using, which operating system, and show the actual code you use to open the file and read from it. Else this one is just too hard to believe -- if there were a general problem like this, it would have been reported many times. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 23:50 Message: Logged In: YES user_id=80475 I tried it an Py2.2.3, Py2.3.3, and Py2.4a0 and it works fine. Perhaps you have some other problem. >>> f = open('/pydev/hello.bin', 'rb') >>> f.read(6) '\xffhello' The docstring for file.read does warn that sometimes fewer bytes than requested can be returned in a non-blocking mode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875157&group_id=5470 From noreply at sourceforge.net Wed Jun 1 14:24:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 05:24:41 -0700 Subject: [ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output Message-ID: Bugs item #761452, was opened at 2003-06-26 23:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 Please note that this message will contain 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Walsh (rjwalsh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser chokes on my.yahoo.com output Initial Comment: The HTML parser chokes on the output produced by http://my.yahoo.com/. The problem appears to be that the HTML Yahoo is producing contains stuff like this: <option foo bar=> The bar= without any value causes HTMLParser to get confused. I made the following patch to HTMLParser.py and everything is now happy. This may be illegal HTML, but it appears to be popular. Basically, this patch tells it that the part after the = is optional. --- HTMLParser.py.orig 2003-06-26 14:05:07.670049324 -0700 +++ HTMLParser.py 2003-06-26 14:05:14.440298260 -0700 @@ -36,7 +36,7 @@ (?:'[^']*' # LITA-enclosed value |\"[^\"]*\" # LIT-enclosed value |[^'\">\s]+ # bare value - ) + )? )? ) )* ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:24 Message: Logged In: YES user_id=1188172 Should it be applied, then? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 17:49 Message: Logged In: YES user_id=6380 Here it is (a one-char change). Looks harmless to me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 04:55 Message: Logged In: YES user_id=33168 It's difficult to read the patch as posted since whitespace is lost. Please attach the patch as a file. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 From noreply at sourceforge.net Wed Jun 1 14:26:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 05:26:24 -0700 Subject: [ python-Bugs-792570 ] SimpleXMLRPCServer cannot handle large requests Message-ID: Bugs item #792570, was opened at 2003-08-21 17:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 Please note that this message will contain 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marc-Andr? Morissette (morissette) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer cannot handle large requests Initial Comment: SimpleXMLRPCServer throws a WSAEINTR ioerror on large XML-RPC requests. Under Windows, the socket.read() method cannot seem to handle large (tens of megabytes) reads (could be a Python specific problem). This means that very large XML-RPC requests can cause the exception. Here is a tentative patch against 2.2.3 to fix the problem. It should be easy to port it to 2.3 --- /cygdrive/c/Python22/Lib/SimpleXMLRPCServer.py 2003-07-09 14:16:52.000000000 -0400 +++ /cygdrive/z/SimpleXMLRPCServer.py 2003-08-21 11:01:19.000000000 -0400 @@ -73,6 +73,8 @@ import SocketServer import BaseHTTPServer import sys +import cStringIO class SimpleXMLRPCRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler): """Simple XML-RPC request handler class. @@ -95,7 +97,14 @@ try: # get arguments - data = self.rfile.read(int(self.headers["content- length"])) + max_chunk_size = 10000000 + content_length = int(self.headers["content- length"]) + buffer = cStringIO.StringIO() + for offset in range(0, content_length, max_chunk_size): + chunk_size = min(content_length - offset, max_chunk_size) + buffer.write(self.rfile.read(chunk_size)) + data = buffer.getvalue() + buffer.close() params, method = xmlrpclib.loads(data) # generate response ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:26 Message: Logged In: YES user_id=1188172 Marc-Andre, can you still reproduce this with Python 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 From noreply at sourceforge.net Wed Jun 1 15:05:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 06:05:50 -0700 Subject: [ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform? Message-ID: Bugs item #1212703, was opened at 2005-06-01 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vincent Jamart (ranma) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 CVS broken for HP-UX platform? Initial Comment: While trying to compile Python 2.5 from the nighlty CVS image, it raises the following errors on HP-UX. (OS version= HP-UX 11.22 on ia64, compiler= aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]) Compilation flags: export CC=aCC export CFLAGS="-Ae +DD64" export LDFLAGS="+DD64" make clean ./configure --prefix=/usr/local/python_cvs --with-cxx=aCC (...) creating Makefile aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 From noreply at sourceforge.net Wed Jun 1 17:28:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 08:28:36 -0700 Subject: [ python-Bugs-1194249 ] Minor bug in urllib docs Message-ID: Bugs item #1194249, was opened at 2005-05-03 02:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: A.M. Kuchling (akuchling) Summary: Minor bug in urllib docs Initial Comment: The urllib docs contain an example which starts as follows: # Use http://www.someproxy.com:3128 for http proxying proxies = proxies={'http': 'http://www.someproxy.com:3128'} filehandle = urllib.urlopen(some_url, proxies=proxies) The double "proxies=" is most likely a mistake and should be removed. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 11:28 Message: Logged In: YES user_id=11375 Fixed committed to CVS HEAD, and to the 2.4 and 2.3 branches. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194249&group_id=5470 From noreply at sourceforge.net Wed Jun 1 17:40:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 08:40:16 -0700 Subject: [ python-Bugs-1181939 ] asyncore.loop() documentation Message-ID: Bugs item #1181939, was opened at 2005-04-12 22:12 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1181939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Graham (gumleef) >Assigned to: A.M. Kuchling (akuchling) Summary: asyncore.loop() documentation Initial Comment: Document at http://docs.python.org/lib/module-asyncore.html says that the map dictionary is updated in the asyncore class's __init__() method (and to make sure you extend this if you wish to retain this behaviour). This is not the case. The map dictionary is updated by asyncore.create_socket(). asyncore does not need to be extended to retain the mapping behaviour the documentation refers to. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 11:40 Message: Logged In: YES user_id=11375 I've removed the misleading text; thank you for pointing this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1181939&group_id=5470 From noreply at sourceforge.net Wed Jun 1 18:54:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 09:54:22 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Jun 1 19:33:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 10:33:29 -0700 Subject: [ python-Bugs-1212900 ] Python segfaults on OpenBSD (tested 3.4 and 3.5) Message-ID: Bugs item #1212900, was opened at 2005-06-01 17:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults on OpenBSD (tested 3.4 and 3.5) Initial Comment: Here is a minimal case, launch the server and then the client (change the server ip on the client source). Under NetBSD it works as expected, under OpenBSD I get a big segfault at the "ping" time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:07:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:07:51 -0700 Subject: [ python-Bugs-1191726 ] about shift key Message-ID: Bugs item #1191726, was opened at 2005-04-28 16:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191726&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: yang (leeews) Assigned to: Nobody/Anonymous (nobody) Summary: about shift key Initial Comment: I'v wrote the following program ------------------------------------------------------------------------------ from Tkinter import * class KeyDemo(Frame): """""" def __init__(self): """""" Frame.__init__(self) self.pack(expand=YES,fill=BOTH) self.master.title("Demonstrating Keystroke Events") self.master.geometry("350x100") self.message1=StringVar() self.line1=Label(self,textvariable=self.message1) self.message1.set("Type any key or shift") self.line1.pack() self.message2=StringVar() self.line2=Label(self,textvariable=self.message2) self.message2.set("") self.line2.pack() self.master.bind("",self.keyPressed) self.master.bind("",self.keyReleased) self.master.bind("",self.shiftPressed) self.master.bind("",self.shiftReleased) def keyPressed(self,event): """""" self.message1.set("Key pressed: "+ event.char) self.message2.set("This key is not left shift") def keyReleased(self,event): """""" self.message1.set("Key released: "+ event.char) self.message2.set("This key is not left shift") def shiftPressed(self,event): """""" self.message1.set("Shift pressed") self.message2.set("This key is left shift") def shiftReleased(self,event): """""" self.message1.set("Shift released") self.message2.set("This key is left shift") def main(): KeyDemo().mainloop() if __name__=="__main__": main() -------------------------------------------------------------------------- When I pressed right shift , it shows: Key pressed: This key is not left shift And when I released right shift ,it shows: Shift released This key is left shift But what I release is right shift. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:07 Message: Logged In: YES user_id=1188172 I can reproduce this here with Py2.4.1 on WinXP. With Py2.4.1/2.3.5 and Tk 8.4.9 using Linux, there's no problem. Could this be a Tk problem? In any case, updating metadata. ---------------------------------------------------------------------- Comment By: yang (leeews) Date: 2005-04-29 13:47 Message: Logged In: YES user_id=1268579 sorry,I'll be minimize my code sample next time my code had formatted correctly when I edit it,but when I post it , The spaces for format control had disappeared. my platform is python 2.4 /winXP This is the first time I report bug, so I don't know what is the correct way. sorry to trouble you ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-29 02:46 Message: Logged In: YES user_id=971153 This seems like a bug (not a patch) report.. So I guess it might be a good idea to close it and refile as a bug... And a few more suggestions: --try to minimize your code sample --make sure that your sample code is formatted correctly in your post --please indicate what platform/OS you are using ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191726&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:25:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:25:28 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 15:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 11:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:30:33 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:37:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:37:43 -0700 Subject: [ python-Feature Requests-1200804 ] enhancing os.chown functionality Message-ID: Feature Requests item #1200804, was opened at 2005-05-12 18:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 Please note that this 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: Closed Resolution: Rejected Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:37 Message: Logged In: YES user_id=1188172 I've create patch #1213031 which includes a note in the docs about this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:41 Message: Logged In: YES user_id=21627 Jeff already provided the right analysis: It *is* currently possibly with os.chown to only change the groupid without specifying the userid: just pass -1 as the userid. The requested feature is already there, so I'm rejecting this request. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-05-19 00:49 Message: Logged In: YES user_id=2772 the posix (os) module is intended as a thin wrapper around operating system services. The chown(2) syscall requires that owner and group both be specified. Possibly an enhanced chownonly/chgrp would find a home in the 'shutil' module. Possibly translating a parameter of None into -1 (which means 'no change') would be accepted as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:51:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:51:36 -0700 Subject: [ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output Message-ID: Bugs item #761452, was opened at 2003-06-26 14:11 Message generated for change (Comment added) made by rjwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 Please note that this message will contain 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Walsh (rjwalsh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser chokes on my.yahoo.com output Initial Comment: The HTML parser chokes on the output produced by http://my.yahoo.com/. The problem appears to be that the HTML Yahoo is producing contains stuff like this: <option foo bar=> The bar= without any value causes HTMLParser to get confused. I made the following patch to HTMLParser.py and everything is now happy. This may be illegal HTML, but it appears to be popular. Basically, this patch tells it that the part after the = is optional. --- HTMLParser.py.orig 2003-06-26 14:05:07.670049324 -0700 +++ HTMLParser.py 2003-06-26 14:05:14.440298260 -0700 @@ -36,7 +36,7 @@ (?:'[^']*' # LITA-enclosed value |\"[^\"]*\" # LIT-enclosed value |[^'\">\s]+ # bare value - ) + )? )? ) )* ---------------------------------------------------------------------- >Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 13:51 Message: Logged In: YES user_id=608672 It's been so long since I looked at this, I don't believe I even have the code any more. It's just a one-character change, though - can you recreate it yourself by just adding the ? character to the end of line 39 in HTMLParser.py. Unless it's moved in the meantime, of course. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 05:24 Message: Logged In: YES user_id=1188172 Should it be applied, then? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 08:49 Message: Logged In: YES user_id=6380 Here it is (a one-char change). Looks harmless to me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 19:55 Message: Logged In: YES user_id=33168 It's difficult to read the patch as posted since whitespace is lost. Please attach the patch as a file. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 From noreply at sourceforge.net Wed Jun 1 22:52:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 13:52:47 -0700 Subject: [ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output Message-ID: Bugs item #761452, was opened at 2003-06-26 14:11 Message generated for change (Comment added) made by rjwalsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 Please note that this message will contain 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Walsh (rjwalsh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser chokes on my.yahoo.com output Initial Comment: The HTML parser chokes on the output produced by http://my.yahoo.com/. The problem appears to be that the HTML Yahoo is producing contains stuff like this: <option foo bar=> The bar= without any value causes HTMLParser to get confused. I made the following patch to HTMLParser.py and everything is now happy. This may be illegal HTML, but it appears to be popular. Basically, this patch tells it that the part after the = is optional. --- HTMLParser.py.orig 2003-06-26 14:05:07.670049324 -0700 +++ HTMLParser.py 2003-06-26 14:05:14.440298260 -0700 @@ -36,7 +36,7 @@ (?:'[^']*' # LITA-enclosed value |\"[^\"]*\" # LIT-enclosed value |[^'\">\s]+ # bare value - ) + )? )? ) )* ---------------------------------------------------------------------- >Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 13:52 Message: Logged In: YES user_id=608672 Crap. Stupid SourceForge bug tracker puts the latest stuff on top - I was replying to the wrong one. The change can be applied, in my opinion. ---------------------------------------------------------------------- Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 13:51 Message: Logged In: YES user_id=608672 It's been so long since I looked at this, I don't believe I even have the code any more. It's just a one-character change, though - can you recreate it yourself by just adding the ? character to the end of line 39 in HTMLParser.py. Unless it's moved in the meantime, of course. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 05:24 Message: Logged In: YES user_id=1188172 Should it be applied, then? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 08:49 Message: Logged In: YES user_id=6380 Here it is (a one-char change). Looks harmless to me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 19:55 Message: Logged In: YES user_id=33168 It's difficult to read the patch as posted since whitespace is lost. Please attach the patch as a file. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761452&group_id=5470 From noreply at sourceforge.net Wed Jun 1 23:07:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 14:07:41 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 15:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 15:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 11:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Jun 1 23:32:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 14:32:37 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 23:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Jun 1 23:39:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 14:39:08 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 00:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:39 Message: Logged In: YES user_id=80475 The current behavior best matches my expectations. One other datapoint, AWK handles it the same way. Recommend closing this as Invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-01 00:19 Message: Logged In: YES user_id=31435 I expect you'll find that, e.g., Perl does the same thing: a "missing" alternative is treated as an empty string, and an empty string always matches. What basis do you have for claiming it should not match (beyond just repeating that it should not )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Wed Jun 1 23:43:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 14:43:08 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 13:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) >Assigned to: M.-A. Lemburg (lemburg) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:43 Message: Logged In: YES user_id=80475 Mark, do you have any thoughts on this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Thu Jun 2 00:59:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 15:59:37 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 05:13 Message generated for change (Comment added) made by karamana You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- >Comment By: Vijay Kumar (karamana) Date: 2005-06-01 22:59 Message: Logged In: YES user_id=404715 I think what you are saying is correct in terms of a formal sense, but it makes sense to distinguish between a useful match and an empty match. May be there can be an additional method isEmptyMatch() in the match object which can be used to detect this. Also this one does not work: Gives a compile error m = re.search("[]","This is a simple sentence") print m wherease this one returns None: m = re.search("[|]","This is a simple sentence") print m So the empty match is not consistent :) (don't know if I should wink ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 21:39 Message: Logged In: YES user_id=80475 The current behavior best matches my expectations. One other datapoint, AWK handles it the same way. Recommend closing this as Invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-01 05:19 Message: Logged In: YES user_id=31435 I expect you'll find that, e.g., Perl does the same thing: a "missing" alternative is treated as an empty string, and an empty string always matches. What basis do you have for claiming it should not match (beyond just repeating that it should not )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Thu Jun 2 01:13:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 16:13:58 -0700 Subject: [ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak Message-ID: Bugs item #1208304, was opened at 2005-05-25 05:20 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Toman (manekcz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2's urlopen() method causes a memory leak Initial Comment: It seems that the urlopen(url) methd of the urllib2 module leaves some undestroyable objects in memory. Please try the following code: ========================== if __name__ == '__main__': import urllib2 a = urllib2.urlopen('http://www.google.com') del a # or a = None or del(a) # check memory on memory leaks import gc gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() for it in gc.garbage: print it ========================== In our code, we're using lots of urlopens in a loop and the number of unreachable objects grows beyond all limits :) We also tried a.close() but it didn't help. You can also try the following: ========================== def print_unreachable_len(): # check memory on memory leaks import gc gc.set_debug(gc.DEBUG_SAVEALL) gc.collect() unreachableL = [] for it in gc.garbage: unreachableL.append(it) return len(str(unreachableL)) if __name__ == '__main__': print "at the beginning", print_unreachable_len() import urllib2 print "after import of urllib2", print_unreachable_len() a = urllib2.urlopen('http://www.google.com') print 'after urllib2.urlopen', print_unreachable_len() del a print 'after del', print_unreachable_len() ========================== We're using WindowsXP with latest patches, Python 2.4 (ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 19:13 Message: Logged In: YES user_id=11375 Confirmed. The objects involved seem to be an HTTPResponse and the socket._fileobject wrapper; the assignment 'r.recv=r.read' around line 1013 of urllib2.py seems to be critical to creating the cycle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470 From noreply at sourceforge.net Thu Jun 2 01:19:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 16:19:10 -0700 Subject: [ python-Bugs-1210326 ] comma separated cookie values Message-ID: Bugs item #1210326, was opened at 2005-05-28 06:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: tvogt (tovo) Assigned to: Nobody/Anonymous (nobody) Summary: comma separated cookie values Initial Comment: According to RFC 2109 "For backward compatibility, the separator in the Cookie header is semi-colon (;) everywhere. A server should also accept comma (,) as the separator between cookie-values for future compatibility." The Cookie standard module does not support this as it should. >>> import Cookie >>> c=Cookie.SimpleCookie() >>> c.load('foo=2, bar=3') >>> print c['foo'].value 2, ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 19:19 Message: Logged In: YES user_id=11375 The updated cookie RFC, RFC 2965, also has this language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470 From noreply at sourceforge.net Thu Jun 2 01:23:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 16:23:08 -0700 Subject: [ python-Bugs-1123268 ] Typo in Curses-Function doc Message-ID: Bugs item #1123268, was opened at 2005-02-15 12:12 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123268&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Aaron C. Spike (acspike) >Assigned to: A.M. Kuchling (akuchling) Summary: Typo in Curses-Function doc Initial Comment: The description of the filter() method on says "This may be used for enabling cgaracter-at-a-time line editing without touching the rest of the screen." cgaracter should likely be character ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 19:23 Message: Logged In: YES user_id=11375 Fixed in HEAD and 2.4 branch. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123268&group_id=5470 From noreply at sourceforge.net Thu Jun 2 01:26:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 16:26:55 -0700 Subject: [ python-Bugs-1121875 ] SMTPHandler argument misdescribed Message-ID: Bugs item #1121875, was opened at 2005-02-13 12:21 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121875&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter (peter2108) >Assigned to: A.M. Kuchling (akuchling) Summary: SMTPHandler argument misdescribed Initial Comment: The documentation for SMTPHandler in the logging module says "The toaddrs should be a list of strings without domain names (That's what the mailhost is for)." which does not seem to be correct. The toaddr should be a list of strings like 'john at somewhere.com'. This occurs in 2.3 and 2.4 documentation. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 19:26 Message: Logged In: YES user_id=11375 This seems to be fixed on the current 2.4 maintenance branch, and in CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121875&group_id=5470 From noreply at sourceforge.net Thu Jun 2 01:33:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 16:33:01 -0700 Subject: [ python-Bugs-1105706 ] incorrect constant names in curses window objects page Message-ID: Bugs item #1105706, was opened at 2005-01-19 23:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105706&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: dcrosta (dcrosta) >Assigned to: A.M. Kuchling (akuchling) Summary: incorrect constant names in curses window objects page Initial Comment: The documentation for the border() function in the curses "Window Objects" page (http://www.python.org/doc/2.3.4/lib/curses-window-objects.html) says that ACS_BRCORNER and ACS_BLCORNER are the defaults for the lower left and right corners, respectively. The curses "Constants" page (http://www.python.org/doc/2.3.4/lib/node218.html) has the correct names, ACS_LRCORNER and ACS_LLCORNER, respectively. My system: Python 2.3.4 on Gentoo GNU/Linux ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 19:33 Message: Logged In: YES user_id=11375 Fixed in 2.4-maint and HEAD. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105706&group_id=5470 From noreply at sourceforge.net Thu Jun 2 02:07:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 17:07:04 -0700 Subject: [ python-Bugs-1152762 ] curses.textpad raises error Message-ID: Bugs item #1152762, was opened at 2005-02-27 01:00 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152762&group_id=5470 Please note that this message will contain 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 Submitted By: John McPherson (jrm21) Assigned to: Nobody/Anonymous (nobody) Summary: curses.textpad raises error Initial Comment: textpad seems to have a bug when you backspace from the start of a line. By default, stripspaces is on, so it tries to skip any spaces on the previous line. But if there are no spaces, it raises a curses error and makes the app quit. Reproduce by: $ python /usr/lib/python2.3/curses/textpad.py type "1234567890" into the textpad press backspace twice. The problem is _end_of_line() function doing "last = last + 1" I think a better way would be to start at the end of the line (last=self.maxx), and skip backwards while "last" is a space: while last > 0 and ascii.ascii(self.win.inch(y, last)) == ascii.SP: last -= 1 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 20:07 Message: Logged In: YES user_id=11375 Thanks for reporting this problem! Skipping backwards doesn't really solve the problem, because the function is supposed to return the index of the last space; even if you go backwards, you still need to increment 'last' by 1 to get the index of the space. I think the fix is to do 'last = min(last+1, self.maxx)', and this is the fix I'll check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152762&group_id=5470 From noreply at sourceforge.net Thu Jun 2 02:12:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 17:12:23 -0700 Subject: [ python-Bugs-1152762 ] curses.textpad raises error Message-ID: Bugs item #1152762, was opened at 2005-02-27 01:00 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John McPherson (jrm21) >Assigned to: A.M. Kuchling (akuchling) Summary: curses.textpad raises error Initial Comment: textpad seems to have a bug when you backspace from the start of a line. By default, stripspaces is on, so it tries to skip any spaces on the previous line. But if there are no spaces, it raises a curses error and makes the app quit. Reproduce by: $ python /usr/lib/python2.3/curses/textpad.py type "1234567890" into the textpad press backspace twice. The problem is _end_of_line() function doing "last = last + 1" I think a better way would be to start at the end of the line (last=self.maxx), and skip backwards while "last" is a space: while last > 0 and ascii.ascii(self.win.inch(y, last)) == ascii.SP: last -= 1 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 20:12 Message: Logged In: YES user_id=11375 Fix committed to 2-4-maint and HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-01 20:07 Message: Logged In: YES user_id=11375 Thanks for reporting this problem! Skipping backwards doesn't really solve the problem, because the function is supposed to return the index of the last space; even if you go backwards, you still need to increment 'last' by 1 to get the index of the space. I think the fix is to do 'last = min(last+1, self.maxx)', and this is the fix I'll check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152762&group_id=5470 From noreply at sourceforge.net Thu Jun 2 07:19:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 22:19:22 -0700 Subject: [ python-Bugs-1183468 ] check for return/yield outside function is wrong Message-ID: Bugs item #1183468, was opened at 2005-04-15 01:53 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: check for return/yield outside function is wrong Initial Comment: The code currently uses c_nestlevel. That's incorrect as this example code demonstrates: >>> class A: ... return ... Traceback (most recent call last): File "", line 1, in TypeError: Error when calling the metaclass bases PyClass_New: dict must be a dictionary Not sure what the fix is but I wanted to file a bug so it doesn't get forgotten. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-02 05:19 Message: Logged In: YES user_id=35752 Fixed by using information about the scope from the symbol table (newcompile.c 1.1.2.108). ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-04-16 22:05 Message: Logged In: YES user_id=699438 Patch 1184418 is (sortof) posted. SF is giving me grief when I try to do it as a real attachment though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183468&group_id=5470 From noreply at sourceforge.net Thu Jun 2 08:49:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Jun 2005 23:49:05 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 07:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-02 08:49 Message: Logged In: YES user_id=1188172 Your example is wrong. "[]" is an error because it is an empty character group. "[|]" is a valid character group which matches the literal "|", it is equivalent to r"\|". Between [ and ] most character lose their special meaning. I'm also in favour of the current behaviour, recommend closing. ---------------------------------------------------------------------- Comment By: Vijay Kumar (karamana) Date: 2005-06-02 00:59 Message: Logged In: YES user_id=404715 I think what you are saying is correct in terms of a formal sense, but it makes sense to distinguish between a useful match and an empty match. May be there can be an additional method isEmptyMatch() in the match object which can be used to detect this. Also this one does not work: Gives a compile error m = re.search("[]","This is a simple sentence") print m wherease this one returns None: m = re.search("[|]","This is a simple sentence") print m So the empty match is not consistent :) (don't know if I should wink ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:39 Message: Logged In: YES user_id=80475 The current behavior best matches my expectations. One other datapoint, AWK handles it the same way. Recommend closing this as Invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-01 07:19 Message: Logged In: YES user_id=31435 I expect you'll find that, e.g., Perl does the same thing: a "missing" alternative is treated as an empty string, and an empty string always matches. What basis do you have for claiming it should not match (beyond just repeating that it should not )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Thu Jun 2 13:16:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 04:16:01 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 06:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 16:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 15:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 15:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 11:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Thu Jun 2 13:48:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 04:48:47 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 20:56 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: M.-A. Lemburg (lemburg) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-06-02 13:48 Message: Logged In: YES user_id=38388 A doc-patch would be nice. I don't like the general situation either. Unicode doesn't behave like this and I don't think string.lower() and .upper() should either, but there are users out there who think differently, so we might want to add a parameter which then allows modifying the type of mapping: string.lower(map='ascii') string.upper(map='latin-1') etc. Just an idea. PS: I'll be offline for two weeks now, so don't expect any more comments before then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:43 Message: Logged In: YES user_id=80475 Mark, do you have any thoughts on this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Thu Jun 2 14:37:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 05:37:55 -0700 Subject: [ python-Bugs-1209880 ] doc bug in Lock.acquire Message-ID: Bugs item #1209880, was opened at 2005-05-27 10:04 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Nobody/Anonymous (nobody) Summary: doc bug in Lock.acquire Initial Comment: The docs for the acquire method in both the thread and threading modules are incorrect. They describe an old (insane) version that returned None when called with no argument. It appears that acquire is now sane, and always returns True or False. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 08:37 Message: Logged In: YES user_id=11375 I think the (args==NULL) code path is vestigial and can no longer be executed, because the PyArg_ParseTuple call will fail if args is NULL. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 05:33 Message: Logged In: YES user_id=1188172 It certainly seems that there is a code path in Lock.acquire that can return None, as the following excerpt from Modules/threadmodule.c shows: static PyObject * lock_PyThread_acquire_lock(lockobject *self, PyObject *args) { int i = 1; if (!PyArg_ParseTuple(args, "|i:acquire", &i)) return NULL; Py_BEGIN_ALLOW_THREADS i = PyThread_acquire_lock(self->lock_lock, i); Py_END_ALLOW_THREADS if (args == NULL) { Py_INCREF(Py_None); return Py_None; } else return PyBool_FromLong((long)i); } Nevertheless, a_lock.acquire() still returns true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 From noreply at sourceforge.net Thu Jun 2 14:56:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 05:56:44 -0700 Subject: [ python-Bugs-1213475 ] Queue.qsize() better info about unreliability Message-ID: Bugs item #1213475, was opened at 2005-06-02 15:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: Queue.qsize() better info about unreliability Initial Comment: I know Queues are supposed to be used mostly in threads apps. since they are not banned to apps without threads, I think that | qsize(self) | Return the approximate size of the queue (not reliable!). can be better. You mean not reliable (or unreliable :D) because of threads right? if you mean *GENERALLY* because of when ti goes to next instruction it might have change, then put this not reliable thing in len() too ;) I propose: (urreliable if using threads) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 From noreply at sourceforge.net Thu Jun 2 15:02:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 06:02:53 -0700 Subject: [ python-Bugs-1213475 ] Queue.qsize() better info about unreliability Message-ID: Bugs item #1213475, was opened at 2005-06-02 15:56 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: Queue.qsize() better info about unreliability Initial Comment: I know Queues are supposed to be used mostly in threads apps. since they are not banned to apps without threads, I think that | qsize(self) | Return the approximate size of the queue (not reliable!). can be better. You mean not reliable (or unreliable :D) because of threads right? if you mean *GENERALLY* because of when ti goes to next instruction it might have change, then put this not reliable thing in len() too ;) I propose: (urreliable if using threads) ---------------------------------------------------------------------- >Comment By: Nikos Kouremenos (nkour) Date: 2005-06-02 16:02 Message: Logged In: YES user_id=865368 or better: qsize() :: "Return the approximate size of the queue. Because of multithreading semantics, this number is not reliable." (RexxFi) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 From noreply at sourceforge.net Thu Jun 2 15:41:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 06:41:34 -0700 Subject: [ python-Bugs-1177831 ] (?(id)yes|no) only works when referencing the first group Message-ID: Bugs item #1177831, was opened at 2005-04-06 11:06 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177831&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andr? Malo (ndparker) >Assigned to: A.M. Kuchling (akuchling) Summary: (?(id)yes|no) only works when referencing the first group Initial Comment: (?(id)yes|no) only works when referencing the first group Referencing other marked groups may lead to weird results. The problem is, that the compiler stores the following code: ... (op = GROUPREF_EXISTS) while the matcher expects: ... where group is and is . This is the problematic code in sre_compile.py (1.57): 168 elif op is GROUPREF_EXISTS: 169 emit(OPCODES[op]) 170 emit((av[0]-1)*2) 171 skipyes = _len(code); emit(0) 172 _compile(code, av[1], flags) changing line 170 to emit(av[0]-1) fixes the bug. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 09:41 Message: Logged In: YES user_id=11375 Thank you for your excellent explanation and suggested fix. I've applied the fix to both CVS HEAD and 2.4-maint, and added a test case that exercises groups greater than 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177831&group_id=5470 From noreply at sourceforge.net Thu Jun 2 15:53:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 06:53:08 -0700 Subject: [ python-Bugs-1193001 ] Notation Message-ID: Bugs item #1193001, was opened at 2005-04-30 10:01 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193001&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Mythril (mythrix) >Assigned to: A.M. Kuchling (akuchling) Summary: Notation Initial Comment: In Notation, it says the BNF form used is: name: lc_letter (lc_letter | "_")* lc_letter: "a"..."z" But in the documentation, it is: identifier ::= (letter|"_") (letter | digit | "_")* letter ::= lowercase | uppercase (ie, ::=, and not :) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 09:53 Message: Logged In: YES user_id=11375 The notation section was using a different LaTeX macro from the other grammar rules; I've fixed this on the HEAD and 2.4-maint branches. Thanks for reporting this error! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193001&group_id=5470 From noreply at sourceforge.net Thu Jun 2 18:11:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 09:11:41 -0700 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 20:20 Message generated for change (Comment added) made by nikis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 16:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-14 23:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 08:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 13:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 12:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 10:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Thu Jun 2 19:01:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 10:01:29 -0700 Subject: [ python-Bugs-1209880 ] doc bug in Lock.acquire Message-ID: Bugs item #1209880, was opened at 2005-05-27 10:04 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Perkins (cperkins) >Assigned to: A.M. Kuchling (akuchling) Summary: doc bug in Lock.acquire Initial Comment: The docs for the acquire method in both the thread and threading modules are incorrect. They describe an old (insane) version that returned None when called with no argument. It appears that acquire is now sane, and always returns True or False. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 13:01 Message: Logged In: YES user_id=11375 I've changed the docs on both the HEAD and 2.4-maint branches to only describe the True/False return values. Thanks for your report! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 08:37 Message: Logged In: YES user_id=11375 I think the (args==NULL) code path is vestigial and can no longer be executed, because the PyArg_ParseTuple call will fail if args is NULL. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 05:33 Message: Logged In: YES user_id=1188172 It certainly seems that there is a code path in Lock.acquire that can return None, as the following excerpt from Modules/threadmodule.c shows: static PyObject * lock_PyThread_acquire_lock(lockobject *self, PyObject *args) { int i = 1; if (!PyArg_ParseTuple(args, "|i:acquire", &i)) return NULL; Py_BEGIN_ALLOW_THREADS i = PyThread_acquire_lock(self->lock_lock, i); Py_END_ALLOW_THREADS if (args == NULL) { Py_INCREF(Py_None); return Py_None; } else return PyBool_FromLong((long)i); } Nevertheless, a_lock.acquire() still returns true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470 From noreply at sourceforge.net Thu Jun 2 20:32:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 11:32:31 -0700 Subject: [ python-Feature Requests-1213703 ] Move test_method_checksum from test_unicodedata. Message-ID: Feature Requests item #1213703, was opened at 2005-06-02 18:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 From noreply at sourceforge.net Thu Jun 2 22:47:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 13:47:49 -0700 Subject: [ python-Feature Requests-1213703 ] Move test_method_checksum from test_unicodedata. Message-ID: Feature Requests item #1213703, was opened at 2005-06-02 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-06-02 22:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 From noreply at sourceforge.net Thu Jun 2 23:08:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 14:08:04 -0700 Subject: [ python-Feature Requests-1213703 ] Move test_method_checksum from test_unicodedata. Message-ID: Feature Requests item #1213703, was opened at 2005-06-02 18:32 Message generated for change (Comment added) made by dsuch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? ---------------------------------------------------------------------- >Comment By: Darek Suchojad (dsuch) Date: 2005-06-02 21:08 Message: Logged In: YES user_id=954779 Ah, I get it. I'm trying to port unicodedata to Jython (so far I have almost completed creating its pure-Python version which I will rewrite in Java) and that's how I've discovered this "inconsistency", but I understand your point, so I'll just withdraw my proposal, it was just a thought after all... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-06-02 20:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:33:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:33:46 -0700 Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks Message-ID: Bugs item #1213894, was opened at 2005-06-02 17:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.realpath() cannot handle symlinks Initial Comment: To reproduce: Create a link, say to /tmp: bagira:~/python> ls -l xxx lrwxrwxrwx 1 ilya ilya 4 2005-06-02 17:09 xxx -> /tmp/ And now: bagira:~/python> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.realpath("xxx") '/home/ilya/python/xxx' I'd expect realpath() to return "/tmp" Note: This bug was reported earlier (e.g bug 990669) but it was closed as fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:38:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:38:53 -0700 Subject: [ python-Feature Requests-1213703 ] Move test_method_checksum from test_unicodedata. Message-ID: Feature Requests item #1213703, was opened at 2005-06-02 13:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? ---------------------------------------------------------------------- Comment By: Darek Suchojad (dsuch) Date: 2005-06-02 16:08 Message: Logged In: YES user_id=954779 Ah, I get it. I'm trying to port unicodedata to Jython (so far I have almost completed creating its pure-Python version which I will rewrite in Java) and that's how I've discovered this "inconsistency", but I understand your point, so I'll just withdraw my proposal, it was just a thought after all... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-06-02 15:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:45:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:45:27 -0700 Subject: [ python-Feature Requests-1212169 ] Prepending Text Message-ID: Feature Requests item #1212169, was opened at 2005-05-31 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 19:45 Message: Logged In: YES user_id=80475 All string concatenation in Python creates a new string and leaves the original untouched. So, there are no append operations. Likewise, the can be no prepend operations. Instead, there are only a+b operations whose result can be assigned to 'a' to give the effect of an append, to 'b' to give the effect of a prepend, and to 'c' to create a new variable leaving the inputs untouched. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:48 Message: Logged In: YES user_id=1188172 -0. What's wrong with >>> string = something + string Also, the above conveys the notion that this is an expensive operation (when done multiple times, e.g. in a loop) better than a str method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 From noreply at sourceforge.net Fri Jun 3 02:50:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 17:50:06 -0700 Subject: [ python-Feature Requests-1191699 ] make slices pickable Message-ID: Feature Requests item #1191699, was opened at 2005-04-28 08:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) >Assigned to: Raymond Hettinger (rhettinger) Summary: make slices pickable Initial Comment: As suggested by the summary, provide pickability of slices by default. Currently one has to use copy_reg module to register slices as pickables. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 19:50 Message: Logged In: YES user_id=80475 Okay, sounds reasonable. Will implement when I have time. ---------------------------------------------------------------------- Comment By: Sebastien de Menten (sdementen) Date: 2005-04-30 13:02 Message: Logged In: YES user_id=820079 Use case for pickable slices. Let A be a numeric array of size M x N. We want to consider sub-arrays in this array like A[:4, :] (the first 4 lines of the array). If we want to store both the array and the information of sub-arrays structures, we need to store slices (we can also store start/end indices of the array ... but this is call a slice so it would be better to have pickable slices). In fact, whenever one wants to write generic algorithm working on "sublist of lists" or "subarrays of arrays" or "sub-items of collection of items", it is nicer to use slice objects explicitly and so store them also explicitly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 07:32 Message: Logged In: YES user_id=80475 Use cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470 From noreply at sourceforge.net Fri Jun 3 03:12:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 18:12:37 -0700 Subject: [ python-Feature Requests-1190033 ] The array module and the buffer interface Message-ID: Feature Requests item #1190033, was opened at 2005-04-26 01:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:12 Message: Logged In: YES user_id=80475 +0 It is not unreasonable to want to generalize the interface. OTOH, the str() workaround is trivial and explicit: >>> buf = buffer('abcdefghi', 1, 5) >>> array('b', str(buf)) array('b', [98, 99, 100, 101, 102]) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 07:39 Message: Logged In: YES user_id=341410 I couldn't sleep, so I started working on it. Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it just isn't documented, nor is it exposed via array_new. I've got less than 20 lines of changes that seem to be necessary for array(typecode, buf) to be supported, including documentation and unittest updates. I'll sleep on it (I'm getting tired) and upload it tomorrow. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 01:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 00:20 Message: Logged In: YES user_id=80475 Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 From noreply at sourceforge.net Fri Jun 3 03:25:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 18:25:23 -0700 Subject: [ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function Message-ID: Feature Requests item #1185383, was opened at 2005-04-18 14:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3]Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-04-28 15:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 15:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 From noreply at sourceforge.net Fri Jun 3 03:33:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 18:33:47 -0700 Subject: [ python-Feature Requests-1182143 ] making builtin exceptions more informative Message-ID: Feature Requests item #1182143, was opened at 2005-04-13 06:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: making builtin exceptions more informative Initial Comment: Using builtin exception information is tricky as it consists of: a) the type of exception (easily accessible) b) the args attribute = a 1 element tuple with a string 1st example: try: print foo except NameError, e: print e.args symbol = e.args[0][17:-16] print symbols ==> ("NameError: name 'foo' is not defined", ) foo It would be nicer to have: e.args = ("NameError: name 'foo' is not defined", "foo") The first element being the current string for backward compatibilty. ============================= 2nd example: try: (4).foo except NameError, e: print e.args ==> ("'int' object has no attribute 'foo'",) It would be nicer to have: e.args = ("'int' object has no attribute 'foo'", 4, "foo") Again, the first element being the current string for backward compatibilty. ============================= Moreover, in the documentation about Exception, I read """Warning: Messages to exceptions are not part of the Python API. Their contents may change from one version of Python to the next without warning and should not be relied on by code which will run under multiple versions of the interpreter. """ So even args could not be relied upon ! But it also means that there is no need to be backward compatible (I am playing devil's advocate, backward compatibility is important !) Seb ps: There may be problems (that I am not aware) with a) an exception keeping references to other objects b) C API that can throw only exceptions with strings c) a specific advantage of having strings only in builtin exceptions ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:33 Message: Logged In: YES user_id=80475 This looks like a good idea to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&group_id=5470 From noreply at sourceforge.net Fri Jun 3 03:34:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 18:34:53 -0700 Subject: [ python-Feature Requests-1163139 ] expm1 and log1p Message-ID: Feature Requests item #1163139, was opened at 2005-03-14 12:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:34 Message: Logged In: YES user_id=80475 For the reasons mentioned by Tim, closing this RFE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-03-14 13:20 Message: Logged In: YES user_id=31435 Python code intends to be portable, and the math module hasn't yet included any platform-specific functions. I used to write math libraries for a living, so I know about netlib . If that's the intended approach to portability , it still needs someone to volunteer to do all the non-trivial coding, testing, doc, license-hassling, and x-platform config work. Won't be me because I can't make time for it. Note that you could easily write an extension module exposing these functions on _your_ platform (assuming your platform C supplies them). ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2005-03-14 12:59 Message: Logged In: YES user_id=888261 Is there an objection in principle to including something in the math module only if it is found in the system's libm? If so, a solution would be to use a C implementation of expm1 when it is not already supplied, for example from fdlibm: http://www.netlib.org/fdlibm/ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-03-14 12:39 Message: Logged In: YES user_id=31435 Hard one, since none of those functions are required by the C89 standard, Python doesn't require more than C89, and the math module overwhelmingly consists of thin wrappers around the platform C's implementations. When C99 is universally available, then it will be easy. Before then, someone would have to volunteer non-trivial work (for example, Microsoft's C runtime doesn't supply any of these -- it's a x-platform mess). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 From noreply at sourceforge.net Fri Jun 3 03:38:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 18:38:55 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-03 13:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-01 07:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Fri Jun 3 04:02:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 19:02:41 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 15:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Fri Jun 3 04:04:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 19:04:45 -0700 Subject: [ python-Feature Requests-1190033 ] The array module and the buffer interface Message-ID: Feature Requests item #1190033, was opened at 2005-04-25 23:59 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-02 19:04 Message: Logged In: YES user_id=341410 I had assumed str(buf) copied the contents of the buffer, but I was mistaken (read the source Josiah). As I stated in my previous post, array.fromstring takes buffer objects, so the documentation should be updated in that case, which I can do if desired. Honestly, I am also +0 on the patch. I think it is convenient for completeness sake, but with array.fromstring, and str(buf) being fast, it isn't necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 18:12 Message: Logged In: YES user_id=80475 +0 It is not unreasonable to want to generalize the interface. OTOH, the str() workaround is trivial and explicit: >>> buf = buffer('abcdefghi', 1, 5) >>> array('b', str(buf)) array('b', [98, 99, 100, 101, 102]) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 05:39 Message: Logged In: YES user_id=341410 I couldn't sleep, so I started working on it. Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it just isn't documented, nor is it exposed via array_new. I've got less than 20 lines of changes that seem to be necessary for array(typecode, buf) to be supported, including documentation and unittest updates. I'll sleep on it (I'm getting tired) and upload it tomorrow. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-27 23:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-27 22:20 Message: Logged In: YES user_id=80475 Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 From noreply at sourceforge.net Fri Jun 3 08:03:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 23:03:45 -0700 Subject: [ python-Feature Requests-1182143 ] making builtin exceptions more informative Message-ID: Feature Requests item #1182143, was opened at 2005-04-13 13:02 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: making builtin exceptions more informative Initial Comment: Using builtin exception information is tricky as it consists of: a) the type of exception (easily accessible) b) the args attribute = a 1 element tuple with a string 1st example: try: print foo except NameError, e: print e.args symbol = e.args[0][17:-16] print symbols ==> ("NameError: name 'foo' is not defined", ) foo It would be nicer to have: e.args = ("NameError: name 'foo' is not defined", "foo") The first element being the current string for backward compatibilty. ============================= 2nd example: try: (4).foo except NameError, e: print e.args ==> ("'int' object has no attribute 'foo'",) It would be nicer to have: e.args = ("'int' object has no attribute 'foo'", 4, "foo") Again, the first element being the current string for backward compatibilty. ============================= Moreover, in the documentation about Exception, I read """Warning: Messages to exceptions are not part of the Python API. Their contents may change from one version of Python to the next without warning and should not be relied on by code which will run under multiple versions of the interpreter. """ So even args could not be relied upon ! But it also means that there is no need to be backward compatible (I am playing devil's advocate, backward compatibility is important !) Seb ps: There may be problems (that I am not aware) with a) an exception keeping references to other objects b) C API that can throw only exceptions with strings c) a specific advantage of having strings only in builtin exceptions ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-06-03 08:03 Message: Logged In: YES user_id=89016 +1 This should probably be part of Brett's Py3000 exception PEP. Candidates I can think of are: KeyError(obj=..., key=...) IndexError(obj=..., index=...) IOError(file=..., code=...) NameError(name=...) Regenerating the message would be done with __str__(). I'm not sure how this would work on the level of the C API. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 03:33 Message: Logged In: YES user_id=80475 This looks like a good idea to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&group_id=5470 From noreply at sourceforge.net Fri Jun 3 08:42:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 23:42:57 -0700 Subject: [ python-Feature Requests-1190033 ] The array module and the buffer interface Message-ID: Feature Requests item #1190033, was opened at 2005-04-26 01:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 01:42 Message: Logged In: YES user_id=80475 I recommend dropping this one and leaving the API alone. The improvement would be so small that it isn't worth the time to review it, test it, and introduce another version incompatability (something that runs on Py2.5 that won't run on Py2.4). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-02 21:04 Message: Logged In: YES user_id=341410 I had assumed str(buf) copied the contents of the buffer, but I was mistaken (read the source Josiah). As I stated in my previous post, array.fromstring takes buffer objects, so the documentation should be updated in that case, which I can do if desired. Honestly, I am also +0 on the patch. I think it is convenient for completeness sake, but with array.fromstring, and str(buf) being fast, it isn't necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:12 Message: Logged In: YES user_id=80475 +0 It is not unreasonable to want to generalize the interface. OTOH, the str() workaround is trivial and explicit: >>> buf = buffer('abcdefghi', 1, 5) >>> array('b', str(buf)) array('b', [98, 99, 100, 101, 102]) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 07:39 Message: Logged In: YES user_id=341410 I couldn't sleep, so I started working on it. Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it just isn't documented, nor is it exposed via array_new. I've got less than 20 lines of changes that seem to be necessary for array(typecode, buf) to be supported, including documentation and unittest updates. I'll sleep on it (I'm getting tired) and upload it tomorrow. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 01:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 00:20 Message: Logged In: YES user_id=80475 Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 From noreply at sourceforge.net Fri Jun 3 08:50:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Jun 2005 23:50:42 -0700 Subject: [ python-Feature Requests-1190033 ] The array module and the buffer interface Message-ID: Feature Requests item #1190033, was opened at 2005-04-25 23:59 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-02 23:50 Message: Logged In: YES user_id=341410 Sounds reasonable. What about updating the documentation for array.fromstring() to acknowledge that it accepts buffer objects, or do we call it an 'undocumented and untested bonus feature'? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 23:42 Message: Logged In: YES user_id=80475 I recommend dropping this one and leaving the API alone. The improvement would be so small that it isn't worth the time to review it, test it, and introduce another version incompatability (something that runs on Py2.5 that won't run on Py2.4). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-02 19:04 Message: Logged In: YES user_id=341410 I had assumed str(buf) copied the contents of the buffer, but I was mistaken (read the source Josiah). As I stated in my previous post, array.fromstring takes buffer objects, so the documentation should be updated in that case, which I can do if desired. Honestly, I am also +0 on the patch. I think it is convenient for completeness sake, but with array.fromstring, and str(buf) being fast, it isn't necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 18:12 Message: Logged In: YES user_id=80475 +0 It is not unreasonable to want to generalize the interface. OTOH, the str() workaround is trivial and explicit: >>> buf = buffer('abcdefghi', 1, 5) >>> array('b', str(buf)) array('b', [98, 99, 100, 101, 102]) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 05:39 Message: Logged In: YES user_id=341410 I couldn't sleep, so I started working on it. Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it just isn't documented, nor is it exposed via array_new. I've got less than 20 lines of changes that seem to be necessary for array(typecode, buf) to be supported, including documentation and unittest updates. I'll sleep on it (I'm getting tired) and upload it tomorrow. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-27 23:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-27 22:20 Message: Logged In: YES user_id=80475 Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 From noreply at sourceforge.net Fri Jun 3 09:58:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 00:58:48 -0700 Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks Message-ID: Bugs item #1213894, was opened at 2005-06-03 02:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) >Assigned to: Raymond Hettinger (rhettinger) Summary: os.path.realpath() cannot handle symlinks Initial Comment: To reproduce: Create a link, say to /tmp: bagira:~/python> ls -l xxx lrwxrwxrwx 1 ilya ilya 4 2005-06-02 17:09 xxx -> /tmp/ And now: bagira:~/python> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.realpath("xxx") '/home/ilya/python/xxx' I'd expect realpath() to return "/tmp" Note: This bug was reported earlier (e.g bug 990669) but it was closed as fixed ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 09:58 Message: Logged In: YES user_id=1188172 Confirmed. Only occurs when the symlink is the first directory part of the argument. Attaching fix, assigning to Raymond to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 From noreply at sourceforge.net Fri Jun 3 10:01:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 01:01:11 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 13:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 23:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Fri Jun 3 10:17:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 01:17:44 -0700 Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks Message-ID: Bugs item #1213894, was opened at 2005-06-03 02:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Raymond Hettinger (rhettinger) Summary: os.path.realpath() cannot handle symlinks Initial Comment: To reproduce: Create a link, say to /tmp: bagira:~/python> ls -l xxx lrwxrwxrwx 1 ilya ilya 4 2005-06-02 17:09 xxx -> /tmp/ And now: bagira:~/python> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.realpath("xxx") '/home/ilya/python/xxx' I'd expect realpath() to return "/tmp" Note: This bug was reported earlier (e.g bug 990669) but it was closed as fixed ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:17 Message: Logged In: YES user_id=1188172 Attaching new test case for this problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 09:58 Message: Logged In: YES user_id=1188172 Confirmed. Only occurs when the symlink is the first directory part of the argument. Attaching fix, assigning to Raymond to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 From noreply at sourceforge.net Fri Jun 3 12:52:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 03:52:36 -0700 Subject: [ python-Feature Requests-1190033 ] The array module and the buffer interface Message-ID: Feature Requests item #1190033, was opened at 2005-04-26 01:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: The array module and the buffer interface Initial Comment: It would be terribly convenient if array objects were willing to take any object supporting the buffer interface as initialization or extension via a.fromstring(). They currently offer the buffer interface for other objects to read/write once the array has been created, but they do not accept buffers during creation or extension (except for the typecode 'c'). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 05:52 Message: Logged In: YES user_id=80475 No need for a doc update either. The docs rarely make promises about the substitutability of lookalike objects. For instance, almost nothing that accepts a file argument documents accepting StringIO objects or other lookalikes. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-03 01:50 Message: Logged In: YES user_id=341410 Sounds reasonable. What about updating the documentation for array.fromstring() to acknowledge that it accepts buffer objects, or do we call it an 'undocumented and untested bonus feature'? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 01:42 Message: Logged In: YES user_id=80475 I recommend dropping this one and leaving the API alone. The improvement would be so small that it isn't worth the time to review it, test it, and introduce another version incompatability (something that runs on Py2.5 that won't run on Py2.4). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-02 21:04 Message: Logged In: YES user_id=341410 I had assumed str(buf) copied the contents of the buffer, but I was mistaken (read the source Josiah). As I stated in my previous post, array.fromstring takes buffer objects, so the documentation should be updated in that case, which I can do if desired. Honestly, I am also +0 on the patch. I think it is convenient for completeness sake, but with array.fromstring, and str(buf) being fast, it isn't necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:12 Message: Logged In: YES user_id=80475 +0 It is not unreasonable to want to generalize the interface. OTOH, the str() workaround is trivial and explicit: >>> buf = buffer('abcdefghi', 1, 5) >>> array('b', str(buf)) array('b', [98, 99, 100, 101, 102]) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 07:39 Message: Logged In: YES user_id=341410 I couldn't sleep, so I started working on it. Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it just isn't documented, nor is it exposed via array_new. I've got less than 20 lines of changes that seem to be necessary for array(typecode, buf) to be supported, including documentation and unittest updates. I'll sleep on it (I'm getting tired) and upload it tomorrow. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-04-28 01:37 Message: Logged In: YES user_id=341410 Not right now, but I could probably have one for you tomorrow. You want doc updates and tests too? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 00:20 Message: Logged In: YES user_id=80475 Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470 From noreply at sourceforge.net Fri Jun 3 13:27:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 04:27:21 -0700 Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks Message-ID: Bugs item #1213894, was opened at 2005-06-02 19:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Submitted By: Ilya Sandler (isandler) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.path.realpath() cannot handle symlinks Initial Comment: To reproduce: Create a link, say to /tmp: bagira:~/python> ls -l xxx lrwxrwxrwx 1 ilya ilya 4 2005-06-02 17:09 xxx -> /tmp/ And now: bagira:~/python> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.realpath("xxx") '/home/ilya/python/xxx' I'd expect realpath() to return "/tmp" Note: This bug was reported earlier (e.g bug 990669) but it was closed as fixed ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 06:27 Message: Logged In: YES user_id=80475 Run the full testsuite, then go ahead an apply the patch. Be sure to add an entry to Misc/NEWS. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 03:17 Message: Logged In: YES user_id=1188172 Attaching new test case for this problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 02:58 Message: Logged In: YES user_id=1188172 Confirmed. Only occurs when the symlink is the first directory part of the argument. Attaching fix, assigning to Raymond to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 From noreply at sourceforge.net Fri Jun 3 13:56:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 04:56:36 -0700 Subject: [ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++ Message-ID: Bugs item #1205568, was opened at 2005-05-20 07:05 Message generated for change (Comment added) made by rzigweid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. ---------------------------------------------------------------------- >Comment By: Robert M. Zigweid (rzigweid) Date: 2005-06-03 07:56 Message: Logged In: YES user_id=554287 Firstly, exposing this bug, I discovred, also requires passing --with- pydebug=true. It's fine if you don't compile with pydebug. I'm sorry I did not mention/realize that initially. Secondly in response to loewis comment. It looks like linking with g++ instead of gcc as you eluded to takes care of the problem. Ilyria% gcc -u _PyMac_Error -o python.exe > Modules/ccpython.o > libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status Ilyria ~/src/Python-2.4.1 05-06-03 7:53AM [gcc -u _PyMac_Error -o python.exe \n Modules/ccpython.o \n libpython2.4.a -ldl ] Ilyria% g++ -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl Ilyria ~/src/Python-2.4.1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 17:13 Message: Logged In: YES user_id=21627 Can you check whether just linking with g++ (instead of linking with gcc, and still not adding -lSystem) also solves the problem? configure is supposed to detect that g++ is needed for linking; if linking with g++ solves the problem, then configure.in must be enhanced to properly auto-detect this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 From noreply at sourceforge.net Fri Jun 3 16:32:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 07:32:45 -0700 Subject: [ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks Message-ID: Bugs item #1213894, was opened at 2005-06-03 02:33 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.path.realpath() cannot handle symlinks Initial Comment: To reproduce: Create a link, say to /tmp: bagira:~/python> ls -l xxx lrwxrwxrwx 1 ilya ilya 4 2005-06-02 17:09 xxx -> /tmp/ And now: bagira:~/python> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.realpath("xxx") '/home/ilya/python/xxx' I'd expect realpath() to return "/tmp" Note: This bug was reported earlier (e.g bug 990669) but it was closed as fixed ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 16:32 Message: Logged In: YES user_id=1188172 Fixed, thanks for the report. Lib/posixpath.py r1.74 r1.73.2.1 Lib/test/test_posixpath.py r1.13 r1.12.2.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 13:27 Message: Logged In: YES user_id=80475 Run the full testsuite, then go ahead an apply the patch. Be sure to add an entry to Misc/NEWS. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:17 Message: Logged In: YES user_id=1188172 Attaching new test case for this problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 09:58 Message: Logged In: YES user_id=1188172 Confirmed. Only occurs when the symlink is the first directory part of the argument. Attaching fix, assigning to Raymond to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&group_id=5470 From noreply at sourceforge.net Fri Jun 3 16:53:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 07:53:11 -0700 Subject: [ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)" Message-ID: Bugs item #1212411, was opened at 2005-06-01 01:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Vijay Kumar (karamana) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Incorrect result for regular expression - "|(hello)|(world)" Initial Comment: The regular expression "|hello|world" incorrectly gives a match, owing to the starting '|'. Below is a sample program which highlights this. The correct result behavior is to return None: If the leading '|' is removed then the result is correct. ----- import re m = re.search("|hello|world","This is a simple sentence") print m m2 = re.search("hello|world","This is a simple sentence") print m2 ---- output --- <_sre.SRE_Match object at 0x00B71F70> None ---------- The first one is incorrect. Should have returned a None. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-06-03 10:53 Message: Logged In: YES user_id=31435 I'm closing this as not-a-bug. The current behavior makes sense, matches how other regexp packages work, and can't be changed regardless without breaking existing code. Note that (mid|)night isn't the same as (mid)?night in the case where "mid" doesn't match. That's one reason the first form actually gets used (in the first form group 1 matches an empty string, in the second form group 1 doesn't match at all). As birkenfeld said, character classes are entirely different gimmicks. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-02 02:49 Message: Logged In: YES user_id=1188172 Your example is wrong. "[]" is an error because it is an empty character group. "[|]" is a valid character group which matches the literal "|", it is equivalent to r"\|". Between [ and ] most character lose their special meaning. I'm also in favour of the current behaviour, recommend closing. ---------------------------------------------------------------------- Comment By: Vijay Kumar (karamana) Date: 2005-06-01 18:59 Message: Logged In: YES user_id=404715 I think what you are saying is correct in terms of a formal sense, but it makes sense to distinguish between a useful match and an empty match. May be there can be an additional method isEmptyMatch() in the match object which can be used to detect this. Also this one does not work: Gives a compile error m = re.search("[]","This is a simple sentence") print m wherease this one returns None: m = re.search("[|]","This is a simple sentence") print m So the empty match is not consistent :) (don't know if I should wink ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 17:39 Message: Logged In: YES user_id=80475 The current behavior best matches my expectations. One other datapoint, AWK handles it the same way. Recommend closing this as Invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-01 01:19 Message: Logged In: YES user_id=31435 I expect you'll find that, e.g., Perl does the same thing: a "missing" alternative is treated as an empty string, and an empty string always matches. What basis do you have for claiming it should not match (beyond just repeating that it should not )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470 From noreply at sourceforge.net Fri Jun 3 17:13:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 08:13:43 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-03 10:13 Message: Logged In: YES user_id=44345 Can you elaborate? I fail to see what the string module has to do with the re module. Can you give an example of code that would break? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 03:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 06:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 16:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 15:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 15:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 11:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:00:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:00:42 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:00 Message: Logged In: YES user_id=1188172 Raymond said that braces should always be considered special. This includes constructs like "{(?P.*)}" which the string module uses, and which would be a syntax error then. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-03 17:13 Message: Logged In: YES user_id=44345 Can you elaborate? I fail to see what the string module has to do with the re module. Can you give an example of code that would break? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 13:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 23:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:09:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:09:26 -0700 Subject: [ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path Message-ID: Bugs item #1209447, was opened at 2005-05-26 22:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() fails if 2nd arg is a UNC path Initial Comment: os.path.join('c:', r'\server\share') returns c:\server\share rather than \server\share. Interestingly os.path.join('c:a', r'\server\share') returns r'\server\share'. IMHO, r'\server\share' should be returned in all cases. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:09 Message: Logged In: YES user_id=1188172 I'd recommend not to change the behaviour, but add a note in the docs that UNCs are not recognized as such in os.path.join. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 12:25 Message: Logged In: YES user_id=1188172 This is a difficult issue, since as far as I recall Windows allows two or more backslashes in a row in the middle of normal paths. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:16:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:16:19 -0700 Subject: [ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly Message-ID: Bugs item #1194181, was opened at 2005-05-03 04:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 Please note that this message will contain 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: 8 Submitted By: Bob Ippolito (etrepum) >Assigned to: Raymond Hettinger (rhettinger) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:16 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:18:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:18:28 -0700 Subject: [ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++ Message-ID: Bugs item #1205568, was opened at 2005-05-20 13:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-06-03 20:18 Message: Logged In: YES user_id=21627 Ok. configure should have detected that you need g++ to link. To do so, it compiles the program void foo();int main(){foo();}void foo(){} with g++ (g++ -c), then links the object file with gcc. If that fails, it concludes that g++ is needed. Can you please a) confirm that this specific procedure indeed links correctly, and b) experiment to find out what changes to the program need to be made so that it fails to link because of ___gxx_personality_v0 ? To analyse b), a number of issues have to be considered: it may be that more include files are needed in the test program, it may be that other compiler flags need to be passed, and it may be that more code needs to be added. If you cannot easily make the test case fail, please try to reduce Modules/ccpython so that moves towards the test code. ---------------------------------------------------------------------- Comment By: Robert M. Zigweid (rzigweid) Date: 2005-06-03 13:56 Message: Logged In: YES user_id=554287 Firstly, exposing this bug, I discovred, also requires passing --with- pydebug=true. It's fine if you don't compile with pydebug. I'm sorry I did not mention/realize that initially. Secondly in response to loewis comment. It looks like linking with g++ instead of gcc as you eluded to takes care of the problem. Ilyria% gcc -u _PyMac_Error -o python.exe > Modules/ccpython.o > libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status Ilyria ~/src/Python-2.4.1 05-06-03 7:53AM [gcc -u _PyMac_Error -o python.exe \n Modules/ccpython.o \n libpython2.4.a -ldl ] Ilyria% g++ -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl Ilyria ~/src/Python-2.4.1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 23:13 Message: Logged In: YES user_id=21627 Can you check whether just linking with g++ (instead of linking with gcc, and still not adding -lSystem) also solves the problem? configure is supposed to detect that g++ is needed for linking; if linking with g++ solves the problem, then configure.in must be enhanced to properly auto-detect this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:23:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:23:59 -0700 Subject: [ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly Message-ID: Bugs item #1194181, was opened at 2005-05-02 22:39 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 Please note that this message will contain 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: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Raymond Hettinger (rhettinger) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-03 14:23 Message: Logged In: YES user_id=139309 It should still be OK to check in. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 14:16 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:24:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:24:32 -0700 Subject: [ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows Message-ID: Bugs item #1190204, was opened at 2005-04-26 14:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 Please note that this 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 Submitted By: Kent Johnson (kjohnson) >Assigned to: Raymond Hettinger (rhettinger) Summary: 3.29 site is confusing re site-packages on Windows Initial Comment: Library Reference 3.29 site seems to say that site-packages is only searched on Unix and Mac. The relevant sentence is in the third paragraph: "For the tail part, it uses the empty string (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." A clearer and more accurate wording would be "For the tail part, it uses the empty string and lib/site-python (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." The relevant code is line 187 in site.py. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:24 Message: Logged In: YES user_id=1188172 Fix attached; okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 From noreply at sourceforge.net Fri Jun 3 20:46:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 11:46:05 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 16:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 13:46 Message: Logged In: YES user_id=80475 Hmm, it looks like they cannot be treated differently without breaking backwards compatability. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 13:00 Message: Logged In: YES user_id=1188172 Raymond said that braces should always be considered special. This includes constructs like "{(?P.*)}" which the string module uses, and which would be a syntax error then. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-03 10:13 Message: Logged In: YES user_id=44345 Can you elaborate? I fail to see what the string module has to do with the re module. Can you give an example of code that would break? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 03:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 06:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 16:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 16:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 15:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 15:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 11:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Fri Jun 3 21:10:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 12:10:52 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 21:10 Message: Logged In: YES user_id=1188172 Then, I think, we should follow Perl's behaviour and treat "{}" as a literal, just like every other brace construct that isn't a repeat specifier. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 20:46 Message: Logged In: YES user_id=80475 Hmm, it looks like they cannot be treated differently without breaking backwards compatability. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:00 Message: Logged In: YES user_id=1188172 Raymond said that braces should always be considered special. This includes constructs like "{(?P.*)}" which the string module uses, and which would be a syntax error then. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-03 17:13 Message: Logged In: YES user_id=44345 Can you elaborate? I fail to see what the string module has to do with the re module. Can you give an example of code that would break? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 13:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 23:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Fri Jun 3 21:34:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 12:34:28 -0700 Subject: [ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path Message-ID: Bugs item #1209447, was opened at 2005-05-26 20:45 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() fails if 2nd arg is a UNC path Initial Comment: os.path.join('c:', r'\server\share') returns c:\server\share rather than \server\share. Interestingly os.path.join('c:a', r'\server\share') returns r'\server\share'. IMHO, r'\server\share' should be returned in all cases. ---------------------------------------------------------------------- >Comment By: John Ehresman (jpe) Date: 2005-06-03 19:34 Message: Logged In: YES user_id=22785 If the current behavior is kept, then os.path.join can't be relied upon to return the 2nd (or 3rd+) argument if that argument is an absolute path. This is one of the things I rely on os.path.join to do and would need to write my own version. Also, the behavior is quite different if the first agument contains more than simply the drive letter. I know this is a difficult issue and that is why I would like to see it fixed in the standard library. My question is whether there is a rationale for the current behavior. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 18:09 Message: Logged In: YES user_id=1188172 I'd recommend not to change the behaviour, but add a note in the docs that UNCs are not recognized as such in os.path.join. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:25 Message: Logged In: YES user_id=1188172 This is a difficult issue, since as far as I recall Windows allows two or more backslashes in a row in the middle of normal paths. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470 From noreply at sourceforge.net Fri Jun 3 21:47:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 12:47:55 -0700 Subject: [ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly Message-ID: Bugs item #1194181, was opened at 2005-05-03 04:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Bob Ippolito (etrepum) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 21:47 Message: Logged In: YES user_id=1188172 Ok, checked in as Modules/bz2module.c r1.24 r1.23.2.1 Lib/test/test_bz2.py r1.17 r1.16.2.1 ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-03 20:23 Message: Logged In: YES user_id=139309 It should still be OK to check in. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:16 Message: Logged In: YES user_id=1188172 Okay to check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 From noreply at sourceforge.net Fri Jun 3 21:49:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 12:49:46 -0700 Subject: [ python-Bugs-1212900 ] Python segfaults on OpenBSD (tested 3.4 and 3.5) Message-ID: Bugs item #1212900, was opened at 2005-06-01 19:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults on OpenBSD (tested 3.4 and 3.5) Initial Comment: Here is a minimal case, launch the server and then the client (change the server ip on the client source). Under NetBSD it works as expected, under OpenBSD I get a big segfault at the "ping" time... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-06-03 21:49 Message: Logged In: YES user_id=21627 Looks like a stack overflow. What is the stack size limit in your account? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 From noreply at sourceforge.net Fri Jun 3 22:12:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 13:12:22 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 01:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Fri Jun 3 22:45:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 13:45:10 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2005-06-03 15:45 Message: Logged In: YES user_id=555 I like rhettinger's "iter(s).next()" solution quite well, except that it's kind of an obscure way to say "give me an element of this set". I'm completely okay with the idea that the choose method may or may not return the same element each time--I just want a "for example" element. To my thinking, pop() isn't really a good solution because it treats sets and frozensets differently. Plus a pop()/add() cycle seems wasteful and confusing. One could argue that in the other place where pop() is available (lists), there is also a simple way to "peek" at what would be popped, which is kind of what we're talking about here. As for a use case, I'm not sure I have a great one. This came up when I was writing some union/find code. I was using sets to represent equivalence classes and I wanted to be able to grab a representative of a set (which would be any element of the set), given the set. I was surprised to find that there didn't seem to be a straightforward way to do this. I agree that I could just copy your 'choose' function into my code easily. There are several such functions that I already copy into pretty much every script I write these days (warn, error, and groupby, which probably do just what you think they do). If it's something that would be broadly useful, though, it seems like it'd be a lot more efficient for everyone to know the function by the same name (i.e., by having it be in the standard library). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Fri Jun 3 22:50:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 13:50:03 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Raymond Hettinger (rhettinger) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:50 Message: Logged In: YES user_id=1188172 Attaching patch which duplicates the file handle under UNIX too (btw, the size() method was broken too), mimics Windows behaviour with resize(), adds a testcase for this and clarifies the docs. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 01:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Fri Jun 3 23:10:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 14:10:51 -0700 Subject: [ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic Message-ID: Bugs item #1212077, was opened at 2005-05-31 10:34 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2005-06-03 16:10 Message: Logged In: YES user_id=555 I didn't mean it as a rant. Sorry. I don't necessarily mind having an optimized version of groupby with sharp edges for the unawares, but it seems like a "friendly" version is actually at least as important and should therefore also be supplied. (Making an analogy with Lisp, having 'nconc' doesn't alleviate the need for an 'append'.) The friendly version of 'groupby' doesn't really have much to do with itertools--maybe it should be a basic builtin operator, like 'reduce'. With due respect, I don't think the examples I'm giving are at all cryptic or playing fast and loose with comprehension semantics. Rather, I'd argue that they demonstrate that the somewhat surprising semantics of itertools.groupby make it not entirely suitable for naive users. I'm really hoping for something here, as I've been copying a 'groupby' function (from the Python recipe collection) into my scripts now for quite a long time. I think this is a powerful and very much needed basic function, and I'd really like to see a broadly usable version of it incorporated. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:16 Message: Logged In: YES user_id=80475 Sorry, this is more of a rant than a bug report. The tool is functioning as designed and documented. The various design options were discussed on python-dev and this was what was settled on as the most useful, general purpose tool (eminently practical, but not idiotproof). Like other itertools, it can be used in a straight-forward manner or be used to write cryptic, mysterious code. In general, if you can't follow your own code (in situatations such as the above), a good first step is to unroll the list comprehension into a regular for-loop as that tends to make the assumptions and control flow more visible. Also, it can be taken as a hint that the itertool is not being used as intended. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 From noreply at sourceforge.net Sat Jun 4 05:22:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 20:22:14 -0700 Subject: [ python-Bugs-1212900 ] Python segfaults on OpenBSD (tested 3.4 and 3.5) Message-ID: Bugs item #1212900, was opened at 2005-06-01 17:33 Message generated for change (Comment added) made by fabinator You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults on OpenBSD (tested 3.4 and 3.5) Initial Comment: Here is a minimal case, launch the server and then the client (change the server ip on the client source). Under NetBSD it works as expected, under OpenBSD I get a big segfault at the "ping" time... ---------------------------------------------------------------------- >Comment By: Fabien Devaux (fabinator) Date: 2005-06-04 03:22 Message: Logged In: YES user_id=658447 ulimit -s returns "4096" with the limit set to 32000 I have the same error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-06-03 19:49 Message: Logged In: YES user_id=21627 Looks like a stack overflow. What is the stack size limit in your account? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212900&group_id=5470 From noreply at sourceforge.net Sat Jun 4 07:52:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Jun 2005 22:52:16 -0700 Subject: [ python-Bugs-1214662 ] test_marshal.py discards marshal.load val Message-ID: Bugs item #1214662, was opened at 2005-06-04 00: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=1214662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: test_marshal.py discards marshal.load val Initial Comment: I'm working on making the marshal module work with any file-like object. It's proving a bit more difficult than I imagined it would be. At any rate, several of the various test_* methods are similar in structure to test_buffer: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) I'm thinking that throwing away the result of marshal.load has to be an error (especially with the immediately following assert), and that it should really be: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) new = marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) Attached is a patch. I'd apply it but this apparent mistake is so pervasive that I thought it worth a double-check. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 From noreply at sourceforge.net Sat Jun 4 09:19:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 00:19:17 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-06 03:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 09:19 Message: Logged In: YES user_id=1188172 Okay to checkin? ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-05-11 21:23 Message: Logged In: YES user_id=34901 I would agree that the order is definitely broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-10 05:36 Message: Logged In: YES user_id=80475 Fred, I believe this was your change (1.23). The OP's request apprears correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Sat Jun 4 09:37:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 00:37:37 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 09:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Sat Jun 4 10:24:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 01:24:32 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-05 20:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 02:19 Message: Logged In: YES user_id=1188172 Okay to checkin? ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-05-11 14:23 Message: Logged In: YES user_id=34901 I would agree that the order is definitely broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-09 22:36 Message: Logged In: YES user_id=80475 Fred, I believe this was your change (1.23). The OP's request apprears correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Sat Jun 4 11:21:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 02:21:11 -0700 Subject: [ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards Message-ID: Bugs item #1196315, was opened at 2005-05-06 03:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: WeakValueDictionary.__init__ is backwards Initial Comment: >>> from weakref import WeakValueDictionary as wvd >>> class A: ... pass ... >>> wvd({1:A()}) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/weakref.py", line 46, in __init__ UserDict.UserDict.__init__(self, *args, **kw) File "/usr/lib/python2.4/UserDict.py", line 7, in __init__ self.update(dict) File "/usr/lib/python2.4/weakref.py", line 161, in update d[key] = KeyedRef(o, self._remove, key) AttributeError: WeakValueDictionary instance has no attribute '_remove' WeakValueDictionary.__init__ calls UserDict.__init__ first and sets self._remove second. It should do it the other way around. This is a regression from 2.3. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 11:21 Message: Logged In: YES user_id=1188172 Thanks for the report. Committed as Lib/weakref.py r1.27 r1.26.2.1. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 09:19 Message: Logged In: YES user_id=1188172 Okay to checkin? ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2005-05-11 21:23 Message: Logged In: YES user_id=34901 I would agree that the order is definitely broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-10 05:36 Message: Logged In: YES user_id=80475 Fred, I believe this was your change (1.23). The OP's request apprears correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&group_id=5470 From noreply at sourceforge.net Sat Jun 4 11:33:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 02:33:40 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 09:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 11:33 Message: Logged In: YES user_id=1188172 I don't know, but wouldn't it be simpler to just document the warnings.filters attribute so that people know how to manipulate the list of filters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Sat Jun 4 12:01:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 03:01:25 -0700 Subject: [ python-Bugs-1210001 ] Typo in "Differences from mimelib" Message-ID: Bugs item #1210001, was opened at 2005-05-27 18:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Zumi (zumi001) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Typo in "Differences from mimelib" Initial Comment: In the online manual: http://www.python.org/doc/2.4/lib/node577.html "12.2.12 Differences from mimelib" there's a typo: "The methodgetmaintype() was renamed to get_main_type()." Suggestion: a space after the word "method". So something like this: "The method getmaintype() was renamed to get_main_type()." ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:01 Message: Logged In: YES user_id=1188172 Thanks for the report; committed as Doc/lib/email.tex r1.19, r1.18.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&group_id=5470 From noreply at sourceforge.net Sat Jun 4 12:03:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 03:03:14 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 07:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) >Assigned to: Raymond Hettinger (rhettinger) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:03 Message: Logged In: YES user_id=1188172 Attached a documentation patch, following Terry's wording. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 19:42 Message: Logged In: YES user_id=593130 If I understand correctly, this revision of the consequent of the second sentence (after ',') matches the implementation. [If the class also defines __getattr__, ] the latter will not be called unless __getattribute__ either calls it explicitly or raises an AttributeError. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-05-26 18:18 Message: Logged In: YES user_id=6380 The implementation works as expected. The documentation is flawed. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-26 17:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 11:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 20:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 16:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Sat Jun 4 12:11:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 03:11:01 -0700 Subject: [ python-Bugs-1192315 ] 'clear -1' in pdb Message-ID: Bugs item #1192315, was opened at 2005-04-29 12:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pechkin (mpech) >Assigned to: Raymond Hettinger (rhettinger) Summary: 'clear -1' in pdb Initial Comment: Delete breakpoints like in %subj% is great feature, but wrong. Add additional check like in do_enable() if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:11 Message: Logged In: YES user_id=1188172 Attached patch which implements the check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 From noreply at sourceforge.net Sat Jun 4 12:27:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 03:27:32 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Master_Jaf (master_jaf) Assigned to: Nobody/Anonymous (nobody) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:27 Message: Logged In: YES user_id=1188172 Attaching a patch for the Tutorial. It adds the following sentence: +Note that with Python 2.2, a new kind of classes was introduced: +A class deriving from \class{object} is called a \emph{new-style class}. +The differences to classic classes are mostly internal, but there are +some features (like properties and static methods) that are only +available for new-style classes. + ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 20:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Sat Jun 4 12:35:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 03:35:31 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 09:37 Message generated for change (Comment added) made by bronger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- >Comment By: Torsten Bronger (bronger) Date: 2005-06-04 12:35 Message: Logged In: YES user_id=442234 It's simpler of course. However, if it's relatively easy to avoid, a module user should not manipulate module data structures directly, I think. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 11:33 Message: Logged In: YES user_id=1188172 I don't know, but wouldn't it be simpler to just document the warnings.filters attribute so that people know how to manipulate the list of filters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Sat Jun 4 13:12:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 04:12:59 -0700 Subject: [ python-Bugs-1209560 ] spurious blank page in dist.pdf Message-ID: Bugs item #1209560, was opened at 2005-05-27 02:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Raymond Hettinger (rhettinger) Summary: spurious blank page in dist.pdf Initial Comment: In the US Letter sized version of dist.pdf in the current download zip (Python 2.4.1), the third page of the file (the one immediately preceding the table of contents, which starts with roman numeral "i") is blank. That means that page "i" of the table of contents, and page "1" of the actual document, begin on even-numbered pages in the file. This is bad because if you print on a duplex printer, page 1 comes out on the back of page ii, page 3 comes out on the back of page 2, etc. You want odd numbered pages to be on the front and even numbered pages to be on the back, so page 2 should be on the back of page 1, etc. This is probably a problem with the latex extension that made the pdf file and so it probably affects the other pdfs as well as dist.pdf, but that's the only one I printed. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 13:12 Message: Logged In: YES user_id=1188172 This indeed happens only in dist.pdf. Attaching a patch which includes the copyright, as in all other documents, and magically, the paging is right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 From noreply at sourceforge.net Sat Jun 4 13:45:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 04:45:33 -0700 Subject: [ python-Bugs-1189248 ] Seg Fault when compiling small program Message-ID: Bugs item #1189248, was opened at 2005-04-25 07:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: Seg Fault when compiling small program Initial Comment: I am using SuSE 9.2. When trying to compile/interpret the attached file, the python interpreter seg faults with no other information. Please note: the attached test file does not end in a new line. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 13:45 Message: Logged In: YES user_id=1188172 I believe it is fixed, too... can't reproduce here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-25 09:56 Message: Logged In: YES user_id=6656 I think this is fixed in Python 2.4.1... what version are you using? ---------------------------------------------------------------------- Comment By: Reginald B. Charney (rcharney) Date: 2005-04-25 08:42 Message: Logged In: YES user_id=411372 It turns out that the seg fault was caused by the first line of the program: # coding: evil It seems that specifying an invalid character encoding causes a seg fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 From noreply at sourceforge.net Sat Jun 4 14:46:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 05:46:14 -0700 Subject: [ python-Bugs-1214662 ] test_marshal.py discards marshal.load val Message-ID: Bugs item #1214662, was opened at 2005-06-04 06:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: test_marshal.py discards marshal.load val Initial Comment: I'm working on making the marshal module work with any file-like object. It's proving a bit more difficult than I imagined it would be. At any rate, several of the various test_* methods are similar in structure to test_buffer: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) I'm thinking that throwing away the result of marshal.load has to be an error (especially with the immediately following assert), and that it should really be: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) new = marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) Attached is a patch. I'd apply it but this apparent mistake is so pervasive that I thought it worth a double-check. Skip ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-04 13:46 Message: Logged In: YES user_id=6656 Makes sense to me. I guess the pervasiveness has something to do with the evils of copy & paste... (I haven't run the new tests, mind) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 From noreply at sourceforge.net Sat Jun 4 14:48:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 05:48:41 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 08:37 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-04 13:48 Message: Logged In: YES user_id=6656 Pfft, this isn't Java! I'm not sure it should be done with impunity, but as a documented interface it makes perfect sense to me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-06-04 11:35 Message: Logged In: YES user_id=442234 It's simpler of course. However, if it's relatively easy to avoid, a module user should not manipulate module data structures directly, I think. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 10:33 Message: Logged In: YES user_id=1188172 I don't know, but wouldn't it be simpler to just document the warnings.filters attribute so that people know how to manipulate the list of filters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Sat Jun 4 14:57:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 05:57:19 -0700 Subject: [ python-Bugs-1214662 ] test_marshal.py discards marshal.load val Message-ID: Bugs item #1214662, was opened at 2005-06-04 00:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: test_marshal.py discards marshal.load val Initial Comment: I'm working on making the marshal module work with any file-like object. It's proving a bit more difficult than I imagined it would be. At any rate, several of the various test_* methods are similar in structure to test_buffer: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) I'm thinking that throwing away the result of marshal.load has to be an error (especially with the immediately following assert), and that it should really be: def test_buffer(self): for s in ["", "Andr? Previn", "abc", " "*10000]: b = buffer(s) new = marshal.loads(marshal.dumps(b)) self.assertEqual(s, new) marshal.dump(b, file(test_support.TESTFN, "wb")) new = marshal.load(file(test_support.TESTFN, "rb")) self.assertEqual(s, new) os.unlink(test_support.TESTFN) Attached is a patch. I'd apply it but this apparent mistake is so pervasive that I thought it worth a double-check. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-04 07:57 Message: Logged In: YES user_id=44345 Agreed about cut-n-paste as the likely culprit. Fix applied to test_marshal.py 1.11. (I did run the tests... ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-04 07:46 Message: Logged In: YES user_id=6656 Makes sense to me. I guess the pervasiveness has something to do with the evils of copy & paste... (I haven't run the new tests, mind) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214662&group_id=5470 From noreply at sourceforge.net Sat Jun 4 18:42:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 09:42:26 -0700 Subject: [ python-Bugs-1214859 ] subprocess auto-reaps children Message-ID: Bugs item #1214859, was opened at 2005-06-04 18: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=1214859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess auto-reaps children Initial Comment: The subprocess module automatically reaps child processes, by maintaining a list of instances which is traversed each time a new Popen instance is created. Apparently this was originally intended to avoid large number of zombie processes to accrete in the system if the programmer is lazy and does not wait for them properly, but it can cause problems when the programmer wants greater control. In particular, it's not possible to use the pid from a subprocess.Popen instance, since it may already have disappeared. For instance, it makes it difficult to use os.wait() to wait for several child processes at the same time. The solution is simple: Add an option that disables the auto-reaper for a Popen instance. This makes everyone happy: existing code is unaffected, the programmer who wants to control her processes herself is allowed to do that, and the documentation is improved to help avoiding a nasty bug. A patch was posted to the patch tracker as number 1187312. I suggest it for inclusion into the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 From noreply at sourceforge.net Sun Jun 5 04:18:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 19:18:17 -0700 Subject: [ python-Bugs-1215023 ] bsddb dbobj.DB.associate doesn't accept dbobj.DB param Message-ID: Bugs item #1215023, was opened at 2005-06-04 19:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb dbobj.DB.associate doesn't accept dbobj.DB param Initial Comment: To: Michael C Urban Cc: pybsddb-users at lists.sourceforge.net Date: Sat, 4 Jun 2005 18:21:34 -0700 On Sat, Jun 04, 2005 at 06:16:37PM -0500, Michael C Urban wrote: > Hi all, > > I'm running into a TypeError when I try to associate a secondary db with a > primary one. But the error only occurs when I use an object oriented > style, so I am wondering it it might be a bug. > > Basically, the following works fine: > > db = DB(None, 0) > db.open("testDb.db", None, DB_BTREE, DB_CREATE, 0660) > dbs = DB(None, 0) > dbs.open("testDbS.db", None, DB_BTREE, DB_CREATE, 0660) > db.associate(dbs, makeAddressKey, 0) > > However, the following similar code does not: > > def __dbInitialize(self, dbDir, fileName): > self.__dbEnv = dbobj.DBEnv(0) > self.__dbEnv.open(dbDir, db.DB_INIT_TXN | db.DB_CREATE | > db.DB_INIT_MPOOL) > > self.__dbMain = dbobj.DB(self.__dbEnv, 0) > self.__nameIdx = dbobj.DB(self.__dbEnv, 0) > > self.__dbMain.open(fileName, None, db.DB_BTREE, db.DB_CREATE, 0660) > self.__nameIdx.open("nameDb.idx", None, db.DB_BTREE, > db.DB_CREATE, 0660) > > self.__dbMain.associate(self.__nameIdx, self.__makeNameKey, 0) > > ... > The last line causes the following error: > > TypeError: Expected DB argument, instance found. > > Am I doing something wrong here? The only difference I can see between the > first example and the second one is that one uses a private variable from > the class, and the other does not use object oriented style. The databases > all get created fine, as to the log files. It's only when I try to > associate that I have the problem. > > Thanks for any help in advance. This is happening because the C wrapper requires that the secondaryDB parameter to associate() is a C wrapper DB object. My first suggestion is based on the code above, use db.DB not dbobj.DB. dbobj is only a wrapper around the C db.DB to allow people to subclass it. If you do need to use a dbobj derived class for the secondary DB, realize that BerkeleyDB doesn't call back to python for DB access so it won't use any overridden methods. If thats ok, then add the following overridden method to your dbobj derived class and associate should work: 
    def associate(self, *args, **kwargs):
        # if we're given a dbobj derived secondaryDB we
need to pass
        # the actual C db.DB object to BerkeleyDB.  do it.
        argDB = kwargs.get('secondaryDB')
        if not argDB:
            argDB = args.pop(0)
        if isinstance(argDB, DB):
            kwargs['secondaryDB'] = argDB._cobj
        return apply(self._cobj.associate, args, kwargs)
This passes the internal C db.DB object to the BerkeleyDB associate method. I'm pasting this email as a pybsddb bug report. the above method should probably be used as the base dbobj.associate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&group_id=5470 From noreply at sourceforge.net Sun Jun 5 08:02:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Jun 2005 23:02:21 -0700 Subject: [ python-Bugs-1206232 ] IDLE 1.0.5 (Python 2.3.5) crashes under Windows Message-ID: Bugs item #1206232, was opened at 2005-05-21 12:46 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Torsten Bronger (bronger) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE 1.0.5 (Python 2.3.5) crashes under Windows Initial Comment: Using Win2k or XP, IDLE 1.0.5 and Python 2.3.5, the attached source produces a fatal error and IDLE and the Python Shell are closed. In order to reproduce the issue, start IDLE, open the attached file and press "F5". ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-05 01:02 Message: Logged In: YES user_id=149084 Probably not worth fixing in 2.3 branch at this point. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-05-26 15:26 Message: Logged In: YES user_id=442234 Oops, I think I should add my further findings nevertheless: It was indeed the hex constants and their implicit conversion to signed values. An attached "L" solved the problem. Could it be that the warning messages cause possible errors with IDLE on Windows? With Linux, I see those "future warnings" on the console when I try to import my file. With IDLE, these things are supressed, of course. 2.4 doesn't show warnings, too. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-05-26 15:20 Message: Logged In: YES user_id=442234 No, I had tested it also with 2.4.x and had no problem. I didn't know whether there would be another 2.3.x, so I submitted it. In case the 2.3 branch is closed, do the same with this bug. ;) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:23 Message: Logged In: YES user_id=593130 Does this still happen with 2.4.1 and the corresponding IDLE? Besides numerous bug fixes, I believe 2.4 changed the interpretation of unsigned hex constants from sometimes negative to always positive. From a glance at your file, this seems likely relevant. If you also find a bug with current Python/IDLE, please reduce your file to the minimum necessary to produce the bug. Also include the error message and traceback you get. (As far as I know, there is currently no prospect of a 2.3.6, but there should at least be a 2.4.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206232&group_id=5470 From noreply at sourceforge.net Sun Jun 5 12:46:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 03:46:35 -0700 Subject: [ python-Bugs-1187437 ] TypeError message on bad iteration is misleading Message-ID: Bugs item #1187437, was opened at 2005-04-21 16:58 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError message on bad iteration is misleading Initial Comment: >>> for i in 5: ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I know this is kind of a trivial point, but the message "iteration of non-sequence" should really be something like "iteration of non-iterable object", since not all iterable things are sequences. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 12:46 Message: Logged In: YES user_id=1188172 Seems reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 From noreply at sourceforge.net Sun Jun 5 12:57:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 03:57:31 -0700 Subject: [ python-Bugs-1184380 ] example broken in section 1.12 of Extending & Embedding Message-ID: Bugs item #1184380, was opened at 2005-04-16 21:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184380&group_id=5470 Please note that this 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: Fixed Priority: 1 Submitted By: bamoore (bamoore) Assigned to: Nobody/Anonymous (nobody) Summary: example broken in section 1.12 of Extending & Embedding Initial Comment: In section 1.12 of Extending and Embedding the Python Interpreter Release 2.4, the example (spammodule) does not compile on linux with distutils. I get the following: ~/sandbox/python/c_api_test$ python2.4 spam-setup.py build running build running build_ext building 'spam' extension creating build creating build/temp.linux-i686-2.4 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.4 -c spammodule.c -o build/temp.linux-i686-2.4/spammodule.o spammodule.c:7: error: conflicting types for `PySpam_System' spammodule.h:21: error: previous declaration of `PySpam_System' error: command 'gcc' failed with exit status 1 I think the solution is to change line 12 of the spammodule header file listing from: #define PySpam_System_PROTO (char *command) to: #define PySpam_System_PROTO (const char *command) as that seems to compile for me. (though not tested from another C extension). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 12:57 Message: Logged In: YES user_id=1188172 Thanks, fixed as Doc/ext/extending.tex r1.33, r1.30.4.3 ---------------------------------------------------------------------- Comment By: Luis Bruno (lbruno) Date: 2005-04-21 16:05 Message: Logged In: YES user_id=1263795 AIUI, your solution is correct; a cursory glance through the PyArg_ParseTuple() documentation and the system() manual page leads me to believe we're expecting a const char *. I'll submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184380&group_id=5470 From noreply at sourceforge.net Sun Jun 5 14:29:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 05:29:08 -0700 Subject: [ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME Message-ID: Bugs item #1193849, was opened at 2005-05-02 17:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 Please note that this 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 Submitted By: Wummel (calvin) >Assigned to: Raymond Hettinger (rhettinger) Summary: os.path.expanduser documentation wrt. empty $HOME Initial Comment: If $HOME is unset, an initial "~" should not be expanded according to the documentation. But instead it somehow is expanded, perhaps through the pwd module: $ env -u HOME python -c "import os.path; print os.path.expanduser('~/foo')" /home/calvin/foo The result should be "~/foo" instead of "/home/calvin/foo". I suggest adjusting the documentation to state the also a single "~" is looked up in the pwd module, not only "~user". ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:29 Message: Logged In: YES user_id=1188172 Attached a patch which fixes the docs. Okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 From noreply at sourceforge.net Sun Jun 5 14:49:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 05:49:01 -0700 Subject: [ python-Bugs-1183585 ] try to open /dev/null as directory Message-ID: Bugs item #1183585, was opened at 2005-04-15 10:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Roberto A. Foglietta (robang) Assigned to: Nobody/Anonymous (nobody) Summary: try to open /dev/null as directory Initial Comment: bash-2.05b# strace python 2>&1 | grep open | grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:49 Message: Logged In: YES user_id=1188172 I think this isn't Python's fault, as isandler's post shows. I would rather look for a bug in the C lib. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-05-17 07:02 Message: Logged In: YES user_id=971153 2 questions though: 1. Does this cause any problems? 2. I observe exactly the same behaviour for ls! (I'm on Debian, kernel 2.4.25) bagira:~> strace ls | & grep open | grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) and for du: bagira:~> strace du /etc | & grep open |grep null open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) So, I'm almost ready to say that even if it's a bug, it's not a python's bug... (Search for /dev/null in python source also does not find anything interesting).. ---------------------------------------------------------------------- Comment By: Roberto A. Foglietta (robang) Date: 2005-04-20 20:02 Message: Logged In: YES user_id=36141 I downloaded the python-2.4.1 sources and compiled under slack 10 and Mandrake 10.1 and in both case it tried to open /dev/null as a directory. Some debian users reported me the same behaviure. [roberto at wsraf roberto]$ uname -ar Linux wsraf.sad.it 2.6.8.1-24mdksmp #1 SMP Thu Jan 13 23:11:43 MST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz unknown GNU/Linux ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-04-16 09:54 Message: Logged In: YES user_id=849994 I don't quite understand what you're trying to tell us here. Are you just calling Python this way and observing the system calls? Then, what system do you use? What version? What kernel, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470 From noreply at sourceforge.net Sun Jun 5 15:11:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 06:11:51 -0700 Subject: [ python-Bugs-1215146 ] int('x',radix) puzzle Message-ID: Bugs item #1215146, was opened at 2005-06-05 06:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: int('x',radix) puzzle Initial Comment: I don?t understand the built-in function int(x, radix). Or its documentation in the Library Reference section 2.1 ? Built-In Functions. I?m using Python 2.4.1 on Windows XP Pro w/SP2, And I get the following on IDLE: >>> int(9) 9 >>> int('9') 9 >>> int('9',2) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',2) ValueError: invalid literal for int(): 9 >>> int('9',8) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',8) ValueError: invalid literal for int(): 9 >>> int('9',10) 9 >>> int('9',16) 9 >>> int('19',16) 25 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:09:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:09:00 -0700 Subject: [ python-Bugs-1215146 ] int('x',radix) puzzle Message-ID: Bugs item #1215146, was opened at 2005-06-05 15:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: int('x',radix) puzzle Initial Comment: I don?t understand the built-in function int(x, radix). Or its documentation in the Library Reference section 2.1 ? Built-In Functions. I?m using Python 2.4.1 on Windows XP Pro w/SP2, And I get the following on IDLE: >>> int(9) 9 >>> int('9') 9 >>> int('9',2) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',2) ValueError: invalid literal for int(): 9 >>> int('9',8) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',8) ValueError: invalid literal for int(): 9 >>> int('9',10) 9 >>> int('9',16) 9 >>> int('19',16) 25 >>> ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 16:08 Message: Logged In: YES user_id=1188172 The function is behaving as expected. The radix argument specifies which base the number system in the string has. Radix 2 means binary, for example, and radix 16 hexadecimal. >From that, it is clear that '9' is an invalid binary or octal number. In the future, please direct such questions to the Newsgroup comp.lang.python. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:32:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:32:56 -0700 Subject: [ python-Feature Requests-1175686 ] add "reload" function Message-ID: Feature Requests item #1175686, was opened at 2005-04-03 03:48 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 3 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add "reload" function Initial Comment: The file menu in Editor windows could benefit from a "reload" function that re-reads the file from disc and loads it into the editor, replacing what's currently in the editor. That's useful for those of us who like to edit with Emacs in another window while running the code under Idle. To get really fancy, it might be cool to optionally display a diff between the in-editor version and the on-disk version allowing merging changes, but that's maybe over the top. Other editors usually do have commands like this, e.g.M-x Revert-file in Emacs or ":e!" in vi. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-05 09:32 Message: Logged In: YES user_id=149084 Responding to your "misplaced" post, I use emacs for everything also; basically I live in emacs. However, my question still stands. Have you tried IDLE with the autosave and F5 to run? If IDLE had incremental search it would be pretty close or maybe even better. I used to use emacs to develop IDLE but I find I'm increasingly using IDLE for that purpose. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-26 11:20 Message: Logged In: YES user_id=149084 I like the Revert idea better. It probably should be above "Close" in the File menu. Otherwise, if it's next to "Recent Files", someday someone is going to select it by mistake and be really ticked. I think the suggestion violates KISS. Over time, it's ideas like this that cause creeping features and a boated interface. But again, why not use IDLE instead of emacs to edit Python code? One button Save/Run! What is the killer feature that's missing from IDLE? That would be the real thing to work on. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-18 21:55 Message: Logged In: YES user_id=149084 Why do you use Emacs instead of IDLE? (I use emacs myself sometimes, but I'm curious what your reasons are these days.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 17:48 Message: Logged In: YES user_id=80475 If added, it should definitely be called "revert" instead of "reload". The latter already has a specific meaning in Python that relates to imports. The former seems to be standard terminology across a number of editing tools from emacs to photoshop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1175686&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:52:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:52:35 -0700 Subject: [ python-Feature Requests-563141 ] fileinput/gzip modules should play well Message-ID: Feature Requests item #563141, was opened at 2002-06-01 02:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg White (groggygreggy) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput/gzip modules should play well Initial Comment: It seems to be nearly impossible to use the fileinput module to read gzip files, even though gzip support is available in the gzip module. As a first step, it would be nice if the fileinput.FileInput class provided an overridable method that let outsiders glue the gzip module in place. It would also be nice if there was a way to make fileinput just automatically support gzip files (if, for instance, it saw a .gz extension). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 16:52 Message: Logged In: YES user_id=1188172 See patch #1215184. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 04:25 Message: Logged In: YES user_id=357491 The hook is reasonable, the automatic opening of gzip is not. No need to have magic done based purely on extension. Any chance you could write a patch to expose the hook? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:52:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:52:50 -0700 Subject: [ python-Bugs-1215146 ] int('x',radix) puzzle Message-ID: Bugs item #1215146, was opened at 2005-06-05 06:11 Message generated for change (Comment added) made by azgordo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: int('x',radix) puzzle Initial Comment: I don?t understand the built-in function int(x, radix). Or its documentation in the Library Reference section 2.1 ? Built-In Functions. I?m using Python 2.4.1 on Windows XP Pro w/SP2, And I get the following on IDLE: >>> int(9) 9 >>> int('9') 9 >>> int('9',2) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',2) ValueError: invalid literal for int(): 9 >>> int('9',8) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',8) ValueError: invalid literal for int(): 9 >>> int('9',10) 9 >>> int('9',16) 9 >>> int('19',16) 25 >>> ---------------------------------------------------------------------- >Comment By: elgordo (azgordo) Date: 2005-06-05 07:52 Message: Logged In: YES user_id=1291540 OK --- I was confused by the documentation. I'd like to propose the following replacement for the documentation: int([x[, b]]) Converts base b numbers specified by the inputs to their decimal integer equivalents. When the base b is absent x may be either (i) the string representation of a possibly signed decimal integer (possibly embedded in whitespace), or (ii) a possibly signed decimal integer or floating point number (floating point numbers are truncated towards zero). If the base b is present and non-zero, it must be an integer in the range [2, 36] and x must be the possibly signed string representation of an integer in base b notation. When x is a string and the base b is zero, the base actually used is guessed by interpreting the string x in the same way as for integer literals. When b is present then (i) if x is not a string a TypeError is raised, and (ii) if the string x does not represent an integer then a ValueError is raised. Returns 0 if no arguments are given. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 07:08 Message: Logged In: YES user_id=1188172 The function is behaving as expected. The radix argument specifies which base the number system in the string has. Radix 2 means binary, for example, and radix 16 hexadecimal. >From that, it is clear that '9' is an invalid binary or octal number. In the future, please direct such questions to the Newsgroup comp.lang.python. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 From noreply at sourceforge.net Sun Jun 5 16:54:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 07:54:58 -0700 Subject: [ python-Bugs-1215146 ] int('x',radix) puzzle Message-ID: Bugs item #1215146, was opened at 2005-06-05 06:11 Message generated for change (Comment added) made by azgordo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: int('x',radix) puzzle Initial Comment: I don?t understand the built-in function int(x, radix). Or its documentation in the Library Reference section 2.1 ? Built-In Functions. I?m using Python 2.4.1 on Windows XP Pro w/SP2, And I get the following on IDLE: >>> int(9) 9 >>> int('9') 9 >>> int('9',2) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',2) ValueError: invalid literal for int(): 9 >>> int('9',8) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',8) ValueError: invalid literal for int(): 9 >>> int('9',10) 9 >>> int('9',16) 9 >>> int('19',16) 25 >>> ---------------------------------------------------------------------- >Comment By: elgordo (azgordo) Date: 2005-06-05 07:54 Message: Logged In: YES user_id=1291540 OK --- I was confused by the documentation. I'd like to propose the following replacement for the documentation: int([x[, b]]) Converts base b numbers specified by the inputs to their decimal integer equivalents. When the base b is absent x may be either (i) the string representation of a possibly signed decimal integer (possibly embedded in whitespace), or (ii) a possibly signed decimal integer or floating point number (floating point numbers are truncated towards zero). If the base b is present and non-zero, it must be an integer in the range [2, 36] and x must be the possibly signed string representation of an integer in base b notation. When x is a string and the base b is zero, the base actually used is guessed by interpreting the string x in the same way as for integer literals. When b is present then (i) if x is not a string a TypeError is raised, and (ii) if the string x does not represent an integer then a ValueError is raised. Returns 0 if no arguments are given. ---------------------------------------------------------------------- Comment By: elgordo (azgordo) Date: 2005-06-05 07:52 Message: Logged In: YES user_id=1291540 OK --- I was confused by the documentation. I'd like to propose the following replacement for the documentation: int([x[, b]]) Converts base b numbers specified by the inputs to their decimal integer equivalents. When the base b is absent x may be either (i) the string representation of a possibly signed decimal integer (possibly embedded in whitespace), or (ii) a possibly signed decimal integer or floating point number (floating point numbers are truncated towards zero). If the base b is present and non-zero, it must be an integer in the range [2, 36] and x must be the possibly signed string representation of an integer in base b notation. When x is a string and the base b is zero, the base actually used is guessed by interpreting the string x in the same way as for integer literals. When b is present then (i) if x is not a string a TypeError is raised, and (ii) if the string x does not represent an integer then a ValueError is raised. Returns 0 if no arguments are given. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 07:08 Message: Logged In: YES user_id=1188172 The function is behaving as expected. The radix argument specifies which base the number system in the string has. Radix 2 means binary, for example, and radix 16 hexadecimal. >From that, it is clear that '9' is an invalid binary or octal number. In the future, please direct such questions to the Newsgroup comp.lang.python. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 From noreply at sourceforge.net Sun Jun 5 19:08:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 10:08:43 -0700 Subject: [ python-Feature Requests-644940 ] Support file path concat with " /" Message-ID: Feature Requests item #644940, was opened at 2002-11-27 21:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mark VanTassel (markvantassel) Assigned to: Nobody/Anonymous (nobody) Summary: Support file path concat with "/" Initial Comment: A very useful feature is to overload the "/" operator for strings to support path concatenation - that is, to concat the left and right arguments in such a way that there is exactly one slash between them, regardless of which argument(s) did or didn't include slashes: dir = "/this/that" file = "whatever.py" print dir / file #prints "/this/that/whatever.py" It seems silly, but when you're not 100% in control of things (such as when reading paths from config files, user input, etc), it's great to be sure that the right thing will happen without writing/testing a lot of icky code. And even when you are 100% in control, it's nice to not have to worry about it so much. This doesn't seem to conflict with any existing usage or syntax, so I don't think it can possibly break any existing behaviour (except, of course, those who were counting on having an exception thrown!) I've already coded this as a minor tweak to the Python 2.2.2 release, and I'd be happy to share the fix with the powers that be, if there's general concensus that this is a good thing. Feedback is solicited and appreciated (this is my first foray into open-source development, so be gentle!) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 19:08 Message: Logged In: YES user_id=1188172 I think this can be closed. If someone wants that functionality in the Python distribution, he should ask for a module like http://www.jorendorff.com/articles/python/path/ in the stdlib (which I would support too). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-12-09 19:30 Message: Logged In: YES user_id=89016 IMHO implementing str / str as a duplicate of os.path.join blurs what a string is. The meaning of a type should be tied to the type and not to various sets of operators (for + a str instance is treated as a string, for / as a filename). And if we add /, where should we stop? str.open(), str.exists(), str.stat() etc.? If we duplicate every function in os.path we might get name clashes. IMHO string and filename APIs should be kept separate. So the clearer solution would to be implement a separate filename class. Whether this is a subclass of str or not is IMHO unclear. What about Unicode filenames? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-03 19:24 Message: Logged In: YES user_id=21627 Please notice that there is an established function in Python that has the same effect: os.path.join: >>> dir = "/this/that" >>> file = "whatever.py" >>> import os >>> print os.path.join(dir,file) /this/that/whatever.py There is, in general, reluctance to add new syntax to Python if you can achieve the same effect with a function - in particular if the function has been there for a long time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 21:00 Message: Logged In: YES user_id=33168 How often do you really need this? Is it that bad/hard to use os.path.join? There are always problems with adding new features which overload existing operations, like using "/". It's true that it would raise an exception today, so could be acceptable to implement str / str. However, unless this is for a very common task, is it worth it? Using / to join path components is not obvious to me. I doubt it would be generally obvious. Would it be confusing? There is the cost of not being able to use / for something possibly more meaningful and more common if this were implemented. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-29 14:02 Message: Logged In: YES user_id=658048 Having used a C++ string class with overloaded "/", I can assure you it's quite useful. Aside from the executable being about 100 bytes larger, I can't see how it hurts anything. The righthandside absolute path (assuming you mean with a non-empty leftside path) is a semantic problem. You could reasonably say that if the right side starts with a slash, ignore the left side. Similarly, if the rightside starts with "X:" (under windows), ignore the left side. The Mac version could certainly insert ":" chars instead of slashes. Note, though, that the "/" operator isn't intended to solve all the worlds problems - if you have quirky path-usage rules, you'll probably have to implement them yourself regardless. This is just to make the relatively simple stuff (hopefully the 80% case) drop-dead simple and avoid strange errors when the user improperly specifies a directory (or a file) in a config file or whatever. URLs are a more intriguing issue - they were far less important the first time I implemented this. I suppose a subclass would be best. And while OS-specific flavors might be nice add-ons (for those rare cases when a Mac is concatenating paths meant for evaluation on a windows machine, etc), I strongly believe that the "default" behaviour should be appropriate for the current OS, thereby promoting code portability. Question: Would it be too ugly (or too difficult) to have a prefix character (analogous to the "r" for raw strings) to specify that a literal string is of one of the above-suggested subtypes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 10:46 Message: Logged In: YES user_id=45365 Apart from the question of whether pathname concatenation is important enough to add a special operator on the string type for (I think not), there are lots of boundary issues with your proposal. For instance, how about a righthandside absolute path? How about two paths with C: style disks in them on Windows? How about Macintosh pathnames (colon-separated, with relative paths starting with a colon)? Or, why does it concatenate pathnames in the first place, and not URLs (makes a difference on Mac)? If you want to continue down this trail I would suggest the first step is to subclass strings. You can then have separate subclasses for Windows paths, Unix paths, URLs, Mac paths, etc. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-27 21:49 Message: Logged In: YES user_id=658048 P.S. There are a few loose ends for discussion: 1) What to do with empty strings? My current implementation doesn't do anything special, so dir/"" ends with a slash, ""/file starts with a slash, and ""/"" is a slash. If someone thinks different behaviour would be better, I'm open to alternatives. 2) What about back slashes on Windows (my native platform, actually)? My version removes trailing slashes and backslashes from the 1st arg, and removes leading slashes and backslashes from the 2nd ard, and then puts a backslash between them... but again I'm open to alternatives. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 From noreply at sourceforge.net Sun Jun 5 19:26:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 10:26:55 -0700 Subject: [ python-Feature Requests-798520 ] os.popen with invalid mode differs on Windows and POSIX Message-ID: Feature Requests item #798520, was opened at 2003-09-01 14:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=798520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen with invalid mode differs on Windows and POSIX Initial Comment: On Windows, os.popen with an invalid mode throw a ValueError and on POSIX systems it throws an OSError. Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.popen('dir', '') Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: popen() arg 2 must be 'r' or 'w' Python 2.3 (#167, Sep 1 2003, 06:38:18) [GCC 3.0.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.popen('ls', '') Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 22] Invalid argument Additionally, the ValueError message is incorrect; arg 2 can be 'r', 'rb', 'rt', 'w', 'wb', or 'wt'. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 19:26 Message: Logged In: YES user_id=1188172 Should the exceptions be synchronized? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=798520&group_id=5470 From noreply at sourceforge.net Sun Jun 5 19:34:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 10:34:49 -0700 Subject: [ python-Bugs-412436 ] compileall doesn't notice syntax errors Message-ID: Bugs item #412436, was opened at 2001-03-30 12:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: compileall doesn't notice syntax errors Initial Comment: compileall.py returns an exit code to indicate the success or failure of compilation. This feature was added in compileall.py revision 1.7 in response to distutils message http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html This is not as useful as it looks because a prior change to py_compile.py (revision 1.13) catches syntax errors, hiding them completely from compileall.py, so compileall.py can't report the failure to its caller. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 19:34 Message: Logged In: YES user_id=1188172 Closing as Fixed, then. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-27 05:58 Message: Logged In: YES user_id=971153 I did a small test ~>echo '"garab' > garbage.py ~>python -m compileall . and got expected: SyntaxError: EOL while scanning single-quoted string and exit status of 1 So the problem is fixed in latest python and bug can be closed ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 22:01 Message: Logged In: YES user_id=92689 The change to compileall.py has been in CVS for a long time. The strange thing is that the accompanying py_compile.py patch wasn't checked in. All I did was update that change for current CVS. Jeremy? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:25 Message: Logged In: YES user_id=33168 I definitely think Just's change to py_compile.py (return 0 or 1 from compile()) should be checked in. This doesn't hurt and is backwards compatible. I think a NEWS entry and doc updates (Doc/lib/libpycompile.tex) should be done as well. The change to compileall.py is also probably ok, but I didn't look as closely (the patch failed to apply for me in 2.3). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 13:29 Message: Logged In: YES user_id=92689 Reopening this bug as it's entirely unclear why the py_compile.py change wasn't checked in. This has resulted in a new bug, #653301. I've attached a patch that's updated for current CVS (rev. 1.23 of py_compile.py). Since py_compile.py is crucial to the install process I'd rather have someone else make the decision to check this in or not. ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2001-09-10 05:31 Message: Logged In: YES user_id=320286 I don't see how this can be fixed in compileall.py since the problem is with py_compile.py. py_compile.compile (up to and including the latest version I see in CVS, revision 1.18) only ever returns None, so the code in compileall.py revision 1.19 that says: ok = py_compile.compile(fullname, None, dfile) and if ok == 0: can't possibly work. Caveat: this comment based on reading code, not running it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-18 03:23 Message: Logged In: YES user_id=31392 Fixed in rev 1.9 of compileall.py. Note that this fix causes a bunch of changes to the test suite, so that files containing syntaxerrors are not compiled by compileall. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 23:16 Message: Logged In: YES user_id=31392 Will fix following the 2.1 release ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 16:31 Message: Logged In: YES user_id=31392 I think this is easy enough to fix, but I don't know what unintended side-effects the fix will have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 From noreply at sourceforge.net Sun Jun 5 20:04:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 11:04:05 -0700 Subject: [ python-Bugs-504219 ] locale.resetlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-16 05:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Syver Enstad (syvere) Assigned to: Mark Hammond (mhammond) Summary: locale.resetlocale is broken Initial Comment: locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. The only way I've succeeded in setting the locale on Python 2.1 is to use the format described in the Visual C++ C-runtime library docs for setlocale where a more verbose format is used to set the locale. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 20:04 Message: Logged In: YES user_id=1188172 As this is not Windows specific, setting Category to Library. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-08 19:59 Message: Logged In: YES user_id=469548 Still reproducible with Python 2.4: Python 2.4b2 (#19, Nov 8 2004, 11:15:07) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() ['en_US', 'utf'] >>> locale.resetlocale() Traceback (most recent call last): File "", line 1, in ? File "/home/johannes/python/Lib/locale.py", line 389, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting Note that if I run python with 'LANG=nl_NL python', the error does not occur. http://python.org/sf/813449 seems to be the same bug, BTW. ---------------------------------------------------------------------- Comment By: Syver Enstad (syvere) Date: 2002-01-16 14:39 Message: Logged In: YES user_id=428736 Sorry, I forgot to mention the testcase I am using. The test case that fails is the locale module itself, when running it as a standalone application that is. To be more specific: File "d:\devtools\python21\lib\locale.py", line 384, in resetlocale _setlocale(category, _build_localename(getdefaultlocale ())) locale.Error: locale setting not supported And to clarify what input getdefaultlocale returns on my machine: >>> locale.getdefaultlocale() ('no_NO', 'cp1252') and: >>> locale._build_localename(locale.getdefaultlocale()) 'no_NO.cp1252' By the way, is this bug fixed in python 2.2? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-16 12:50 Message: Logged In: YES user_id=21627 Can you provide a detailed test case? AFAIK, no_NO is indeed no supported locale name on Windows, and I don't think Python aanywhere uses it without the application explicitly saying so. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-16 06:07 Message: Logged In: YES user_id=31435 Mark, know anything about this? I don't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 From noreply at sourceforge.net Sun Jun 5 20:28:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 11:28:10 -0700 Subject: [ python-Bugs-755617 ] os module: Need a better description of " mode" Message-ID: Bugs item #755617, was opened at 2003-06-17 02:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Shomphe (mshomphe) Assigned to: Nobody/Anonymous (nobody) Summary: os module: Need a better description of "mode" Initial Comment: The page <http://www.python. org/doc/current/lib/os-file-dir.html> says the following about the function os.chmod: chmod(path, mode) Change the mode of path to the numeric mode. Availability: Unix, Windows. The "mode" values are unclear. It turns out that the UNIX file permission set (e.g., 0666 for read/writeable) works with the Windows set (where 0666 translates to 33206). Is it possible to describe the file permissions in more detail in the documentation at this point? Attached is an email thread discussing this documentation issue. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 20:28 Message: Logged In: YES user_id=1188172 I think the wording suggested by logistix would be a good addition to the docs. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 21:31 Message: Logged In: YES user_id=699438 Something like: "NOTE: Although Windows supports chmod, it incorporates much different functionality than a typical Unix user would expect. Please refer to Microsoft?s documentation for more details." would be nice. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-17 17:18 Message: Logged In: YES user_id=531881 Tim- I captured what Matthew Shomphe recommended into patch 755677 (http://www.python.org/sf/755677). Hope this helps. -c ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-17 16:49 Message: Logged In: YES user_id=31435 Then please suggest the actual text you want to see in the docs. I can't do it for you (for example, chmod has always done exactly what I've wanted it to do on Windows -- but then I've never wanted to do anything with it on Windows beyond fiddling the readonly bit). ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 07:35 Message: Logged In: YES user_id=699438 All I'm saying is that although chmod is valid windows call, it will not produce the effect that most users expect. There's no harm in calling it, but it's not going to accomplish what most users want it to do. This information is more important to a user than other inconsistencies in the Windows implementation. (i.e. os.stat returning a value that is different than chmod set) ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-17 05:37 Message: Logged In: YES user_id=531881 see patch 755677 sheesh neal, you couldn't patch this? ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-17 05:28 Message: Logged In: YES user_id=31435 Well, let's not overreact here -- MS's _chmod simply calls the Win32 SetFileAttributes(), and the only thing it can change is the FILE_ATTRIBUTE_READONLY flag. That's all part of Windows base services, and makes sense on FAT too. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 04:51 Message: Logged In: YES user_id=699438 Realistically, you should NEVER intentionally use chmod to set file permissions on Windows. The FAT filesystem has no permissions, and NTFS has ACLs which are much too complex to map to a chmod style call. MS only has chmod support so they can claim some level of posix compliance. I'm not saying you should drop the ability to call os.chmod on windows, but perhaps the docs should say that its not the recommended way of doing things. Unfortunately, there's not a recommended way of setting security that'll work on all Windows platforms either (although I'd start with os.popen ("cacls ...") Even win32security requires some serious programming just to get started with manipulating ACLs. Typical security looks something like this: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\grant>xcacls "\Program files" C:\Program Files BUILTIN\Users:R BUILTIN\Users:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_EXECUTE BUILTIN\Power Users:C BUILTIN\Power Users:(OI)(CI)(IO)C BUILTIN\Administrators:F BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F BUILTIN\Administrators:F CREATOR OWNER:(OI)(CI)(IO)F C:\Documents and Settings\grant> ---------------------------------------------------------------------- Comment By: Matthew Shomphe (mshomphe) Date: 2003-06-17 04:05 Message: Logged In: YES user_id=716326 Here's my first pass at some additional documentation. My HTML skills are not up to par, but I've tried :) I've attached the document separately. m@ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-17 03:06 Message: Logged In: YES user_id=33168 Could you try to produce a patch to improve the documentation? Or perhaps suggest better wording? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470 From noreply at sourceforge.net Sun Jun 5 23:52:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 14:52:41 -0700 Subject: [ python-Bugs-1215146 ] int('x',radix) puzzle Message-ID: Bugs item #1215146, was opened at 2005-06-05 08:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: elgordo (azgordo) Assigned to: Nobody/Anonymous (nobody) Summary: int('x',radix) puzzle Initial Comment: I don?t understand the built-in function int(x, radix). Or its documentation in the Library Reference section 2.1 ? Built-In Functions. I?m using Python 2.4.1 on Windows XP Pro w/SP2, And I get the following on IDLE: >>> int(9) 9 >>> int('9') 9 >>> int('9',2) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',2) ValueError: invalid literal for int(): 9 >>> int('9',8) Traceback (most recent call last): File "", line 1, in -toplevel- int('9',8) ValueError: invalid literal for int(): 9 >>> int('9',10) 9 >>> int('9',16) 9 >>> int('19',16) 25 >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-05 16:52 Message: Logged In: YES user_id=80475 I find the current wording to be preferable. At some point, adding more words and excessively detailed doc results in docs that are less readable and less communicative. ---------------------------------------------------------------------- Comment By: elgordo (azgordo) Date: 2005-06-05 09:54 Message: Logged In: YES user_id=1291540 OK --- I was confused by the documentation. I'd like to propose the following replacement for the documentation: int([x[, b]]) Converts base b numbers specified by the inputs to their decimal integer equivalents. When the base b is absent x may be either (i) the string representation of a possibly signed decimal integer (possibly embedded in whitespace), or (ii) a possibly signed decimal integer or floating point number (floating point numbers are truncated towards zero). If the base b is present and non-zero, it must be an integer in the range [2, 36] and x must be the possibly signed string representation of an integer in base b notation. When x is a string and the base b is zero, the base actually used is guessed by interpreting the string x in the same way as for integer literals. When b is present then (i) if x is not a string a TypeError is raised, and (ii) if the string x does not represent an integer then a ValueError is raised. Returns 0 if no arguments are given. ---------------------------------------------------------------------- Comment By: elgordo (azgordo) Date: 2005-06-05 09:52 Message: Logged In: YES user_id=1291540 OK --- I was confused by the documentation. I'd like to propose the following replacement for the documentation: int([x[, b]]) Converts base b numbers specified by the inputs to their decimal integer equivalents. When the base b is absent x may be either (i) the string representation of a possibly signed decimal integer (possibly embedded in whitespace), or (ii) a possibly signed decimal integer or floating point number (floating point numbers are truncated towards zero). If the base b is present and non-zero, it must be an integer in the range [2, 36] and x must be the possibly signed string representation of an integer in base b notation. When x is a string and the base b is zero, the base actually used is guessed by interpreting the string x in the same way as for integer literals. When b is present then (i) if x is not a string a TypeError is raised, and (ii) if the string x does not represent an integer then a ValueError is raised. Returns 0 if no arguments are given. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 09:08 Message: Logged In: YES user_id=1188172 The function is behaving as expected. The radix argument specifies which base the number system in the string has. Radix 2 means binary, for example, and radix 16 hexadecimal. >From that, it is clear that '9' is an invalid binary or octal number. In the future, please direct such questions to the Newsgroup comp.lang.python. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215146&group_id=5470 From noreply at sourceforge.net Mon Jun 6 03:50:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 18:50:59 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-23 17:02 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Master_Jaf (master_jaf) >Assigned to: Raymond Hettinger (rhettinger) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 05:27 Message: Logged In: YES user_id=1188172 Attaching a patch for the Tutorial. It adds the following sentence: +Note that with Python 2.2, a new kind of classes was introduced: +A class deriving from \class{object} is called a \emph{new-style class}. +The differences to classic classes are mostly internal, but there are +some features (like properties and static methods) that are only +available for new-style classes. + ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 13:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 07:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 02:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Mon Jun 6 07:20:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 22:20:38 -0700 Subject: [ python-Bugs-887946 ] segfault if redirecting directory Message-ID: Bugs item #887946, was opened at 2004-01-31 11:42 Message generated for change (Comment added) made by mbp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: segfault if redirecting directory Initial Comment: If redirecting directory, python crashes. $ uname -a SunOS xxxxx 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python Python 2.3.2 (#1, Oct 9 2003, 18:59:04) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ mkdir foo $ ls -F foo/ $ python < foo Segmentation Fault -Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2005-06-06 15:20 Message: Logged In: YES user_id=521 I doubt if libc checks whether the input is a directory; there are possible (though extremely obscure) cases where you might want to do that. I think you probably need something along the lines of fstat(0, &buf), then check the st_mode. Remember that fifos and chardevs ought to be allowed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 23:32 Message: Logged In: YES user_id=1038590 Python's C main function assumes stdin, stdout and stderr are all valid FILE pointers. A little experimentation on a Linux box should establish what glibc is providing when the input pipe isn't a proper file (probably stdin == NULL given the symptoms, but that's just a guess) A sanity check on stdin should then be possible near the start of the main function. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 23:24 Message: Logged In: YES user_id=1038590 Win XP SP 1 - C:\Python24>python < Lib "Access is Denied" ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2004-11-05 06:10 Message: Logged In: YES user_id=595280 I did some more test among different versions; 2.4b1/Solaris - segfault 2.3.3/Linux - segfault 2.3.2/Solaris - segfault 2.1.1/Linux - OK 1.5.2/Linux - OK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 From noreply at sourceforge.net Mon Jun 6 07:32:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Jun 2005 22:32:43 -0700 Subject: [ python-Bugs-887946 ] segfault if redirecting directory Message-ID: Bugs item #887946, was opened at 2004-01-31 11:42 Message generated for change (Comment added) made by mbp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: segfault if redirecting directory Initial Comment: If redirecting directory, python crashes. $ uname -a SunOS xxxxx 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python Python 2.3.2 (#1, Oct 9 2003, 18:59:04) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ mkdir foo $ ls -F foo/ $ python < foo Segmentation Fault -Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2005-06-06 15:32 Message: Logged In: YES user_id=521 Here is another failure, which might have the same root cause: $ python /tmp $ echo $? 0 I'd expect this to give an error. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2005-06-06 15:20 Message: Logged In: YES user_id=521 I doubt if libc checks whether the input is a directory; there are possible (though extremely obscure) cases where you might want to do that. I think you probably need something along the lines of fstat(0, &buf), then check the st_mode. Remember that fifos and chardevs ought to be allowed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 23:32 Message: Logged In: YES user_id=1038590 Python's C main function assumes stdin, stdout and stderr are all valid FILE pointers. A little experimentation on a Linux box should establish what glibc is providing when the input pipe isn't a proper file (probably stdin == NULL given the symptoms, but that's just a guess) A sanity check on stdin should then be possible near the start of the main function. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 23:24 Message: Logged In: YES user_id=1038590 Win XP SP 1 - C:\Python24>python < Lib "Access is Denied" ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2004-11-05 06:10 Message: Logged In: YES user_id=595280 I did some more test among different versions; 2.4b1/Solaris - segfault 2.3.3/Linux - segfault 2.3.2/Solaris - segfault 2.1.1/Linux - OK 1.5.2/Linux - OK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 From noreply at sourceforge.net Mon Jun 6 20:16:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 11:16:19 -0700 Subject: [ python-Bugs-1215887 ] String and list methods deeply hidden Message-ID: Bugs item #1215887, was opened at 2005-06-06 20:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 Please note that this 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 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: String and list methods deeply hidden Initial Comment: This is no problem for me anymore, but for beginners it can cause serious headache: The library documentation TOC does nowhere show an entry "string type" or "string methods" or so. To get there, you first have to select "Sequence Types" and then find the link at the bottom. This is not very helpful, and in fact I search a good amount of time for the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 From noreply at sourceforge.net Mon Jun 6 20:21:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 11:21:32 -0700 Subject: [ python-Bugs-1215887 ] String and list methods documentation deeply hidden Message-ID: Bugs item #1215887, was opened at 2005-06-06 20:16 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 Please note that this 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 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) >Summary: String and list methods documentation deeply hidden Initial Comment: This is no problem for me anymore, but for beginners it can cause serious headache: The library documentation TOC does nowhere show an entry "string type" or "string methods" or so. To get there, you first have to select "Sequence Types" and then find the link at the bottom. This is not very helpful, and in fact I search a good amount of time for the first time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 From noreply at sourceforge.net Mon Jun 6 21:19:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 12:19:18 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 15:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Nobody/Anonymous (nobody) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Mon Jun 6 23:29:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Jun 2005 14:29:04 -0700 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 16:15 Message generated for change (Comment added) made by bmaret You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 Please note that this 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 Submitted By: Marc-Antoine Parent (maparent) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-06-06 21:29 Message: Logged In: YES user_id=842097 The patch worked for me (MacOSX 10.4.1, teTeX 3.0). Thanks. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-30 09:23 Message: Logged In: YES user_id=64920 This patch I got from a tex expert seems to fix it. It should also be applied to howto.cls. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-17 21:09 Message: Logged In: YES user_id=64920 I also have this problem when trying to build python-ldap's docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and te_latex-3.0-13. You might wanna take note of this: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/3640&state=open It refers to this module: http://www.tex.ac.uk/tex-archive/macros/latex/contrib/oberdiek/ifpdf.sty ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-04-18 19:53 Message: Logged In: YES user_id=842097 I get the exact same error. I am running MacOSX with teTeX 3.0 installed with Fink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Tue Jun 7 15:23:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 06:23:48 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Nobody/Anonymous (nobody) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Tue Jun 7 19:31:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 10:31:56 -0700 Subject: [ python-Bugs-1216562 ] Replace MSVC memory allocator with ptmalloc2 Message-ID: Bugs item #1216562, was opened at 2005-06-07 17:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216562&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Niall Douglas (ned14) Assigned to: Nobody/Anonymous (nobody) Summary: Replace MSVC memory allocator with ptmalloc2 Initial Comment: You can get a port of ptmalloc2 to win32/win64 at http:// www.nedprod.com/programs/Win32/ptmalloc2/. ptmalloc2 is very considerably faster than the MSVC CRT allocator in small object allocations such as those python would frequently make. If one were to replace python's allocator with ptmalloc2, one should expect to see a sizeable speed increase. As to my knowledge python extension modules don't pass malloced blocks between themselves and the core interpreter, there shouldn't be a problem with calling the wrong allocator with the wrong block. However if there were problems, ptmalloc2 allocated blocks are very easily recognisable from MSVC allocated ones and so the core interpreter could easily free any kind of allocated block. The reverse, unfortunately, is not the case unless one forced all python extension modules to use a python provided allocator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216562&group_id=5470 From noreply at sourceforge.net Tue Jun 7 20:56:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 11:56:54 -0700 Subject: [ python-Bugs-1170422 ] doc speaks of extensions option while it's *called* ext_modu Message-ID: Bugs item #1170422, was opened at 2005-03-25 04:56 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: J?rgen A. Erhard (jae) >Assigned to: A.M. Kuchling (akuchling) Summary: doc speaks of extensions option while it's *called* ext_modu Initial Comment: ext_modules, of course (crap bugtracker) Another minor fix would be to show an import Extension in at least one example. Quite a lot easier to see for the impatient. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-07 14:56 Message: Logged In: YES user_id=11375 This refers to the dist.tex file. I've fixed it on both CVS HEAD and 2.4-maint. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 13:29 Message: Logged In: YES user_id=593130 What I understand is that you want something (literally 'extention option'?) replaced by 'ext_module' somewhere. Could you be more specific as to where (which section of which document, or a url) and what something? Giving the current phrase or sentence and your suggested replacement makes a change decision easier. ---------------------------------------------------------------------- Comment By: J?rgen A. Erhard (jae) Date: 2005-03-25 05:03 Message: Logged In: YES user_id=10380 Ouch, forget about the import Extension... it's there, and I was just blind. Note to self: the usual ;-) (I wish I could edit my own submissions) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470 From noreply at sourceforge.net Tue Jun 7 20:58:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 11:58:58 -0700 Subject: [ python-Bugs-1183972 ] dest parameter in optparse Message-ID: Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 Please note that this message will contain 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 Submitted By: ahmado (ahmado) >Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 From noreply at sourceforge.net Tue Jun 7 21:58:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 12:58:08 -0700 Subject: [ python-Bugs-1172763 ] dumbdbm hoses index on load failure Message-ID: Bugs item #1172763, was opened at 2005-03-29 15:23 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: currivan (currivan) >Assigned to: A.M. Kuchling (akuchling) Summary: dumbdbm hoses index on load failure Initial Comment: Using python to read a dumbdbm db created with jython on Windows, the index got erased. The load failed with an exception due to the python os.linesep being "\n", while the jython version created the db with "\r\n". On exit, the python dumbdbm module committed the empty index it had read, destroying the db. commit (or sync) is implicitly being called on exit from python. dumbdbm ignores the flag it was opened with and commits even if it was opened with 'r'. jython doesn't seem to support any other standard dbm implementation, so I'm stuck with dumbdbm. The problem can be worked around by setting os.linesep manually to enforce consistency. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-07 15:58 Message: Logged In: YES user_id=11375 Another fix, and the one I've just applied to the HEAD and 2.4-maint branches, is to strip off whitespace from the lines in the index file. Thanks for reporting this bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172763&group_id=5470 From noreply at sourceforge.net Tue Jun 7 22:33:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 13:33:55 -0700 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 17:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 Please note that this 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 Submitted By: Marc-Antoine Parent (maparent) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-07 22:33 Message: Logged In: YES user_id=1188172 FWIW, problem exists and patch works for me. Linux 2.6, teTeX 3.0. ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-06-06 23:29 Message: Logged In: YES user_id=842097 The patch worked for me (MacOSX 10.4.1, teTeX 3.0). Thanks. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-30 11:23 Message: Logged In: YES user_id=64920 This patch I got from a tex expert seems to fix it. It should also be applied to howto.cls. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-17 23:09 Message: Logged In: YES user_id=64920 I also have this problem when trying to build python-ldap's docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and te_latex-3.0-13. You might wanna take note of this: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/3640&state=open It refers to this module: http://www.tex.ac.uk/tex-archive/macros/latex/contrib/oberdiek/ifpdf.sty ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-04-18 21:53 Message: Logged In: YES user_id=842097 I get the exact same error. I am running MacOSX with teTeX 3.0 installed with Fink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Wed Jun 8 04:42:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 19:42:38 -0700 Subject: [ python-Bugs-1216831 ] csv module sometimes raises _csv.Error Message-ID: Bugs item #1216831, was opened at 2005-06-08 02: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=1216831&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mary Gardiner (hypatia) Assigned to: Nobody/Anonymous (nobody) Summary: csv module sometimes raises _csv.Error Initial Comment: Tested on 2.3 (Fedora Core 3) and 2.4 (Ubuntu 5.04). The documentation strongly suggests that the csv module raises csv.Error when there are problems parsing the csv, but in fact it sometimes lets _csv.Error escape the C module, as per this example: >>> import csv, StringIO >>> r = csv.reader(StringIO.StringIO('"xx,qq')) >>> r.next() Traceback (most recent call last): File "", line 1, in ? _csv.Error: newline inside string ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216831&group_id=5470 From noreply at sourceforge.net Wed Jun 8 04:52:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Jun 2005 19:52:59 -0700 Subject: [ python-Bugs-1216831 ] csv module sometimes raises _csv.Error Message-ID: Bugs item #1216831, was opened at 2005-06-07 21:42 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216831&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mary Gardiner (hypatia) Assigned to: Nobody/Anonymous (nobody) Summary: csv module sometimes raises _csv.Error Initial Comment: Tested on 2.3 (Fedora Core 3) and 2.4 (Ubuntu 5.04). The documentation strongly suggests that the csv module raises csv.Error when there are problems parsing the csv, but in fact it sometimes lets _csv.Error escape the C module, as per this example: >>> import csv, StringIO >>> r = csv.reader(StringIO.StringIO('"xx,qq')) >>> r.next() Traceback (most recent call last): File "", line 1, in ? _csv.Error: newline inside string ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-06-07 21:52 Message: Logged In: YES user_id=44345 csv.Error and _csv.Error are the same object. The object is defined in the low level _csv module, then imported into the csv module. That the name is "_csv.Error" can't be changed in the context of the csv module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216831&group_id=5470 From noreply at sourceforge.net Wed Jun 8 09:30:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 00:30:54 -0700 Subject: [ python-Bugs-1216923 ] LINKCC->CXX, -ltermcap->-lncurses Message-ID: Bugs item #1216923, was opened at 2005-06-08 09:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216923&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niki W. Waibel (nikiwaibel) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC->CXX, -ltermcap->-lncurses Initial Comment: had troubles building python on various platforms (using gcc-4.0.0 and binutils-2.16.90.0.3): a) Makefile.pre.in had to change $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) -o $@ to $(CXX) $(LDFLAGS) $(LINKFORSHARED) -o $@ for the $(BUILDPYTHON) target. LINKCC was ok for sparc and x86_64 cpus, but *NOT* ok on intel (x86) cpus (solaris AND linux os!). the following error is gone now (using CXX): Modules/ccpython.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0' seems that ccpython.cc is c++ code and so python needs libstdc++ (for some reason only on the intel (x86) cpu. the cleanest way to include that lib is to use g++ instead of gcc. (i dont know wether you need the PURIFY var as well...). b) configure.in: i had to change -ltermcap to -lncurses. otherwise the readline lib on all of my systems was not found. maybe it should be checked in configure wether readline needs termcap or ncurses or none of the libs. c) unfort all my add libs are not in the std include/lib path, neither in /usr/local. so i had to "tune" setup.py. i just changed the lines add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') which is a bad solution. it would be much easier to have variables like LIBDIR and INCLUDEDIR (maybe SYSTEM_LIBDIR, SYSTEM_INCLUDEDIR?) which could be defined as variables or within System.local. the cleanest solution imho would be to use CFLAGS, LDFLAGS and LIBS when building the modules. hope this helps, niki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216923&group_id=5470 From noreply at sourceforge.net Wed Jun 8 11:45:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 02:45:28 -0700 Subject: [ python-Feature Requests-1216944 ] Add Error Code Dictionary to urllib2 Message-ID: Feature Requests item #1216944, was opened at 2005-06-08 09:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Add Error Code Dictionary to urllib2 Initial Comment: In order to properly handle 'HTTPError's from urllib2.urlopen you need to map error codes to an error message. I suggest the addition of the following dictionary to do that : # Table mapping response codes to messages; entries have the # form {code: (shortmessage, longmessage)}. httpresponses = { 100: ('Continue', 'Request received, please continue'), 101: ('Switching Protocols', 'Switching to new protocol; obey Upgrade header'), 200: ('OK', 'Request fulfilled, document follows'), 201: ('Created', 'Document created, URL follows'), 202: ('Accepted', 'Request accepted, processing continues off- line'), 203: ('Non-Authoritative Information', 'Request fulfilled from cache'), 204: ('No response', 'Request fulfilled, nothing follows'), 205: ('Reset Content', 'Clear input form for further input.'), 206: ('Partial Content', 'Partial content follows.'), 300: ('Multiple Choices', 'Object has several resources -- see URI list'), 301: ('Moved Permanently', 'Object moved permanently -- see URI list'), 302: ('Found', 'Object moved temporarily -- see URI list'), 303: ('See Other', 'Object moved -- see Method and URL list'), 304: ('Not modified', 'Document has not changed since given time'), 305: ('Use Proxy', 'You must use proxy specified in Location to access this ' 'resource.'), 307: ('Temporary Redirect', 'Object moved temporarily -- see URI list'), 400: ('Bad request', 'Bad request syntax or unsupported method'), 401: ('Unauthorized', 'No permission -- see authorization schemes'), 402: ('Payment required', 'No payment -- see charging schemes'), 403: ('Forbidden', 'Request forbidden -- authorization will not help'), 404: ('Not Found', 'Nothing matches the given URI'), 405: ('Method Not Allowed', 'Specified method is invalid for this server.'), 406: ('Not Acceptable', 'URI not available in preferred format.'), 407: ('Proxy Authentication Required', 'You must authenticate with ' 'this proxy before proceeding.'), 408: ('Request Time-out', 'Request timed out; try again later.'), 409: ('Conflict', 'Request conflict.'), 410: ('Gone', 'URI no longer exists and has been permanently removed.'), 411: ('Length Required', 'Client must specify Content-Length.'), 412: ('Precondition Failed', 'Precondition in headers is false.'), 413: ('Request Entity Too Large', 'Entity is too large.'), 414: ('Request-URI Too Long', 'URI is too long.'), 415: ('Unsupported Media Type', 'Entity body in unsupported format.'), 416: ('Requested Range Not Satisfiable', 'Cannot satisfy request range.'), 417: ('Expectation Failed', 'Expect condition could not be satisfied.'), 500: ('Internal error', 'Server got itself in trouble'), 501: ('Not Implemented', 'Server does not support this operation'), 502: ('Bad Gateway', 'Invalid responses from another server/proxy.'), 503: ('Service temporarily overloaded', 'The server cannot process the request due to a high load'), 504: ('Gateway timeout', 'The gateway server did not receive a timely response'), 505: ('HTTP Version not supported', 'Cannot fulfill request.'), } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 From noreply at sourceforge.net Wed Jun 8 18:38:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 09:38:52 -0700 Subject: [ python-Feature Requests-1216944 ] Add Error Code Dictionary to urllib2 Message-ID: Feature Requests item #1216944, was opened at 2005-06-08 11:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Add Error Code Dictionary to urllib2 Initial Comment: In order to properly handle 'HTTPError's from urllib2.urlopen you need to map error codes to an error message. I suggest the addition of the following dictionary to do that : # Table mapping response codes to messages; entries have the # form {code: (shortmessage, longmessage)}. httpresponses = { 100: ('Continue', 'Request received, please continue'), 101: ('Switching Protocols', 'Switching to new protocol; obey Upgrade header'), 200: ('OK', 'Request fulfilled, document follows'), 201: ('Created', 'Document created, URL follows'), 202: ('Accepted', 'Request accepted, processing continues off- line'), 203: ('Non-Authoritative Information', 'Request fulfilled from cache'), 204: ('No response', 'Request fulfilled, nothing follows'), 205: ('Reset Content', 'Clear input form for further input.'), 206: ('Partial Content', 'Partial content follows.'), 300: ('Multiple Choices', 'Object has several resources -- see URI list'), 301: ('Moved Permanently', 'Object moved permanently -- see URI list'), 302: ('Found', 'Object moved temporarily -- see URI list'), 303: ('See Other', 'Object moved -- see Method and URL list'), 304: ('Not modified', 'Document has not changed since given time'), 305: ('Use Proxy', 'You must use proxy specified in Location to access this ' 'resource.'), 307: ('Temporary Redirect', 'Object moved temporarily -- see URI list'), 400: ('Bad request', 'Bad request syntax or unsupported method'), 401: ('Unauthorized', 'No permission -- see authorization schemes'), 402: ('Payment required', 'No payment -- see charging schemes'), 403: ('Forbidden', 'Request forbidden -- authorization will not help'), 404: ('Not Found', 'Nothing matches the given URI'), 405: ('Method Not Allowed', 'Specified method is invalid for this server.'), 406: ('Not Acceptable', 'URI not available in preferred format.'), 407: ('Proxy Authentication Required', 'You must authenticate with ' 'this proxy before proceeding.'), 408: ('Request Time-out', 'Request timed out; try again later.'), 409: ('Conflict', 'Request conflict.'), 410: ('Gone', 'URI no longer exists and has been permanently removed.'), 411: ('Length Required', 'Client must specify Content-Length.'), 412: ('Precondition Failed', 'Precondition in headers is false.'), 413: ('Request Entity Too Large', 'Entity is too large.'), 414: ('Request-URI Too Long', 'URI is too long.'), 415: ('Unsupported Media Type', 'Entity body in unsupported format.'), 416: ('Requested Range Not Satisfiable', 'Cannot satisfy request range.'), 417: ('Expectation Failed', 'Expect condition could not be satisfied.'), 500: ('Internal error', 'Server got itself in trouble'), 501: ('Not Implemented', 'Server does not support this operation'), 502: ('Bad Gateway', 'Invalid responses from another server/proxy.'), 503: ('Service temporarily overloaded', 'The server cannot process the request due to a high load'), 504: ('Gateway timeout', 'The gateway server did not receive a timely response'), 505: ('HTTP Version not supported', 'Cannot fulfill request.'), } ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-08 18:38 Message: Logged In: YES user_id=1188172 +1. This would simplify delivering messages to users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 From noreply at sourceforge.net Wed Jun 8 19:26:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 10:26:40 -0700 Subject: [ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3 Message-ID: Bugs item #992017, was opened at 2004-07-16 01:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Ted Bach (bachtor) Assigned to: Nobody/Anonymous (nobody) Summary: code that generates a segfault on Python 2.1-2.3 Initial Comment: On a Redhat Linux 9 based system, the following causes a segfault: """ In python, you can call any expression. """ class foo: def __init__(s,times=1): s.times = times def __call__(s): print s.times def __mul__(s,o): return foo(o) def __coerce__(s,o): if isinstance(o,int): return o,s (foo(3)*10)() # no segfault (10*foo(3))() # segfaults # prints 10 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-08 19:26 Message: Logged In: YES user_id=1188172 Still persists with Python 2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-07 23:44 Message: Logged In: YES user_id=4771 Here is a shorter example: class foo: def __coerce__(self, other): return other, self foo()+1 # segfault: infinite recursion in C classobject.c seems hopelessly prone to infinite recursion in C: whenever an operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() is called again on the result. The most obvious cases of recursion are taken care of, but there are and will always be more convoluted ways to create this recursion. There might be a way to solve the problem cleanly but currently I only see the solution of adding a C recursion check (Py_EnterRecursiveCall / Py_LeaveRecursiveCall). ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 16:18 Message: Logged In: YES user_id=908995 This is not the same problem as bug #980352; this one is an infinite recusion in the instance code (deriving foo from object makes the example work). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-16 15:45 Message: Logged In: YES user_id=6656 Isn't this likely to be a dup of bug [ 980352 ] coercion results used dangerously ? I haven't thought about either very hard, but both involve __coerce__ and core dumps... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 From noreply at sourceforge.net Wed Jun 8 20:22:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 11:22:29 -0700 Subject: [ python-Bugs-1217152 ] Info from man python not in docs Message-ID: Bugs item #1217152, was opened at 2005-06-08 18: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=1217152&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Info from man python not in docs Initial Comment: Some of the information available from 'man python' is not available anywhere else in the docs. In particular there is no comprehensive, detailed listing of all the command line options and environment variables. Consequently this information is not available to users on platforms that don't support man, such as Windows. I suggest adding an appendix to the tutorial or language reference that includes the info from the man page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217152&group_id=5470 From noreply at sourceforge.net Wed Jun 8 23:48:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 14:48:44 -0700 Subject: [ python-Bugs-1171994 ] error in documentation for splitting empty string Message-ID: Bugs item #1171994, was opened at 2005-03-28 12:49 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: error in documentation for splitting empty string Initial Comment: Below is extracted from http://www.python.org/doc/2.4/ lib/string-methods.html describing the string method split(). ----------------------------------------------------------------------- split([sep [,maxsplit]]) ... Splitting an empty string with a specified separator returns an empty list. If sep is not specified or is None, a different splitting algorithm is applied. ... Splitting an empty string returns "['']". ----------------------------------------------------------------------- The rationale for different treatment of splitting an empty string seems to be discussed in 811604. However the documentation seems to be the opposite of actual result. >>> ''.split(',') [''] >>> ''.split() [] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 17:48 Message: Logged In: YES user_id=11375 Fixed by rhettinger's commit in rev. 1.177. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 12:56 Message: Logged In: YES user_id=593130 The new 2.4.1 doc (released today) at http://docs.python.org/lib/string-methods.html remains the same. Verified behavior on 2.2. If unchanged (lest code be broken), there does seem to be a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470 From noreply at sourceforge.net Wed Jun 8 23:57:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 14:57:37 -0700 Subject: [ python-Bugs-1149413 ] bsddb: bug with 'n' flag Message-ID: Bugs item #1149413, was opened at 2005-02-22 17:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 Please note that this message will contain 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 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Gregory P. Smith (greg) >Summary: bsddb: bug with 'n' flag Initial Comment: Where: http://docs.python.org/lib/module-bsddb.html You say there: btopen( filename[, flag[, mode[, btflags[, cachesize[, maxkeypage[, minkeypage[, psize[, lorder]]]]]]]]) the word psize should be replaced with pgsize. An example would help: >>> d = bsddb.btopen(None, "c", cachesize=768000, pgsize=65536) >>> d = bsddb.btopen(None, "n", cachesize=768000, pgsize=65536) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 201, in btopen flags = _checkflag(flag, file) File "/usr/lib/python2.3/bsddb/__init__.py", line 249, in _checkflag if os.path.isfile(file): File "/usr/lib/python2.3/posixpath.py", line 200, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, NoneType found >>> The latter is I believe possibly a bug in the python wrapper not handling 'n' properly. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 17:57 Message: Logged In: YES user_id=11375 I've fixed the documentation to use the right parameter name; thanks for reporting this! The example you give doesn't work for me: it reports 'bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- set_cachesize: method meaningless in shared environment')' with the current CVS head. Removing the cachesize argument makes it work. The 'n' problem does seem to be a bug; the code should check that file is not None before doing os.file.exists(). Reassigning and reclassifying the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 From noreply at sourceforge.net Thu Jun 9 00:10:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 15:10:56 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-05 19:03 Message generated for change (Comment added) made by pocket_aces You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Nobody/Anonymous (nobody) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-08 16:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 07:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 06:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 20:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 20:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 16:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 14:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 11:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 10:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 03:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 01:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 01:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 01:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-05 21:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-05 19:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Thu Jun 9 00:54:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 15:54:28 -0700 Subject: [ python-Bugs-1170331 ] Error in base64.b32decode Message-ID: Bugs item #1170331, was opened at 2005-03-24 23:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: toidinamai (toidinamai) Assigned to: Nobody/Anonymous (nobody) Summary: Error in base64.b32decode Initial Comment: Hi, I believe there is an error in base64.b32decode because it doesn't seem to allow to decode arbitrary binary data: #!/usr/bin/env python2.4 import base64 b64d = base64.b64decode b64e = base64.b64encode print "base64: ", repr(b64d(b64e('\x00'))) b16d = base64.b16decode b16e = base64.b16encode print "base16: ", repr(b16d(b16e('\x00'))) b32d = base64.b32decode b32e = base64.b32encode print "base32: ", repr(b32d(b32e('\x00'))) This raises a very strange exception: Traceback (most recent call last): File "test.py", line 18, in ? print "base32: ", repr(b32d(b32e('\x00'))) File "/usr/lib/python2.4/base64.py", line 228, in b32decode last = binascii.unhexlify(hex(acc)[2:-1]) TypeError: Odd-length string b32 should work just like b64 and b16. Best regards Frank Bensktein. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 18:54 Message: Logged In: YES user_id=11375 Fixed by applying patch #1171487, to both HEAD and 2.4-maint branches. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 13:35 Message: Logged In: YES user_id=593130 Your original report somehow got larded with blank lines that spread it over 4 screens. If you can somehow prevent this next time, it would be much easier to read. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-03-27 14:48 Message: Logged In: YES user_id=699438 patch 1171487 posted. It is pure python so you should be able to incorporate into your existing codebase relatively easily. You won't need to rebuild the python executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470 From noreply at sourceforge.net Thu Jun 9 00:54:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Jun 2005 15:54:47 -0700 Subject: [ python-Bugs-1170331 ] Error in base64.b32decode Message-ID: Bugs item #1170331, was opened at 2005-03-24 23:05 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: toidinamai (toidinamai) >Assigned to: A.M. Kuchling (akuchling) Summary: Error in base64.b32decode Initial Comment: Hi, I believe there is an error in base64.b32decode because it doesn't seem to allow to decode arbitrary binary data: #!/usr/bin/env python2.4 import base64 b64d = base64.b64decode b64e = base64.b64encode print "base64: ", repr(b64d(b64e('\x00'))) b16d = base64.b16decode b16e = base64.b16encode print "base16: ", repr(b16d(b16e('\x00'))) b32d = base64.b32decode b32e = base64.b32encode print "base32: ", repr(b32d(b32e('\x00'))) This raises a very strange exception: Traceback (most recent call last): File "test.py", line 18, in ? print "base32: ", repr(b32d(b32e('\x00'))) File "/usr/lib/python2.4/base64.py", line 228, in b32decode last = binascii.unhexlify(hex(acc)[2:-1]) TypeError: Odd-length string b32 should work just like b64 and b16. Best regards Frank Bensktein. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 18:54 Message: Logged In: YES user_id=11375 Fixed by applying patch #1171487, to both HEAD and 2.4-maint branches. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 13:35 Message: Logged In: YES user_id=593130 Your original report somehow got larded with blank lines that spread it over 4 screens. If you can somehow prevent this next time, it would be much easier to read. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-03-27 14:48 Message: Logged In: YES user_id=699438 patch 1171487 posted. It is pure python so you should be able to incorporate into your existing codebase relatively easily. You won't need to rebuild the python executable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470 From noreply at sourceforge.net Thu Jun 9 14:32:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 05:32:16 -0700 Subject: [ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail() Message-ID: Bugs item #1217513, was opened at 2005-06-09 12:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 Please note that this 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 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Omission in docs for smtplib.SMTP.sendmail() Initial Comment: In Library Reference 11.12.1 SMTP Objects, the description of the to_addrs parameter to SMTP.sendmail() is, "a list of RFC 822 to-address strings". In fact sendmail() also allows a single string to be passed as to_addrs. The comment in smtplib.py says, "to_addrs: A list of addresses to send this mail to. A barestring will be treated as a list with 1 address." I suggest the Library Reference be changed to say, "a list of RFC 822 to-address strings or a single to-address string" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 From noreply at sourceforge.net Thu Jun 9 16:23:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 07:23:16 -0700 Subject: [ python-Bugs-1074261 ] gzip dies on gz files with many appended headers Message-ID: Bugs item #1074261, was opened at 2004-11-27 12:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Eichin (eichin) Assigned to: A.M. Kuchling (akuchling) Summary: gzip dies on gz files with many appended headers Initial Comment: One of the values of the gzip format is that one can reopen for append and the file is, as a whole, still valid. This is accomplished by adding new headers on reopen. gzip.py (as tested on 2.1, 2.3, and 2.4rc1 freshly built) doesn't deal well with more than a certain number of appended headers. The included test case generates (using gzip.py) such a file, runs gzip -tv on it to show that it is valid, and then tries to read it with gzip.py -- and it blows out, with OverflowError: long int too large to convert to int in earlier releases, MemoryError in 2.4rc1 - what's going on is that gzip.GzipFile.read keeps doubling readsize and calling _read again; _read does call _read_gzip_header, and consumes *one* header. So, readsize doubling means that older pythons blow out by not autopromoting past 2**32, and 2.4 blows out trying to call file.read on a huge value - but basically, more than 30 or so headers and it fails. The test case below is based on a real-world queueing case that generates over 200 appended headers - and isn't bounded in any useful way. I'll think about ways to make GzipFile more clever, but I don't have a patch yet. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 10:23 Message: Logged In: YES user_id=11375 Patch applied to both HEAD and 2.4-maint branches; thanks! ---------------------------------------------------------------------- Comment By: Mark Eichin (eichin) Date: 2004-11-27 18:28 Message: Logged In: YES user_id=79734 Patch sent to patch-tracker as 1074381. ---------------------------------------------------------------------- Comment By: Mark Eichin (eichin) Date: 2004-11-27 12:48 Message: Logged In: YES user_id=79734 Oh, this is actually easy to fix: just clamp readsize. After all, you don't *actually* want to try to read gigabyte chunks most of the time. (The supplied patch allows one to override gzip.GzipFile.max_read_chunk if one really does.) Tested on 2.4rc1, and a version backported to 2.1 works there too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&group_id=5470 From noreply at sourceforge.net Thu Jun 9 16:54:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 07:54:40 -0700 Subject: [ python-Bugs-1217591 ] make frameworkinstall fails for non-default location Message-ID: Bugs item #1217591, was opened at 2005-06-09 08:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Jack Jansen (jackjansen) Summary: make frameworkinstall fails for non-default location Initial Comment: Mac OS X 10.3.8, Python 2.4.1. Attempts to 'make frameworkinstall' to a non-default prefix and framework location fail: $ ./configure --prefix= --enable-framework=/Frameworks $ make $ make frameworkinstall The last step always attempts to create /usr/local/bin/python, instead of /bin/python. The immediate cause appears to be line 20 of Mac/OSX/Makefile: bindir=/usr/local/bin The problem is easier to spot if the 'make frameworkinstall' step is performed without root permissions: $ ./configure --prefix=${HOME}/tmp/py241 --enable- framework=${HOME}/tmp/py241/Frameworks ... $ make ... $ make frameworkinstall ... make -f ./Mac/OSX/Makefile installunixtools DIRMODE=755 FILEMODE=644 srcdir=. builddir=. DESTDIR= prefix=/Users/myself/tmp/py241/ Frameworks/Python.framework/Versions/2.4 /usr/bin/install -c -d /usr/local/bin install: chmod 755 /usr/local/bin: Operation not permitted ln -fsn /Users/myself/tmp/py241/Frameworks/Python.framework/ Versions/2.4/bin/python /usr/local/bin/python2.4 ln: /usr/local/bin/python2.4: Permission denied make[1]: *** [installunixtools] Error 1 make: *** [frameworkinstallunixtools] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470 From noreply at sourceforge.net Thu Jun 9 17:41:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 08:41:06 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 15:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Thu Jun 9 17:57:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 08:57:31 -0700 Subject: [ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4" Message-ID: Bugs item #1079134, was opened at 2004-12-04 18:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: A.M. Kuchling (akuchling) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:57 Message: Logged In: YES user_id=11375 Change made to the CVS HEAD version of the document; it'll be backported to the 2.4 maintenance branch before any 2.4.2 release. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-04 21:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 From noreply at sourceforge.net Thu Jun 9 18:01:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 09:01:44 -0700 Subject: [ python-Bugs-1095328 ] Add 'update FAQ' to release checklist Message-ID: Bugs item #1095328, was opened at 2005-01-03 18:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Anthony Baxter (anthonybaxter) >Summary: Add 'update FAQ' to release checklist Initial Comment: http://www.python.org/doc/faq/general.html#how- stable-is-python States that the most stable version is 2.3.3. This should be 2.4.0. Modifying (or checking) this FAQ entry should probably be added to the list of things to be done when a new version is released. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 12:01 Message: Logged In: YES user_id=11375 FAQ updated. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-03 18:07 Message: Logged In: YES user_id=80475 Andrew, can you fix this and then assign to Anthony for inclusion on his checklist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 From noreply at sourceforge.net Thu Jun 9 18:11:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 09:11:52 -0700 Subject: [ python-Bugs-1161031 ] Neverending warnings from asyncore Message-ID: Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-06-09 12:11 Message: Logged In: YES user_id=31435 My guess is rev 1.57. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-09 11:41 Message: Logged In: YES user_id=11375 What change to asyncore caused the problem? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 15:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 03:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 03:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 From noreply at sourceforge.net Thu Jun 9 22:31:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 13:31:55 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Raymond Hettinger (rhettinger) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Thu Jun 9 23:04:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 14:04:03 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 17:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 Please note that this message will contain 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: 6 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 23:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Fri Jun 10 01:38:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 16:38:40 -0700 Subject: [ python-Bugs-1217881 ] pydoc includes unnecessary files for a package. Message-ID: Bugs item #1217881, was opened at 2005-06-09 19:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc includes unnecessary files for a package. Initial Comment: PyDoc lists all files present in a package directory in a "Package Contents" table instead of only the ones listed in __all__ variable in __init__.py file. This is very inconvenient for packages which are wrappers for some C library since the shared library and a Wrapper get the reference on the package page but then they do not have any comments and their pages are not generated. As a result package page has those annoying dead links. One can probably fix this by creating a special dummy pages for those unused files but it's an agly solution. I do believe that using __all__ variable from __init__.py file when it is defined is more appropriate way to know what files represent the contents of the package. Cheers, Igor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 From noreply at sourceforge.net Fri Jun 10 04:18:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Jun 2005 19:18:14 -0700 Subject: [ python-Bugs-1217881 ] pydoc includes unnecessary files for a package. Message-ID: Bugs item #1217881, was opened at 2005-06-09 19:38 Message generated for change (Comment added) made by belyi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc includes unnecessary files for a package. Initial Comment: PyDoc lists all files present in a package directory in a "Package Contents" table instead of only the ones listed in __all__ variable in __init__.py file. This is very inconvenient for packages which are wrappers for some C library since the shared library and a Wrapper get the reference on the package page but then they do not have any comments and their pages are not generated. As a result package page has those annoying dead links. One can probably fix this by creating a special dummy pages for those unused files but it's an agly solution. I do believe that using __all__ variable from __init__.py file when it is defined is more appropriate way to know what files represent the contents of the package. Cheers, Igor ---------------------------------------------------------------------- >Comment By: Igor Belyi (belyi) Date: 2005-06-09 22:18 Message: Logged In: YES user_id=995711 Interestingly, the patch to do this is very small since __all__ variable is already heavy used for other items. Hope it will help, Igor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217881&group_id=5470 From noreply at sourceforge.net Fri Jun 10 12:07:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 03:07:40 -0700 Subject: [ python-Bugs-1218081 ] email.Utils.py: "'" in RFC2231 header Message-ID: Bugs item #1218081, was opened at 2005-06-10 10:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.py: "'" in RFC2231 header Initial Comment: A header like this one can cause ValueError in attempting to decode the RFC2231 format: Content-Disposition: inline; filename*0="Today's Headlines- C.I.A. Is Reviewing Its Security Policy for R"; filename*1="ecruiting Translators.jpg" Note that there is a ' in the filename. MUA should have escaped the ' by %27 but Python email library should be robust for such a violation. Here is the traceback: >>> print p[4]['content-disposition'] inline; filename*0="Today's Headlines- C.I.A. Is Reviewing Its Security Policy for R"; filename*1="ecruiting Translators.jpg" >>> p[4].get_filename() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/email/Message.py", line 707, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/local/lib/python2.4/email/Message.py", line 590, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/local/lib/python2.4/email/Message.py", line 537, in _get_params_pre serve params = Utils.decode_params(params) File "/usr/local/lib/python2.4/email/Utils.py", line 275, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/local/lib/python2.4/email/Utils.py", line 222, in decode_rfc2231 charset, language, s = parts ValueError: need more than 2 values to unpack >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470 From noreply at sourceforge.net Fri Jun 10 12:08:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 03:08:19 -0700 Subject: [ python-Bugs-1218081 ] email.Utils.py: "'" in RFC2231 header Message-ID: Bugs item #1218081, was opened at 2005-06-10 10:07 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils.py: "'" in RFC2231 header Initial Comment: A header like this one can cause ValueError in attempting to decode the RFC2231 format: Content-Disposition: inline; filename*0="Today's Headlines- C.I.A. Is Reviewing Its Security Policy for R"; filename*1="ecruiting Translators.jpg" Note that there is a ' in the filename. MUA should have escaped the ' by %27 but Python email library should be robust for such a violation. Here is the traceback: >>> print p[4]['content-disposition'] inline; filename*0="Today's Headlines- C.I.A. Is Reviewing Its Security Policy for R"; filename*1="ecruiting Translators.jpg" >>> p[4].get_filename() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/email/Message.py", line 707, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/local/lib/python2.4/email/Message.py", line 590, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/local/lib/python2.4/email/Message.py", line 537, in _get_params_pre serve params = Utils.decode_params(params) File "/usr/local/lib/python2.4/email/Utils.py", line 275, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/local/lib/python2.4/email/Utils.py", line 222, in decode_rfc2231 charset, language, s = parts ValueError: need more than 2 values to unpack >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470 From noreply at sourceforge.net Fri Jun 10 13:45:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 04:45:38 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Raymond Hettinger (rhettinger) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Fri Jun 10 15:49:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 06:49:10 -0700 Subject: [ python-Bugs-1218234 ] inspect.getsource doesn't update when a module is reloaded Message-ID: Bugs item #1218234, was opened at 2005-06-10 15: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=1218234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource doesn't update when a module is reloaded Initial Comment: This is test.py: def foo(): print "Bla" And in an interactive session: >>> import inspect, test >>> test.foo() Bla >>> inspect.getsource(test.foo) 'def foo():\n print "Bla"\n' Now I edit test.py to (without exiting the interactive session): def foo(): print "Oh no!" >>> reload(test) >>> test.foo() Oh no! >>> inspect.getsource(test.foo) 'def foo():\n print "Bla"\n' inspect should output the new source. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&group_id=5470 From noreply at sourceforge.net Fri Jun 10 18:34:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 09:34:06 -0700 Subject: [ python-Feature Requests-1218333 ] Create a fat build on darwin Message-ID: Feature Requests item #1218333, was opened at 2005-06-10 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=355470&aid=1218333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Create a fat build on darwin Initial Comment: Apple recently announced that they will switch to intel CPU's for their systems. They request that vendors build fat binaries for software. IMHO the python build process should be changed to make this easily possible. Areas that (might) need changing: * autoconf checks for CPU features (endianness, sizes of basic types). That won't work with cross-builds. A possible solution: create a pycpufeatures.h that hardcodes the information. * distutils might need to be taught about creating fat binaries. * It might be necessary to link to a specific SDK, this in turn might require changes in the autoconf machinery. NOTE: I intend to do some work on this in due time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470 From noreply at sourceforge.net Fri Jun 10 18:36:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 09:36:29 -0700 Subject: [ python-Bugs-1218234 ] inspect.getsource doesn't update when a module is reloaded Message-ID: Bugs item #1218234, was opened at 2005-06-10 15:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource doesn't update when a module is reloaded Initial Comment: This is test.py: def foo(): print "Bla" And in an interactive session: >>> import inspect, test >>> test.foo() Bla >>> inspect.getsource(test.foo) 'def foo():\n print "Bla"\n' Now I edit test.py to (without exiting the interactive session): def foo(): print "Oh no!" >>> reload(test) >>> test.foo() Oh no! >>> inspect.getsource(test.foo) 'def foo():\n print "Bla"\n' inspect should output the new source. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 18:36 Message: Logged In: YES user_id=1188172 This is the fault of the linecache module which inspect uses. It caches the file contents and does not reload it accordingly. However, I assume it's pretty hard finding a good solution to this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&group_id=5470 From noreply at sourceforge.net Sat Jun 11 01:44:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 16:44:36 -0700 Subject: [ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function Message-ID: Feature Requests item #1185383, was opened at 2005-04-18 21:26 Message generated for change (Comment added) made by jonaskoelker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3] [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 03:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-04-28 22:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 22:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 From noreply at sourceforge.net Sat Jun 11 04:26:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Jun 2005 19:26:13 -0700 Subject: [ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function Message-ID: Feature Requests item #1185383, was opened at 2005-04-18 14:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3]Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-10 21:26 Message: Logged In: YES user_id=80475 The whole purpose of the key= argument was to avoid having to build (key, record) tuples. If those are going to be built anyway, then there is little point to using key=. Closing this because: 1) the original use case was better addressed through other methods 2) key= for bisect does not provide the same benefits as it does for other functions. 3) the most recent proposed use is far afield from what key= is supposed to do 4) I think it is bad design and would encourage misguided approaches. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-06-10 18:44 Message: Logged In: YES user_id=1153395 > [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-04-28 15:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 15:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 From noreply at sourceforge.net Sat Jun 11 23:59:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 14:59:15 -0700 Subject: [ python-Bugs-1218930 ] Parser chokes on big files Message-ID: Bugs item #1218930, was opened at 2005-06-11 23:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: Parser chokes on big files Initial Comment: Python 2.4.1 chokes on files generated by gen_py. Sample file attached. Workaround: use the nice pyc compiler (it even becomes faster and smaller source code :)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218930&group_id=5470 From noreply at sourceforge.net Sun Jun 12 06:36:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 21:36:33 -0700 Subject: [ python-Bugs-800432 ] color highlighting not working on EDIT windows Message-ID: Bugs item #800432, was opened at 2003-09-04 08:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: F. Javier Jarava Jarava (developjavier) Assigned to: Kurt B. Kaiser (kbk) Summary: color highlighting not working on EDIT windows Initial Comment: ON idle 1.0/python 2.3/Tk 8.4: When starting IDLE "normally" (ie: with Shell window), and using File->New Window (Ctrl-N) to get a new Edit window, syntax higlihting is off until the contents of the file are saved with a .py extension. BUT, when starting IDLE after configuring it to start with a EDIT window, syntax highlighting is ON for that first window (although not for any other new Edit windows) The behaviour happens both on IDLE as shipped with the python.org 2.3 installer and with cygwin's idle: (idle 1.0, Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin) - started with -n switch to avoid the "missing menus" bug on cygwin) On idle 0.8 (as shipped with ActiveState ActivePython 2.2.2 Build 224) syntax highlighting is ON in edit ("new") windows. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-11 23:36 Message: Logged In: YES user_id=149084 Fixed by Patch 1196895. Jeff Shute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=800432&group_id=5470 From noreply at sourceforge.net Sun Jun 12 06:37:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Jun 2005 21:37:51 -0700 Subject: [ python-Bugs-775012 ] No syntax hilite on new file until saved as *.py Message-ID: Bugs item #775012, was opened at 2003-07-21 08:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Andy Jewell (cybervegan) Assigned to: Kurt B. Kaiser (kbk) Summary: No syntax hilite on new file until saved as *.py Initial Comment: python 2.3c1, on windows xp, uk english. When typing or pasting into a new text window, no syntax highlighting appears until the file is saved with a .py name. I know it doesn't make sense to python-syntax highlight a non-python file, but shouldn't it default to highlighting? IDLE never used to do this - I assume it's a quirk of IDLEfork (maybe intentional behaviour i suppose). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-11 23:37 Message: Logged In: YES user_id=149084 Fixed by Patch 1196895, Jeff Shute. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-09-05 17:15 Message: Logged In: YES user_id=149084 The following from GvR on IDLEfork Bug 763524 30Jun03: "I've been using the latest version from Python CVS on Win9: quite intensively over the last week. Some observations: - When reusing a blank untitled window to edit a Text file, it keeps using Python coloring. - When saving a Python with a non-Python extension (e.g. .txt), it keeps the coloring. - When switching off coloring by saving an untitle buffer as a non-Python extension (e.g. .txt), it keeps existing coloring. - When opening a file reuses a blank untitled window, it doesn't set the focus on the window." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 From noreply at sourceforge.net Sun Jun 12 20:27:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 11:27:31 -0700 Subject: [ python-Bugs-1219273 ] 'Expression' AST Node not documented Message-ID: Bugs item #1219273, was opened at 2005-06-12 11: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=1219273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: 'Expression' AST Node not documented Initial Comment: Python 2.4.1 documentation === The table at the end of section "19.3.1 AST Nodes" does not list Node type 'Expression' and its associated information. Also, the BNF for 'expression' shown in the file > expression ::= > or_test | lambda_form can't be correct because it doesn't cover cases of a simple literals (or identifiers) such as 42 and simple binary operator expressions such as 1+2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470 From noreply at sourceforge.net Sun Jun 12 23:25:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 14:25:08 -0700 Subject: [ python-Bugs-1219342 ] copy.py typo Message-ID: Bugs item #1219342, was opened at 2005-06-13 00:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219342&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: copy.py typo Initial Comment: The __doc__ of Lib/copy.py reads: A shallow copy constructs a new compound object and then (to the extent possible) inserts *the same objects* into in that the original contains. "in" should be "it" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219342&group_id=5470 From noreply at sourceforge.net Mon Jun 13 00:06:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 15:06:13 -0700 Subject: [ python-Bugs-1219361 ] copy.py typo Message-ID: Bugs item #1219361, was opened at 2005-06-13 01: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=1219361&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: copy.py typo Initial Comment: The __doc__ of Lib/copy.py reads: A shallow copy constructs a new compound object and then (to the extent possible) inserts *the same objects* into in that the original contains. "in" should be "it" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219361&group_id=5470 From noreply at sourceforge.net Mon Jun 13 03:14:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 18:14:53 -0700 Subject: [ python-Bugs-1219361 ] copy.py typo Message-ID: Bugs item #1219361, was opened at 2005-06-12 17:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219361&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: copy.py typo Initial Comment: The __doc__ of Lib/copy.py reads: A shallow copy constructs a new compound object and then (to the extent possible) inserts *the same objects* into in that the original contains. "in" should be "it" ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-12 20:14 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219361&group_id=5470 From noreply at sourceforge.net Mon Jun 13 03:17:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 18:17:06 -0700 Subject: [ python-Bugs-1219342 ] copy.py typo Message-ID: Bugs item #1219342, was opened at 2005-06-12 16:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219342&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: copy.py typo Initial Comment: The __doc__ of Lib/copy.py reads: A shallow copy constructs a new compound object and then (to the extent possible) inserts *the same objects* into in that the original contains. "in" should be "it" ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-12 20:17 Message: Logged In: YES user_id=80475 Fixed. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219342&group_id=5470 From noreply at sourceforge.net Mon Jun 13 03:29:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 18:29:07 -0700 Subject: [ python-Bugs-1209560 ] spurious blank page in dist.pdf Message-ID: Bugs item #1209560, was opened at 2005-05-26 19:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: spurious blank page in dist.pdf Initial Comment: In the US Letter sized version of dist.pdf in the current download zip (Python 2.4.1), the third page of the file (the one immediately preceding the table of contents, which starts with roman numeral "i") is blank. That means that page "i" of the table of contents, and page "1" of the actual document, begin on even-numbered pages in the file. This is bad because if you print on a duplex printer, page 1 comes out on the back of page ii, page 3 comes out on the back of page 2, etc. You want odd numbered pages to be on the front and even numbered pages to be on the back, so page 2 should be on the back of page 1, etc. This is probably a problem with the latex extension that made the pdf file and so it probably affects the other pdfs as well as dist.pdf, but that's the only one I printed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 06:12 Message: Logged In: YES user_id=1188172 This indeed happens only in dist.pdf. Attaching a patch which includes the copyright, as in all other documents, and magically, the paging is right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 From noreply at sourceforge.net Mon Jun 13 03:32:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 18:32:41 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 14:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-12 20:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 06:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 15:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 08:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Mon Jun 13 04:56:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Jun 2005 19:56:38 -0700 Subject: [ python-Bugs-1219448 ] small output bug Message-ID: Bugs item #1219448, was opened at 2005-06-12 19:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Levchuk (alevchuk) Assigned to: Nobody/Anonymous (nobody) Summary: small output bug Initial Comment: 6.3 The dir() Function contains a bug: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] here last line should be ['__builtins__', '__doc__', '__name__', 'a', 'fib', 'fibo', 'sys'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219448&group_id=5470 From noreply at sourceforge.net Mon Jun 13 16:12:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 07:12:36 -0700 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 02:27 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-06-13 16:12 Message: Logged In: YES user_id=147070 from test_posixpath.py :: self.assertEqual(posixpath.splitext(".ext"), ("", ".ext")) IMHO should then return (".ext",""). if this is desired :: if i<=p.rfind('/'): return p, '' else: return p[:i], p[i:] should do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Mon Jun 13 19:32:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 10:32:04 -0700 Subject: [ python-Bugs-1219840 ] Need locale arg to strftime() Message-ID: Bugs item #1219840, was opened at 2005-06-13 10:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Nobody/Anonymous (nobody) Summary: Need locale arg to strftime() Initial Comment: strftime()'s behavior is dependant on your current locale. Sometimes this is undesireable, such as when parsing HTTP dates (RFC 2068, 3.3.1), where on is expected to create and parse dates using English month and week names. A similar problem exists with the lower() string method. In either case locale magic isn't always desirable, and it would be useful to add a locale argument to specify which locale to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 From noreply at sourceforge.net Mon Jun 13 20:13:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 11:13:07 -0700 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 14:51 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) >Assigned to: Michael Hudson (mwh) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-13 19:13 Message: Logged In: YES user_id=6656 How about the attached, then? (sorry for the long, long wait) ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-10 13:41 Message: Logged In: YES user_id=774886 The only thing that worries me about that is it takes a different path than ncurses does (or at least 5.4 does). If the env variable isn't set, initscr in ncurses assumes the term type is "unknown" (if no env) and passes "unknown" along, whereas setupterm assumes that if you pass it NULL for the term and the env isn't set, then it simply returns 0. I doubt anyone will have a valid term setup for unknown, but who knows. Beyound that works for me. BTW, the gnu ncurses guys say this is the the behavior in the standard. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-10 11:22 Message: Logged In: YES user_id=6656 The motivation for calling setupterm() ourselves was that I noticed TERM=garbage python -c 'import curses; curses.initscr()' hit the irritating error path too. I also hadn't realised there was a version of initscr in curses/__init__.py, which makes things easier... how about the attached? ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-10 00:06 Message: Logged In: YES user_id=774886 if you pass setupterm 0 for the term name it just tries to get the env variable, so the env test should cover it pretty well. It might make more sense to check the env first and then pass "unkown", setuperm("unknown", -1). This would seem to match the path that curses initscr follows. This would also raise _curses and curses shared exception. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 23:19 Message: Logged In: YES user_id=6656 Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I guess... ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 18:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Mon Jun 13 20:25:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 11:25:29 -0700 Subject: [ python-Bugs-1219862 ] misdocumented argument range for curses.pair_content Message-ID: Bugs item #1219862, was opened at 2005-06-13 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: dcrosta (dcrosta) Assigned to: Nobody/Anonymous (nobody) Summary: misdocumented argument range for curses.pair_content Initial Comment: The documentation for 2.3.5 and 2.4.1 say that the curses module function pair_content take an argument between 0 and COLOR_PAIRS - 1. The underlying curses library function requires an argument between 1 and COLOR_PAIRS -1, inclusive, and giving the value 0 raises a _curses.error (as it should) in python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219862&group_id=5470 From noreply at sourceforge.net Mon Jun 13 20:29:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 11:29:42 -0700 Subject: [ python-Bugs-1180997 ] lax error-checking in new-in-2.4 marshal stuff Message-ID: Bugs item #1180997, was opened at 2005-04-11 20:53 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180997&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: lax error-checking in new-in-2.4 marshal stuff Initial Comment: I realise one of the points of the TYPE_STRINGREF and so on stuff was efficiency, but: >>> marshal.loads('R') # TYPE_STRINGREF == 'R' Segmentation fault ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-13 19:29 Message: Logged In: YES user_id=6656 This turned out to be easier to fix than I expected, so I fixed it. Python/marshal.c revision 1.86 Lib/test/test_marshal.py revision 1.12 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-13 11:05 Message: Logged In: YES user_id=6656 While I have your attention: >>> marshal.loads("", 1) Segmentation fault This is the guilty line: if (!PyArg_ParseTuple(args, "s#|i:loads", &s, &n)) there's no pointer corresponding to the optional integer argument. I'd just fix this, but I have too many local changes to make it easy :( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-11 22:25 Message: Logged In: YES user_id=21627 I agree, and will try to work on a patch before 2.4.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180997&group_id=5470 From noreply at sourceforge.net Mon Jun 13 21:10:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 12:10:29 -0700 Subject: [ python-Bugs-1219903 ] tp_richcompare documentation wrong and incomplete Message-ID: Bugs item #1219903, was opened at 2005-06-13 15: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=1219903&group_id=5470 Please note that this 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: 6 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tp_richcompare documentation wrong and incomplete Initial Comment: tp_richcompare slot as documented here: http://www.python.org/doc/current/api/type-structs.html is incorrect. It states: "The signature is the same as for PyObject_RichCompare(). The function should return 1 if the requested comparison returns true, 0 if it returns false. It should return -1 and set an exception condition when an error occurred during the comparison" However PyObject_RichCompare() actually returns a PyObject* not an int. The documentation at this location really should spell out the full specification for the richcomparefunc. In addition, it's not exactly clear how to implement unordered comparisons (ones where == and != work, but <, >, <=, >= don't). You cannot return Py_NotImplemented because richcomp always falls back to pointer comparison unless PyInstance_Check() is true. For extension types, this won't be the case and the right thing to do is actually raise the exception in the richcomp function. This needs to be documented too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219903&group_id=5470 From noreply at sourceforge.net Mon Jun 13 22:05:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 13:05:56 -0700 Subject: [ python-Bugs-1218930 ] Parser chokes on big files Message-ID: Bugs item #1218930, was opened at 2005-06-11 23:59 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: Parser chokes on big files Initial Comment: Python 2.4.1 chokes on files generated by gen_py. Sample file attached. Workaround: use the nice pyc compiler (it even becomes faster and smaller source code :)) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-06-13 22:05 Message: Logged In: YES user_id=89016 Closing, as this is a duplicate of bug #1175396. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218930&group_id=5470 From noreply at sourceforge.net Tue Jun 14 07:04:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Jun 2005 22:04:02 -0700 Subject: [ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE Message-ID: Bugs item #1220113, was opened at 2005-06-14 15:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:41:02 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 03:41 Message: Logged In: YES user_id=80475 Closed due to lack of use cases and my deep suspicion that it is the wrong thing to do. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-06-03 15:45 Message: Logged In: YES user_id=555 I like rhettinger's "iter(s).next()" solution quite well, except that it's kind of an obscure way to say "give me an element of this set". I'm completely okay with the idea that the choose method may or may not return the same element each time--I just want a "for example" element. To my thinking, pop() isn't really a good solution because it treats sets and frozensets differently. Plus a pop()/add() cycle seems wasteful and confusing. One could argue that in the other place where pop() is available (lists), there is also a simple way to "peek" at what would be popped, which is kind of what we're talking about here. As for a use case, I'm not sure I have a great one. This came up when I was writing some union/find code. I was using sets to represent equivalence classes and I wanted to be able to grab a representative of a set (which would be any element of the set), given the set. I was surprised to find that there didn't seem to be a straightforward way to do this. I agree that I could just copy your 'choose' function into my code easily. There are several such functions that I already copy into pretty much every script I write these days (warn, error, and groupby, which probably do just what you think they do). If it's something that would be broadly useful, though, it seems like it'd be a lot more efficient for everyone to know the function by the same name (i.e., by having it be in the standard library). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:47:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:47:39 -0700 Subject: [ python-Bugs-1215887 ] String and list methods documentation deeply hidden Message-ID: Bugs item #1215887, was opened at 2005-06-06 13:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: String and list methods documentation deeply hidden Initial Comment: This is no problem for me anymore, but for beginners it can cause serious headache: The library documentation TOC does nowhere show an entry "string type" or "string methods" or so. To get there, you first have to select "Sequence Types" and then find the link at the bottom. This is not very helpful, and in fact I search a good amount of time for the first time. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 03:47 Message: Logged In: YES user_id=80475 See Doc/lib/libstdtypes.tex 1.181 and 1.170.2.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215887&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:47:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:47:55 -0700 Subject: [ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE Message-ID: Bugs item #1220113, was opened at 2005-06-14 00:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Peter ?strand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:52:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:52:30 -0700 Subject: [ python-Bugs-1213475 ] Queue.qsize() better info about unreliability Message-ID: Bugs item #1213475, was opened at 2005-06-02 07:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: Queue.qsize() better info about unreliability Initial Comment: I know Queues are supposed to be used mostly in threads apps. since they are not banned to apps without threads, I think that | qsize(self) | Return the approximate size of the queue (not reliable!). can be better. You mean not reliable (or unreliable :D) because of threads right? if you mean *GENERALLY* because of when ti goes to next instruction it might have change, then put this not reliable thing in len() too ;) I propose: (urreliable if using threads) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 03:52 Message: Logged In: YES user_id=80475 In Py2.4.1, the wording is already: Because of multithreading semantics, this number is not reliable. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-06-02 08:02 Message: Logged In: YES user_id=865368 or better: qsize() :: "Return the approximate size of the queue. Because of multithreading semantics, this number is not reliable." (RexxFi) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:57:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:57:16 -0700 Subject: [ python-Bugs-1219448 ] small output bug Message-ID: Bugs item #1219448, was opened at 2005-06-12 21:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Levchuk (alevchuk) Assigned to: Nobody/Anonymous (nobody) Summary: small output bug Initial Comment: 6.3 The dir() Function contains a bug: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] here last line should be ['__builtins__', '__doc__', '__name__', 'a', 'fib', 'fibo', 'sys'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219448&group_id=5470 From noreply at sourceforge.net Tue Jun 14 10:59:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 01:59:15 -0700 Subject: [ python-Bugs-1219840 ] Need locale arg to strftime() Message-ID: Bugs item #1219840, was opened at 2005-06-13 12:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) >Assigned to: Brett Cannon (bcannon) Summary: Need locale arg to strftime() Initial Comment: strftime()'s behavior is dependant on your current locale. Sometimes this is undesireable, such as when parsing HTTP dates (RFC 2068, 3.3.1), where on is expected to create and parse dates using English month and week names. A similar problem exists with the lower() string method. In either case locale magic isn't always desirable, and it would be useful to add a locale argument to specify which locale to use. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 03:59 Message: Logged In: YES user_id=80475 Brett, do you want to take this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 From noreply at sourceforge.net Tue Jun 14 11:04:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 02:04:16 -0700 Subject: [ python-Bugs-1214859 ] subprocess auto-reaps children Message-ID: Bugs item #1214859, was opened at 2005-06-04 11:42 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) >Assigned to: Peter ?strand (astrand) Summary: subprocess auto-reaps children Initial Comment: The subprocess module automatically reaps child processes, by maintaining a list of instances which is traversed each time a new Popen instance is created. Apparently this was originally intended to avoid large number of zombie processes to accrete in the system if the programmer is lazy and does not wait for them properly, but it can cause problems when the programmer wants greater control. In particular, it's not possible to use the pid from a subprocess.Popen instance, since it may already have disappeared. For instance, it makes it difficult to use os.wait() to wait for several child processes at the same time. The solution is simple: Add an option that disables the auto-reaper for a Popen instance. This makes everyone happy: existing code is unaffected, the programmer who wants to control her processes herself is allowed to do that, and the documentation is improved to help avoiding a nasty bug. A patch was posted to the patch tracker as number 1187312. I suggest it for inclusion into the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 From noreply at sourceforge.net Tue Jun 14 11:42:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 02:42:28 -0700 Subject: [ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu) Message-ID: Bugs item #1206537, was opened at 2005-05-22 09:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Submitted By: Raik Gruenberg (graik) >Assigned to: Nobody/Anonymous (nobody) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ): pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 09:08 Message: Logged In: YES user_id=4771 Of course, the weakref documentation is ultimately right, and the problem, unrelated to bound methods, is that you always get a dead weakref if you do weakref.ref() But I'm not being particularly helpful here. A trick simpler than the cookbook proposals is to force the method object to be alive as long as the instance itself by storing it on the instance: obj = MyClass() obj.m = obj.m ref = weakref.ref(obj.m) This works because the last "obj.m" returns an existing object, as opposed to one created just-in-time. This might be mentioned in the weakref documentation with the comment that it's a general rule to be careful not to take weakrefs to short-lived object; the same problem would occur e.g. when taking a weakref to "obj.a" where "a" is a computed property. Storing the result back on "obj" -- under the same or another name -- is a workaround. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 From noreply at sourceforge.net Tue Jun 14 12:14:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 03:14:13 -0700 Subject: [ python-Feature Requests-1212091 ] sets needs an 'arbitrary element' method Message-ID: Feature Requests item #1212091, was opened at 2005-05-31 16:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-14 11:14 Message: Logged In: YES user_id=6656 Just a comment that I've actually wanted this function recently; in the case where the set has a single element, it can be interesting to know what that element is. It's not a big thing, iter(s).next() works, but it's obscure. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 09:41 Message: Logged In: YES user_id=80475 Closed due to lack of use cases and my deep suspicion that it is the wrong thing to do. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-06-03 21:45 Message: Logged In: YES user_id=555 I like rhettinger's "iter(s).next()" solution quite well, except that it's kind of an obscure way to say "give me an element of this set". I'm completely okay with the idea that the choose method may or may not return the same element each time--I just want a "for example" element. To my thinking, pop() isn't really a good solution because it treats sets and frozensets differently. Plus a pop()/add() cycle seems wasteful and confusing. One could argue that in the other place where pop() is available (lists), there is also a simple way to "peek" at what would be popped, which is kind of what we're talking about here. As for a use case, I'm not sure I have a great one. This came up when I was writing some union/find code. I was using sets to represent equivalence classes and I wanted to be able to grab a representative of a set (which would be any element of the set), given the set. I was surprised to find that there didn't seem to be a straightforward way to do this. I agree that I could just copy your 'choose' function into my code easily. There are several such functions that I already copy into pretty much every script I write these days (warn, error, and groupby, which probably do just what you think they do). If it's something that would be broadly useful, though, it seems like it'd be a lot more efficient for everyone to know the function by the same name (i.e., by having it be in the standard library). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 17:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 16:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 From noreply at sourceforge.net Tue Jun 14 16:48:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 07:48:23 -0700 Subject: [ python-Bugs-1219862 ] misdocumented argument range for curses.pair_content Message-ID: Bugs item #1219862, was opened at 2005-06-13 14:25 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: dcrosta (dcrosta) >Assigned to: A.M. Kuchling (akuchling) Summary: misdocumented argument range for curses.pair_content Initial Comment: The documentation for 2.3.5 and 2.4.1 say that the curses module function pair_content take an argument between 0 and COLOR_PAIRS - 1. The underlying curses library function requires an argument between 1 and COLOR_PAIRS -1, inclusive, and giving the value 0 raises a _curses.error (as it should) in python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-14 10:48 Message: Logged In: YES user_id=11375 Fixed on both the HEAD and 2.4-maint branches. Thanks for reporting the error! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219862&group_id=5470 From noreply at sourceforge.net Tue Jun 14 16:55:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 07:55:18 -0700 Subject: [ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file Message-ID: Bugs item #1191043, was opened at 2005-04-27 10:34 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470 Please note that this message will contain 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 Submitted By: Chris AtLee (catlee) Assigned to: Raymond Hettinger (rhettinger) Summary: bz2 RuntimeError when decompressing file Initial Comment: The following code: echo -n Testing123 | bzip2 > test.bz2 python -c "import bz2; lines = bz2.BZ2File('test.bz2').readlines()" produces this output: Traceback (most recent call last): File "", line 1, in ? RuntimeError: wrong sequence of bz2 library commands used Tested on Python 2.4.1 (debian unstable - April 1 2005), and Python 2.3.5 (debian unstable - May 26 2005) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-14 10:55 Message: Logged In: YES user_id=11375 Calling .readline() works fine, though. The problem wasn't apparent with a quick look at the readlines() code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 08:14 Message: Logged In: YES user_id=80475 Okay, I see. Will look into it. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2005-04-28 08:00 Message: Logged In: YES user_id=186532 How is test.bz2 not a valid bz2 file? The command line tool "bzcat" or "bunzip2" can operate properly on it. Using BZ2File("test.bz2").read() works properly, it's just the readlines() call that breaks. Try this out: import bz2 bz2.BZ2File("test.bz2","w").write("testing123") # This works fine assert bz2.BZ2File("test.bz2").read() == "testing123" # This raises a RuntimeError assert bz2.BZ2File("test.bz2").readlines() == ["testing123"] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 03:06 Message: Logged In: YES user_id=80475 The looks like correct behavior to me. The test.bz2 file is not in a valid bz2 format. I suspect that you've misread the BZ2File API which is intended for reading and writing uncompressed data to and from a file in a bz2 format (where the data is stored in compressed form). If this interpretation of the bug report is correct, please mark as not-a-bug and close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470 From noreply at sourceforge.net Tue Jun 14 16:59:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 07:59:16 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 14:24 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) >Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 06:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Tue Jun 14 17:39:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 08:39:34 -0700 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 09:14 Message generated for change (Comment added) made by pietervd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Christoph Mussenbrock (mussenbrock) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- Comment By: Pieter Van Dyck (pietervd) Date: 2005-06-14 17:39 Message: Logged In: YES user_id=1240437 I've run into the same bug so allow me to comment. client environment: windows XP target: Apache/1.3.33 (Unix) checked on: python 2.3.4, 2.3.5, 2.4.1 To reproduce: # from urllib2 import ... proxy = {"http":"http://user:pwd at proxy:port"} opener =build_opener(ProxyHandler(proxy)) install_opener( opener ) req = Request(coolurl) # construct base64string = base64.encodestring('%s:%s' % (site_user, site_pwd))[:-1] authheader = "Basic %s" % base64string req.add_header("Authorization", authheader) urlopen( req ) Symptoms: authentication failed on coolurl (HTTPError 401) Fix: Applying the patch solves the problem for me It appears as if the receiving server treats the empty line as the end of the header even though it strictly shouldn't. HTH Pieter ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:50 Message: Logged In: YES user_id=113328 The change was introduced by revision 1.32 of the file, from patch 527518. There's no mention of removing strip() there, so I suspect it was an accident. The strip() is still missing in CVS HEAD. I can see the problem, in theory (base64.encodestring returns a string with a terminating newline). However, I cannot reproduce the problem. Can the original poster provide a means of verifying the problem? It may be useful as a test case. Regardless, the change seems harmless, and can probably be applied. I attach a patch against CVS HEAD: --- urllib2.py.orig 2005-01-09 05:51:49.000000000 +0000 +++ urllib2.py 2005-01-29 21:31:49.000000000 +0000 @@ -582,7 +582,8 @@ if ':' in user_pass: user, password = user_pass.split(':', 1) user_pass = base64.encodestring('%s:%s' % (unquote(user), - unquote(password))) + unquote(password)) + ).strip() req.add_header('Proxy-authorization', 'Basic ' + user_pass) host = unquote(host) req.set_proxy(host, type) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Tue Jun 14 23:16:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 14:16:47 -0700 Subject: [ python-Bugs-1220756 ] Re-importing embedded thread dumps core Message-ID: Bugs item #1220756, was opened at 2005-06-14 17:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Re-importing embedded thread dumps core Initial Comment: I noticed the following while working on an "embedding numarray" problem: [jmiller at halloween Python-2.4.1]$ Python-2.4.1/Demo/embed/loop 'from thread import *' 10 [6675 refs] [7009 refs] [7320 refs] [7631 refs] [7942 refs] [8253 refs] loop: Objects/typeobject.c:2104: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed. Abort (core dumped) The tp_flags bit in question is: #define Py_TPFLAGS_HEAPTYPE (1L<<9) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 From noreply at sourceforge.net Wed Jun 15 03:42:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 18:42:50 -0700 Subject: [ python-Feature Requests-1218333 ] Create a fat build on darwin Message-ID: Feature Requests item #1218333, was opened at 2005-06-10 12:34 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Create a fat build on darwin Initial Comment: Apple recently announced that they will switch to intel CPU's for their systems. They request that vendors build fat binaries for software. IMHO the python build process should be changed to make this easily possible. Areas that (might) need changing: * autoconf checks for CPU features (endianness, sizes of basic types). That won't work with cross-builds. A possible solution: create a pycpufeatures.h that hardcodes the information. * distutils might need to be taught about creating fat binaries. * It might be necessary to link to a specific SDK, this in turn might require changes in the autoconf machinery. NOTE: I intend to do some work on this in due time. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-06-14 21:42 Message: Logged In: YES user_id=139309 There's a lot of things to consider here, including but not limited to: If building universal binaries that maintain compatibility with Mac OS X 10.3 (two SDK), you'll need to build i386 and ppc architectures separately and lipo them together (might as well do ppc64 too). If building universal binaries that maintain compatibility with Mac OS X 10.2 (two SDKs, and two compilers!), you'll need to build with GCC 3.3 on ppc and GCC 4.0 on i386 with entirely different CFLAGS/LDFLAGS/ MACOSX_DEPLOYMENT_TARGET than the i386 side of things (that's scary). Some modules aren't available for every arch. For example, psyco isn't really useful except on i386. PyObjC, anything that links to Carbon, etc. isn't going to compile on ppc64, etc. If the ".so" is there (i.e. universal binaries for plugins) then the PyImport machinery will see it, try and import it, and get a very nasty low-level dyld error. Either the PyImport machinery should inherit code that checks for arch sanity, or there should be separate naming conventions (.i386.so) or locations (site- packages-ppc) for each arch! Because of the previous consideration, there will have to be ways to tell distutils which architectures you want to compile for.. perhaps just native by default, but allow (multiple-?)SDK multiple-arch builds if requested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470 From noreply at sourceforge.net Wed Jun 15 04:14:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Jun 2005 19:14:55 -0700 Subject: [ python-Bugs-1219840 ] Need locale arg to strftime() Message-ID: Bugs item #1219840, was opened at 2005-06-13 10:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Brett Cannon (bcannon) Summary: Need locale arg to strftime() Initial Comment: strftime()'s behavior is dependant on your current locale. Sometimes this is undesireable, such as when parsing HTTP dates (RFC 2068, 3.3.1), where on is expected to create and parse dates using English month and week names. A similar problem exists with the lower() string method. In either case locale magic isn't always desirable, and it would be useful to add a locale argument to specify which locale to use. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-06-14 19:14 Message: Logged In: YES user_id=357491 There is an issue with this idea. strftime() is just a wrapper around the ISO C library function. We have no direct control over the locale handling. This means that the locale used by strftime() is dictated by the locale that the ISO C libraries think you have. Best thing to do is to temporarily change the locale to what you need, use strftime(), and then set the locale back. PEP 342 would be nice for this. =) At best this is what strftime() would have to do behind the scenes for you. And the extra overhead is not totally desirable. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 01:59 Message: Logged In: YES user_id=80475 Brett, do you want to take this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 From noreply at sourceforge.net Wed Jun 15 13:35:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 04:35:55 -0700 Subject: [ python-Bugs-1220756 ] Re-importing embedded thread dumps core Message-ID: Bugs item #1220756, was opened at 2005-06-14 22:16 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Re-importing embedded thread dumps core Initial Comment: I noticed the following while working on an "embedding numarray" problem: [jmiller at halloween Python-2.4.1]$ Python-2.4.1/Demo/embed/loop 'from thread import *' 10 [6675 refs] [7009 refs] [7320 refs] [7631 refs] [7942 refs] [8253 refs] loop: Objects/typeobject.c:2104: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed. Abort (core dumped) The tp_flags bit in question is: #define Py_TPFLAGS_HEAPTYPE (1L<<9) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-15 12:35 Message: Logged In: YES user_id=6656 Oh dear. The problem here is that PyModule_AddObject steals a reference to the object, but this is not taken care of in threadmodule.c (or gcmodule, it turns out, and I bet many other places). Shouldn't be too hard to fix. (Looks like noone's run Demo/embed/loop for a while...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 From noreply at sourceforge.net Wed Jun 15 13:42:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 04:42:19 -0700 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 06:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) >Assigned to: Michael Hudson (mwh) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-15 12:42 Message: Logged In: YES user_id=6656 This issue should finally be dead in Python CVS HEAD. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-19 16:35 Message: Logged In: YES user_id=6656 And, er, how do you do that? AFAIK, isnan is in SUS and C99 and recommended by IEEE-754 but isn't in plain old ANSI C... I also suspect that it's supported by all platforms we care about that, but certainly wouldn't swear to it. OTOH, pyport.h seems to have a Py_IS_NAN macro already. Maybe that would work, at least enough of the time to be useful... ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-19 03:10 Message: Logged In: YES user_id=2772 If this is all accidental behavior, maybe something (marshal? the compiler?) could issue a warning when a special value is parsed, or marshal.dump()'d. Imagining something like: >>> 2e308 :1: OverflowWarning: behavior of special floating-point value undefined. inf Or else: >>> marshal.dumps(2e308) :1: RuntimeWarning: marshal of special floating-point value undefined. 's\x05\x00\x00\x002e308' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 17:33 Message: Logged In: YES user_id=31435 BTW, while nothing is guaranteed here, your best shot at working (albeit still by accident) portable code is to use expressions that don't tickle IEEE special values directly. For example, use pinf = 1e300 * 1e300 minf = -pinf nan = pinf - pinf That will work the same way from .py or .pyc. Whether pinf is actually +Infinity and nan is actually a NaN then remain platform-dependent accidents, but they will be on the majority platforms (Linux and Windows, using gcc or MSVC to compile Python). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 17:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 13:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 07:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Wed Jun 15 14:28:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 05:28:47 -0700 Subject: [ python-Bugs-1220756 ] Re-importing embedded thread dumps core Message-ID: Bugs item #1220756, was opened at 2005-06-14 22:16 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) >Assigned to: Neil Schemenauer (nascheme) Summary: Re-importing embedded thread dumps core Initial Comment: I noticed the following while working on an "embedding numarray" problem: [jmiller at halloween Python-2.4.1]$ Python-2.4.1/Demo/embed/loop 'from thread import *' 10 [6675 refs] [7009 refs] [7320 refs] [7631 refs] [7942 refs] [8253 refs] loop: Objects/typeobject.c:2104: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed. Abort (core dumped) The tp_flags bit in question is: #define Py_TPFLAGS_HEAPTYPE (1L<<9) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-15 13:28 Message: Logged In: YES user_id=6656 Fixed the issue in the report in revision 2.62 of Modules/threadmodule.c. I'm leaving this open because "./loop 'import gc'" crashes and because I think there are too many places that incref before PyModule_AddObject()... Neil, any ideas about the gc one? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-15 12:35 Message: Logged In: YES user_id=6656 Oh dear. The problem here is that PyModule_AddObject steals a reference to the object, but this is not taken care of in threadmodule.c (or gcmodule, it turns out, and I bet many other places). Shouldn't be too hard to fix. (Looks like noone's run Demo/embed/loop for a while...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 From noreply at sourceforge.net Wed Jun 15 20:17:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 11:17:23 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 11:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Nobody/Anonymous (nobody) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Wed Jun 15 21:26:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 12:26:23 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 14:17 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) >Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Wed Jun 15 21:46:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 12:46:46 -0700 Subject: [ python-Bugs-1221477 ] Incorrect documentation for InPlace Number operators Message-ID: Bugs item #1221477, was opened at 2005-06-15 12:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation for InPlace Number operators Initial Comment: The documentation for the various InPlace abstract number operators (PyNumber_InPlaceSubtract, etc.) specify that the functions return a new reference. Unless I'm mistaken, this is incorrect. The functions do not increment increment the reference counter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 From noreply at sourceforge.net Wed Jun 15 22:18:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 13:18:28 -0700 Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11 Message-ID: Bugs item #1071597, was opened at 2004-11-23 04:30 Message generated for change (Comment added) made by cbeatley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem on HP-UX 11.11 Initial Comment: Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ Using gcc 3.3.3 to build on HP-UX 11.11, the configure out of the box is a bit off, resulting in a failed build, due to missing thread symbols: /usr/ccs/bin/ld: Unsatisfied symbols: PyThread_acquire_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_exit_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_allocate_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_free_lock (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_start_new_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_release_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_get_thread_ident (first referenced in libpython2.4.a(import.o)) (code) PyThread__init_thread (first referenced in libpython2.4.a(thread.o)) (code) collect2: ld returned 1 exit status A workaround is to manually edit pyconfig.h, adding #define _POSIX_THREADS (The reason it is not picked up is that unistd.h on HP-UX has this comment: /************************************************************************ * The following defines are specified in the standard, but are not yet * implemented: * * _POSIX_THREADS can't be defined until all * features are implemented ) The implementation seems however to be sufficiently complete to permit compiling and running Python with _POSIX_THREADS. While I'm editing pyconfig.h, I also comment out _POSIX_C_SOURCE definition, as it will result in lots of compilation warnings, of the style: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Python-2.4c1/Include -DPy_BUILD_CORE -o Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c In file included from ../Python-2.4c1/Include/Python.h:8, from ../Python-2.4c1/Objects/frameobject.c:4: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition ------------ So, to recapitulate: After configure, add #define _POSIX_THREADS and comment out #define _POSIX_C_SOURCE 200112L That will give you a Python working rather well, with "make test" producing: 251 tests OK. 1 test failed: test_pty 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on hp-ux11: test_tcl ---------------------------------------------------------------------- Comment By: Cameron Beatley (cbeatley) Date: 2005-06-15 15:18 Message: Logged In: YES user_id=991535 I have the same problems. When I edit the pyconfig.h file as described and run Make again, I get the following Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/CVS/apps/Python-2.4.1/Lib/distutils/core.py", line 123, in setup dist.parse_config_files() File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 339, in parse_config_files filenames = self.find_config_files() File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 302, in find_config_files check_environ() File "/CVS/apps/Python-2.4.1/Lib/distutils/util.py", line 155, in check_environ import pwd ImportError: No module named pwd *** Error exit code 1 any idea what THIS is? ---------------------------------------------------------------------- Comment By: Harri Pasanen (harripasanen) Date: 2005-01-06 05:01 Message: Logged In: YES user_id=77088 Note that the _POSIX_C_SOURCE is also defined for gcc 3.4.3 on HP-UX 11.23 (Itanium). I don't know if it defined for all the gcc platforms, as it would only show up if the definition in pyconfig.h is different from what the gcc driver uses. ---------------------------------------------------------------------- Comment By: Harri Pasanen (harripasanen) Date: 2005-01-05 08:46 Message: Logged In: YES user_id=77088 _POSIX_C_SOURCE appears to come from the gcc driver, along with a few other macros. If I add "-v" to compilation, the output expands to: Reading specs from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs Configured with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure --enable-languages=c,c++ --enable-threads=posix --disable-nls --with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as --prefix=/usr/local Thread model: posix gcc version 3.3.3 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. -I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE Modules/python.c -quiet -dumpbase python.c -auxbase-strip Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version -fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s GNU C version 3.3.3 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 3.3.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: . Include /usr/local/include /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/include /usr/include End of search list. In file included from Include/Python.h:8, from Modules/python.c:3: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition /usr/local/bin/as --traditional-format -o Modules/python.o /var/tmp//ccLnAhZ0.s ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-23 17:50 Message: Logged In: YES user_id=21627 Can you find out why gcc says that "_POSIX_C_SOURCE" is defined on the command line? On the command line you provide, it isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 From noreply at sourceforge.net Wed Jun 15 22:54:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 13:54:19 -0700 Subject: [ python-Bugs-1216562 ] Replace MSVC memory allocator with ptmalloc2 Message-ID: Bugs item #1216562, was opened at 2005-06-07 19:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216562&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Niall Douglas (ned14) Assigned to: Nobody/Anonymous (nobody) Summary: Replace MSVC memory allocator with ptmalloc2 Initial Comment: You can get a port of ptmalloc2 to win32/win64 at http:// www.nedprod.com/programs/Win32/ptmalloc2/. ptmalloc2 is very considerably faster than the MSVC CRT allocator in small object allocations such as those python would frequently make. If one were to replace python's allocator with ptmalloc2, one should expect to see a sizeable speed increase. As to my knowledge python extension modules don't pass malloced blocks between themselves and the core interpreter, there shouldn't be a problem with calling the wrong allocator with the wrong block. However if there were problems, ptmalloc2 allocated blocks are very easily recognisable from MSVC allocated ones and so the core interpreter could easily free any kind of allocated block. The reverse, unfortunately, is not the case unless one forced all python extension modules to use a python provided allocator. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-06-15 22:54 Message: Logged In: YES user_id=21627 I'm rejecting the idea. There is no proof that there would indeed be a speed improvement, and I very much doubt such a claim. Python uses obmalloc for most objects, so malloc performance is mostly irrelevant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1216562&group_id=5470 From noreply at sourceforge.net Wed Jun 15 23:15:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 14:15:44 -0700 Subject: [ python-Bugs-1221477 ] Incorrect documentation for InPlace Number operators Message-ID: Bugs item #1221477, was opened at 2005-06-15 14:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation for InPlace Number operators Initial Comment: The documentation for the various InPlace abstract number operators (PyNumber_InPlaceSubtract, etc.) specify that the functions return a new reference. Unless I'm mistaken, this is incorrect. The functions do not increment increment the reference counter. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-15 16:15 Message: Logged In: YES user_id=80475 Actually, they do. Arithmetic operations create new number objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 From noreply at sourceforge.net Wed Jun 15 23:29:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Jun 2005 14:29:43 -0700 Subject: [ python-Bugs-1221477 ] Incorrect documentation for InPlace Number operators Message-ID: Bugs item #1221477, was opened at 2005-06-15 12:46 Message generated for change (Comment added) made by agthorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation for InPlace Number operators Initial Comment: The documentation for the various InPlace abstract number operators (PyNumber_InPlaceSubtract, etc.) specify that the functions return a new reference. Unless I'm mistaken, this is incorrect. The functions do not increment increment the reference counter. ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2005-06-15 14:29 Message: Logged In: YES user_id=6324 How are the InPlace versions different from the regular versions, then? I do remember something about number objects in Python being immutable, so what you say makes sense. I'm just not sure if I need to be decrementing any reference counters when I'm trying to do the equivalent of "a += b". Perhaps adding some text to the top of that section describing what "in-place" means in this context? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-15 14:15 Message: Logged In: YES user_id=80475 Actually, they do. Arithmetic operations create new number objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221477&group_id=5470 From noreply at sourceforge.net Thu Jun 16 11:58:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 02:58:02 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-16 10:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 09:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu Jun 16 12:09:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 03:09:15 -0700 Subject: [ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform? Message-ID: Bugs item #1212703, was opened at 2005-06-01 15:05 Message generated for change (Comment added) made by ranma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vincent Jamart (ranma) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 CVS broken for HP-UX platform? Initial Comment: While trying to compile Python 2.5 from the nighlty CVS image, it raises the following errors on HP-UX. (OS version= HP-UX 11.22 on ia64, compiler= aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]) Compilation flags: export CC=aCC export CFLAGS="-Ae +DD64" export LDFLAGS="+DD64" make clean ./configure --prefix=/usr/local/python_cvs --with-cxx=aCC (...) creating Makefile aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. ---------------------------------------------------------------------- >Comment By: Vincent Jamart (ranma) Date: 2005-06-16 12:09 Message: Logged In: YES user_id=150220 We nailed down the problem. Apparantly the option "+DD64" is not used by 'make'. Nevertheless we added this to CPPFLAGS and CFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 From noreply at sourceforge.net Thu Jun 16 13:32:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 04:32:29 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-06-16 13:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 11:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 10:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu Jun 16 14:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 05:09:18 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 12:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 10:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 09:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu Jun 16 14:39:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 05:39:14 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 12:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 10:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 09:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:00:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:00:52 -0700 Subject: [ python-Bugs-1222098 ] float() not accurate Message-ID: Bugs item #1222098, was opened at 2005-06-16 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222098&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brian Dols (dols) Assigned to: Nobody/Anonymous (nobody) Summary: float() not accurate Initial Comment: float("4.1") returns 4.0999999999996 shouldn't it return 4.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222098&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:21:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:21:45 -0700 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 14:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Please note that this 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 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Just van Rossum (jvr) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 14:21 Message: Logged In: YES user_id=11375 Just, it looks like you're responsible for modulefinder, so I'm reassigning this to you. It would be helpful if you could take a look at the docs and see if anything is documented that should be private. Please unassign (or close?) this bug if you're not connected to modulefinder. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 16:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:27:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:27:12 -0700 Subject: [ python-Bugs-1222098 ] float() not accurate Message-ID: Bugs item #1222098, was opened at 2005-06-16 18:00 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222098&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Brian Dols (dols) Assigned to: Nobody/Anonymous (nobody) Summary: float() not accurate Initial Comment: float("4.1") returns 4.0999999999996 shouldn't it return 4.1? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 18:27 Message: Logged In: YES user_id=35752 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://www.python.org/doc/2.2.1/tut/node14.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222098&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:49:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:49:17 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 18:17 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 18:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Thu Jun 16 20:51:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 11:51:25 -0700 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 20:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Please note that this 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 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Just van Rossum (jvr) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-06-16 20:51 Message: Logged In: YES user_id=11105 If Just doesn't appear ;-) please assign to me. I should at least describe the api that is actually *used* in py2exe. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 20:21 Message: Logged In: YES user_id=11375 Just, it looks like you're responsible for modulefinder, so I'm reassigning this to you. It would be helpful if you could take a look at the docs and see if anything is documented that should be private. Please unassign (or close?) this bug if you're not connected to modulefinder. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 22:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Fri Jun 17 00:18:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Jun 2005 15:18:11 -0700 Subject: [ python-Bugs-1222235 ] Bad optparse help wrapping with multiple paragraphs Message-ID: Bugs item #1222235, was opened at 2005-06-16 18:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222235&group_id=5470 From noreply at sourceforge.net Fri Jun 17 10:50:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 01:50:14 -0700 Subject: [ python-Bugs-1222459 ] Typo in section 5.3 of tutorial Message-ID: Bugs item #1222459, was opened at 2005-06-17 01:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 From noreply at sourceforge.net Fri Jun 17 10:50:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 01:50:29 -0700 Subject: [ python-Bugs-1222459 ] Typo in section 5.3 of tutorial Message-ID: Bugs item #1222459, was opened at 2005-06-17 01:50 Message generated for change (Settings changed) made by btvincent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 Please note that this 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: 1 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 From noreply at sourceforge.net Fri Jun 17 12:28:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 03:28:29 -0700 Subject: [ python-Bugs-1222459 ] Typo in section 5.3 of tutorial Message-ID: Bugs item #1222459, was opened at 2005-06-17 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 Please note that this 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: 1 Submitted By: uman (btvincent) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in section 5.3 of tutorial Initial Comment: In section 5.3 of the tutorial: As you see, on output tuples are alway enclosed in parentheses, should read: As you see, on output tuples are always enclosed in parentheses, there is an "s" missing from "always". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-17 05:28 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222459&group_id=5470 From noreply at sourceforge.net Fri Jun 17 12:29:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 03:29:30 -0700 Subject: [ python-Bugs-1222235 ] Bad optparse help wrapping with multiple paragraphs Message-ID: Bugs item #1222235, was opened at 2005-06-16 17:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222235&group_id=5470 From noreply at sourceforge.net Fri Jun 17 12:35:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 03:35:26 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-06-17 12:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 13:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 11:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 10:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Fri Jun 17 14:10:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 05:10:23 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) >Assigned to: Tim Peters (tim_one) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-17 13:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 11:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 12:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 10:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 09:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Fri Jun 17 16:37:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 07:37:39 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Tim Peters (tim_one) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: anothermax (yetanothermax) Date: 2005-06-17 16:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-17 14:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 12:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 14:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 13:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 11:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 10:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 22:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 21:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 08:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Fri Jun 17 17:23:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 08:23:54 -0700 Subject: [ python-Bugs-1222721 ] tk + setlocale problems... Message-ID: Bugs item #1222721, was opened at 2005-06-17 19:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222721&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex A. Naanou (alex_nanou) Assigned to: Martin v. L?wis (loewis) Summary: tk + setlocale problems... Initial Comment: Description: when using both the tkinter GUI and the locale.setlocale (locale.LC_ALL, '') call on Py2.4, the following error is printed to stderr: 
error reading package index 
file /usr/share/tcl/vfs1.3/pkgIndex.tcl:
syntax error in expression "[package provide Tcl] < 8.4": 
extra tokens at
end of expression
in addition to this, the BackSpace key appears not to be handled by the tk input widgets (for example "Entry") after the setlocale call. in Py2.4.1 the error is no longer printed, though the problem with the BS key persists. Testcase: see attached file. --- Originally posted to ALTLinux bugtracker (original text (Russian): https://bugzilla.altlinux.org/show_bug.cgi? id=6339) --- additionally tested on: Py2.4.1 (builds for win32, cygwin, debian linux) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222721&group_id=5470 From noreply at sourceforge.net Fri Jun 17 19:18:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 10:18:52 -0700 Subject: [ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC Message-ID: Bugs item #1222790, was opened at 2005-06-17 19:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Winfried Harbecke (wharbecke) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 From noreply at sourceforge.net Fri Jun 17 19:31:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 10:31:42 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 11:17 Message generated for change (Comment added) made by rjs_org You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 10:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 11:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Fri Jun 17 19:52:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 10:52:23 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 18:17 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-17 17:52 Message: Logged In: YES user_id=35752 The repr of a buffer() object has indeed changed. I don't see how that's a bug though. ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 17:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 18:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Fri Jun 17 21:04:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 12:04:18 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 11:17 Message generated for change (Comment added) made by rjs_org You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 12:04 Message: Logged In: YES user_id=287034 In 2.3, the actual adress of the first element of an array could be parsed for doing a memmove(), and now, not, which breaks some older code. If this is a "more Pythonic" feature, then OK; the previous resolution said "Fixed in bufferobject.c 2.25." without remark. I assumed that it had been restored to the previous. I now have: ptr = tpcnv[a.typecode()]() pythonapi.PyObject_AsReadBuffer(py_object(a), byref(ptr), byref(c_int())) ptr.refed_array = a instead of: split(repr(buffer(a)))[5][:-1] to get/use an address with ctypes... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-17 10:52 Message: Logged In: YES user_id=35752 The repr of a buffer() object has indeed changed. I don't see how that's a bug though. ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 10:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 11:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Fri Jun 17 23:57:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 14:57:49 -0700 Subject: [ python-Bugs-1222928 ] it's -> its Message-ID: Bugs item #1222928, was opened at 2005-06-17 14:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Ed Swierk (eswierk) Assigned to: Nobody/Anonymous (nobody) Summary: it's -> its Initial Comment: These are not earth-shattering bugs, but for the sake of my obsessiveness... "it's" should be changed to "its" in each of these instances: ref/id-classes.html: and it's implementation (including the standard library); mac/module-FrameWork.html:that shouldn't be difficult), that it's dialog support is minimal and mac/module-FrameWork.html:that it's control/toolbar support is non-existent. api/common-structs.html: that it's own expansion varies depending on the definition of api/instanceObjects.html: Create a new instance of a specific class without calling it's doc/inline-markup.html: be used for simple constant definitions. Examples of it's use doc/info-units.html: be used for simple constant definitions. Examples of it's use lib/module-cgitb.html:scripts. (It's name is a bit misleading. It was originally designed to ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470 From noreply at sourceforge.net Sat Jun 18 01:57:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 16:57:51 -0700 Subject: [ python-Bugs-1222978 ] 2.4.1 .msi file won't install to different disk Message-ID: Bugs item #1222978, was opened at 2005-06-17 16:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Trent (hacksoncode) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 .msi file won't install to different disk Initial Comment: I just downloaded and tried to install 2.4.1 for Windows. I downloaded the .msi file to f:\rat\stuff. When I tried to install it (selecting the default install dir of c:\Python24), MSI error messages appeared claiming that it couldn't read from the MSI file. Moving the .msi file to c:\swtools and installing from there worked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 From noreply at sourceforge.net Sat Jun 18 02:06:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Jun 2005 17:06:28 -0700 Subject: [ python-Bugs-1222978 ] 2.4.1 .msi file won't install to different disk Message-ID: Bugs item #1222978, was opened at 2005-06-17 16:57 Message generated for change (Comment added) made by hacksoncode You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Ray Trent (hacksoncode) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 .msi file won't install to different disk Initial Comment: I just downloaded and tried to install 2.4.1 for Windows. I downloaded the .msi file to f:\rat\stuff. When I tried to install it (selecting the default install dir of c:\Python24), MSI error messages appeared claiming that it couldn't read from the MSI file. Moving the .msi file to c:\swtools and installing from there worked. ---------------------------------------------------------------------- >Comment By: Ray Trent (hacksoncode) Date: 2005-06-17 17:06 Message: Logged In: YES user_id=691303 Hmmm. This seems to be a problem with my MSI. Or at least the MySQL .msi file has the same issue. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222978&group_id=5470 From noreply at sourceforge.net Sat Jun 18 18:37:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 09:37:08 -0700 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 From noreply at sourceforge.net Sat Jun 18 19:26:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 10:26:18 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 18:17 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:26 Message: Logged In: YES user_id=35752 Calling PyObject_AsReadBuffer() is the proper way to get the address. It should work with older versions of Python as well. The buffer() object was changed in 2.4 to no longer keep a pointer to buffer memory, only the underlying PyObject. It would be possible to make the repr look the same as pre-2.4 Python. Do you still care? ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 19:04 Message: Logged In: YES user_id=287034 In 2.3, the actual adress of the first element of an array could be parsed for doing a memmove(), and now, not, which breaks some older code. If this is a "more Pythonic" feature, then OK; the previous resolution said "Fixed in bufferobject.c 2.25." without remark. I assumed that it had been restored to the previous. I now have: ptr = tpcnv[a.typecode()]() pythonapi.PyObject_AsReadBuffer(py_object(a), byref(ptr), byref(c_int())) ptr.refed_array = a instead of: split(repr(buffer(a)))[5][:-1] to get/use an address with ctypes... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-17 17:52 Message: Logged In: YES user_id=35752 The repr of a buffer() object has indeed changed. I don't see how that's a bug though. ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 17:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 18:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Sat Jun 18 19:41:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 10:41:03 -0700 Subject: [ python-Bugs-1220756 ] Re-importing embedded thread dumps core Message-ID: Bugs item #1220756, was opened at 2005-06-14 21:16 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Neil Schemenauer (nascheme) Summary: Re-importing embedded thread dumps core Initial Comment: I noticed the following while working on an "embedding numarray" problem: [jmiller at halloween Python-2.4.1]$ Python-2.4.1/Demo/embed/loop 'from thread import *' 10 [6675 refs] [7009 refs] [7320 refs] [7631 refs] [7942 refs] [8253 refs] loop: Objects/typeobject.c:2104: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed. Abort (core dumped) The tp_flags bit in question is: #define Py_TPFLAGS_HEAPTYPE (1L<<9) ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:41 Message: Logged In: YES user_id=35752 I add an incref in gcmodule.c 2.81. "./loop 'import gc'" no longer crashes but it does leak memory. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-15 12:28 Message: Logged In: YES user_id=6656 Fixed the issue in the report in revision 2.62 of Modules/threadmodule.c. I'm leaving this open because "./loop 'import gc'" crashes and because I think there are too many places that incref before PyModule_AddObject()... Neil, any ideas about the gc one? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-15 11:35 Message: Logged In: YES user_id=6656 Oh dear. The problem here is that PyModule_AddObject steals a reference to the object, but this is not taken care of in threadmodule.c (or gcmodule, it turns out, and I bet many other places). Shouldn't be too hard to fix. (Looks like noone's run Demo/embed/loop for a while...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470 From noreply at sourceforge.net Sat Jun 18 19:43:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 10:43:17 -0700 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 16:37 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 From noreply at sourceforge.net Sat Jun 18 19:55:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 10:55:01 -0700 Subject: [ python-Bugs-1222928 ] it's -> its Message-ID: Bugs item #1222928, was opened at 2005-06-17 21:57 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ed Swierk (eswierk) >Assigned to: Neil Schemenauer (nascheme) Summary: it's -> its Initial Comment: These are not earth-shattering bugs, but for the sake of my obsessiveness... "it's" should be changed to "its" in each of these instances: ref/id-classes.html: and it's implementation (including the standard library); mac/module-FrameWork.html:that shouldn't be difficult), that it's dialog support is minimal and mac/module-FrameWork.html:that it's control/toolbar support is non-existent. api/common-structs.html: that it's own expansion varies depending on the definition of api/instanceObjects.html: Create a new instance of a specific class without calling it's doc/inline-markup.html: be used for simple constant definitions. Examples of it's use doc/info-units.html: be used for simple constant definitions. Examples of it's use lib/module-cgitb.html:scripts. (It's name is a bit misleading. It was originally designed to ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470 From noreply at sourceforge.net Sat Jun 18 20:05:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 11:05:24 -0700 Subject: [ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Message-ID: Bugs item #1195576, was opened at 2005-05-04 23:13 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Brett Cannon (bcannon) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 18:05 Message: Logged In: YES user_id=35752 I haven't dug to deep into this but test_warnings now passes. The ast.c ast_error_finish function doesn't seem to have been changed. I think test_warnings was failing for some other reason. It looks like SyntaxWarnings are not currently generated by newcompile.c. I'm leaving this issue open until that gets fixed. Probably a test should be added that actually causes a SyntaxWarning to be generated by the compiler. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-05-06 20:01 Message: Logged In: YES user_id=357491 I shouldn't need a patch, but it might be a little while until I get to this. I am down to the last couple of weeks of the quarter and I am racing to get my masters thesis done before I graduate. Plus a quick recompile the other night under gcc 4 led to a ton of errors for me (hoping it was just a fluke; something about sem_init() ). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 From noreply at sourceforge.net Sat Jun 18 22:12:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 13:12:21 -0700 Subject: [ python-Bugs-1209560 ] spurious blank page in dist.pdf Message-ID: Bugs item #1209560, was opened at 2005-05-27 02:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: paul rubin (phr) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: spurious blank page in dist.pdf Initial Comment: In the US Letter sized version of dist.pdf in the current download zip (Python 2.4.1), the third page of the file (the one immediately preceding the table of contents, which starts with roman numeral "i") is blank. That means that page "i" of the table of contents, and page "1" of the actual document, begin on even-numbered pages in the file. This is bad because if you print on a duplex printer, page 1 comes out on the back of page ii, page 3 comes out on the back of page 2, etc. You want odd numbered pages to be on the front and even numbered pages to be on the back, so page 2 should be on the back of page 1, etc. This is probably a problem with the latex extension that made the pdf file and so it probably affects the other pdfs as well as dist.pdf, but that's the only one I printed. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 22:12 Message: Logged In: YES user_id=1188172 Thanks for the report! Checked in as Doc/dist/dist.tex rev 1.95, 1.86.2.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 13:12 Message: Logged In: YES user_id=1188172 This indeed happens only in dist.pdf. Attaching a patch which includes the copyright, as in all other documents, and magically, the paging is right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470 From noreply at sourceforge.net Sat Jun 18 22:34:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 13:34:52 -0700 Subject: [ python-Bugs-1219273 ] 'Expression' AST Node not documented Message-ID: Bugs item #1219273, was opened at 2005-06-12 20:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: 'Expression' AST Node not documented Initial Comment: Python 2.4.1 documentation === The table at the end of section "19.3.1 AST Nodes" does not list Node type 'Expression' and its associated information. Also, the BNF for 'expression' shown in the file > expression ::= > or_test | lambda_form can't be correct because it doesn't cover cases of a simple literals (or identifiers) such as 42 and simple binary operator expressions such as 1+2. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 22:34 Message: Logged In: YES user_id=1188172 To your second comment: the BNF for expression is correct since or_test can contain and_test which can contain not_test and so on until primary, atom, literal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470 From noreply at sourceforge.net Sat Jun 18 23:05:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 14:05:42 -0700 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 02:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:05 Message: Logged In: YES user_id=1188172 Interestingly, altering the behaviour of splitext in such a way does not contradict the documentation, which is: """ Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. """ Personally I'm in favour of this change (on Unix it makes sense, while on Windows you can hardly find an "extension-only" file). ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-06-13 16:12 Message: Logged In: YES user_id=147070 from test_posixpath.py :: self.assertEqual(posixpath.splitext(".ext"), ("", ".ext")) IMHO should then return (".ext",""). if this is desired :: if i<=p.rfind('/'): return p, '' else: return p[:i], p[i:] should do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Sat Jun 18 23:26:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 14:26:38 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-13 03:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Sun Jun 19 00:05:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Jun 2005 15:05:56 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 14:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Martin v. L?wis (loewis) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-18 17:05 Message: Logged In: YES user_id=80475 Martin, please look at this when you get a chance. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 16:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-12 20:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 06:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 15:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 08:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Sun Jun 19 11:01:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Jun 2005 02:01:53 -0700 Subject: [ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform? Message-ID: Bugs item #1212703, was opened at 2005-06-01 23:05 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vincent Jamart (ranma) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 CVS broken for HP-UX platform? Initial Comment: While trying to compile Python 2.5 from the nighlty CVS image, it raises the following errors on HP-UX. (OS version= HP-UX 11.22 on ia64, compiler= aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]) Compilation flags: export CC=aCC export CFLAGS="-Ae +DD64" export LDFLAGS="+DD64" make clean ./configure --prefix=/usr/local/python_cvs --with-cxx=aCC (...) creating Makefile aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. aCC -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Modules/ccpython.o ./Modules/ccpython.cc "/usr/include/sys/unistd.h", line 594: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline truncate(const char *a, off_t b) { return __truncate64(a,b); } ^ "/usr/include/sys/unistd.h", line 595: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline prealloc(int a, off_t b) { return __prealloc64(a,b); } ^ "/usr/include/sys/unistd.h", line 596: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lockf(int a, int b, off_t c) { return __lockf64(a,b,c); } ^ "/usr/include/sys/unistd.h", line 597: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline ftruncate(int a, off_t b) { return __ftruncate64(a,b); } ^ "/usr/include/sys/stat.h", line 173: warning #2837-D: omission of explicit type is nonstandard ("int" assumed) inline lstat __((const char *, struct stat *)); ^ "./Include/pyport.h", line 612: error #2035: #error directive: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." ^ 1 error detected in the compilation of "./Modules/ccpython.cc". *** Error exit code 2 Stop. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-19 19:01 Message: Logged In: YES user_id=29957 It's not clear from your message - did you find a fix for this? It seems like this should be closed as notabug... ---------------------------------------------------------------------- Comment By: Vincent Jamart (ranma) Date: 2005-06-16 20:09 Message: Logged In: YES user_id=150220 We nailed down the problem. Apparantly the option "+DD64" is not used by 'make'. Nevertheless we added this to CPPFLAGS and CFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470 From noreply at sourceforge.net Mon Jun 20 08:56:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Jun 2005 23:56:52 -0700 Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno Message-ID: Bugs item #1223937, was opened at 2005-06-20 06:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 From noreply at sourceforge.net Mon Jun 20 10:40:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 01:40:04 -0700 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 08:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Mon Jun 20 12:52:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 03:52:50 -0700 Subject: [ python-Bugs-1224047 ] Len too large with national characters Message-ID: Bugs item #1224047, was opened at 2005-06-20 12: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=1224047&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ? in a string. len will return a value of 2. i.e. a='?' print len(a) gives: 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 From noreply at sourceforge.net Mon Jun 20 14:12:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 05:12:01 -0700 Subject: [ python-Bugs-1224047 ] Len too large with national characters Message-ID: Bugs item #1224047, was opened at 2005-06-20 11:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ? in a string. len will return a value of 2. i.e. a='?' print len(a) gives: 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 From noreply at sourceforge.net Mon Jun 20 15:06:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 06:06:22 -0700 Subject: [ python-Bugs-1224047 ] Len too large with national characters Message-ID: Bugs item #1224047, was opened at 2005-06-20 12:52 Message generated for change (Comment added) made by henrikwj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Henrik Winther Jensen (henrikwj) Assigned to: Nobody/Anonymous (nobody) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ? in a string. len will return a value of 2. i.e. a='?' print len(a) gives: 2 ---------------------------------------------------------------------- >Comment By: Henrik Winther Jensen (henrikwj) Date: 2005-06-20 15:06 Message: Logged In: YES user_id=1299770 Actually the problem persists whether i am reading from a file or inputting from a keyboard. I am using python from the command line in linux shell. I dont know what console that is. But it is able to show the danish characters on the screen as well as reading them from the keyboard. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-20 14:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 From noreply at sourceforge.net Mon Jun 20 15:12:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 06:12:01 -0700 Subject: [ python-Bugs-1224047 ] Len too large with national characters Message-ID: Bugs item #1224047, was opened at 2005-06-20 11:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Henrik Winther Jensen (henrikwj) >Assigned to: Michael Hudson (mwh) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ? in a string. len will return a value of 2. i.e. a='?' print len(a) gives: 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-20 14:12 Message: Logged In: YES user_id=6656 Well, what encoding is the file in? I suspect that it's in utf-8, so when you open the file and call read() you get utf-8 data and thus your danish character is represented as two bytes. You might want to do import codecs fileobj = codecs.open('filename.txt', encoding='utf-8') and then fileobj.read() will return a unicode string of the length you're expecting. At any rate, I see no evidence of a Python bug here, so closing. ---------------------------------------------------------------------- Comment By: Henrik Winther Jensen (henrikwj) Date: 2005-06-20 14:06 Message: Logged In: YES user_id=1299770 Actually the problem persists whether i am reading from a file or inputting from a keyboard. I am using python from the command line in linux shell. I dont know what console that is. But it is able to show the danish characters on the screen as well as reading them from the keyboard. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 From noreply at sourceforge.net Mon Jun 20 15:12:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 06:12:49 -0700 Subject: [ python-Bugs-1106262 ] semaphore errors from Python 2.3.x on AIX 5.2 Message-ID: Bugs item #1106262, was opened at 2005-01-20 20:55 Message generated for change (Comment added) made by lim_1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: semaphore errors from Python 2.3.x on AIX 5.2 Initial Comment: Newer versions of the AIX 5.2 libc implement POSIX semaphores and thus define _POSIX_SEMAPHORES in . However, when building Python 2.3.x (and I'm sure any other version with sem_init()), a few semaphore errors are encountered: building 'pcre' extension ./Modules/ld_so_aix gcc -bI:Modules/python.exp -L/opt/TWWfsw/python232/lib/support -Wl,-brtl -Wl,-blibpath:/opt/TWWfsw/python232/lib/support:/usr/lib build/temp.aix-5.2-2.3/pcremodule.o build/temp.aix-5.2-2.3/pypcre.o -L/opt/TWWfsw/python232/lib -o build/lib.aix-5.2-2.3/pcre.so sem_trywait: Permission denied sem_wait: Permission denied sem_post: Permission denied I ran the Python process under truss and saw that the sem_init() from Python/thread_pthread.h worked successfully. fork() was then called and a sem_trywait() operation (probably from PyThread_acquire_lock()) was called. From the sem_init() man page (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/libs/basetrf2/sem_init.htm): If the pshared parameter has a nonzero value, the semaphore is shared between processes. In this case, any process that can access the sem parameter can use it for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. Only the sem parameter itself may be used for performing synchronization. If the pshared parameter is zero, the semaphore is shared between threads of the process. Any thread in this process can use the sem parameter for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. The use of the semaphore by threads other than those created in the same process returns an error. Setting the 2nd value of sem_init to 1 (was 0) solved the problem. However, I don't know if this is wise for security. Another solution is to set HAVE_BROKEN_POSIX_SEMAPHORES for "AIX/5" like for "SunOS/5.8". ---------------------------------------------------------------------- Comment By: Leanid (lim_1) Date: 2005-06-20 13:12 Message: Logged In: YES user_id=701470 I can confirm this problem. I am using scons to build my project on AIX. I could not run parallel builds (-j4) on AIX. Randomly, but very often xlC invocation would stuck and I have 4 xlCcode hanging and taking all CPUs. After adding HAVE_BROKEN_POSIX_SEMAPHORES for AIX and rebuilding Python parallel builds on AIX are fine. Trying first fix with changing 0 to 1 in sem_init also resolved this problem, but I started to get some other unexplained error from scons, so had to deactivate semaphores all together. Albert, thanks for this report, it helped a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 From noreply at sourceforge.net Mon Jun 20 15:41:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 06:41:37 -0700 Subject: [ python-Bugs-1224047 ] Len too large with national characters Message-ID: Bugs item #1224047, was opened at 2005-06-20 12:52 Message generated for change (Comment added) made by henrikwj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Henrik Winther Jensen (henrikwj) Assigned to: Michael Hudson (mwh) Summary: Len too large with national characters Initial Comment: It looks as if len returns the lenght of an UTF8 string even if the string only contains ascii characters and default encoding is ascii. This means that if you insert f. ex. one danish ? in a string. len will return a value of 2. i.e. a='?' print len(a) gives: 2 ---------------------------------------------------------------------- >Comment By: Henrik Winther Jensen (henrikwj) Date: 2005-06-20 15:41 Message: Logged In: YES user_id=1299770 Yes, you are right, the problem is that the console-thingy converts my iso8859 characters to utf-8. Thanks for the explanation. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-20 15:12 Message: Logged In: YES user_id=6656 Well, what encoding is the file in? I suspect that it's in utf-8, so when you open the file and call read() you get utf-8 data and thus your danish character is represented as two bytes. You might want to do import codecs fileobj = codecs.open('filename.txt', encoding='utf-8') and then fileobj.read() will return a unicode string of the length you're expecting. At any rate, I see no evidence of a Python bug here, so closing. ---------------------------------------------------------------------- Comment By: Henrik Winther Jensen (henrikwj) Date: 2005-06-20 15:06 Message: Logged In: YES user_id=1299770 Actually the problem persists whether i am reading from a file or inputting from a keyboard. I am using python from the command line in linux shell. I dont know what console that is. But it is able to show the danish characters on the screen as well as reading them from the keyboard. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-20 14:12 Message: Logged In: YES user_id=6656 How are you getting your danish character into the string? If it's by typing it into a console, is your console in utf-8 mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224047&group_id=5470 From noreply at sourceforge.net Mon Jun 20 17:12:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 08:12:44 -0700 Subject: [ python-Bugs-1153016 ] Setting socket timeout crashes SSL Message-ID: Bugs item #1153016, was opened at 2005-02-27 20:41 Message generated for change (Comment added) made by maltehelmert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pristine777 (pristine777) Assigned to: Nobody/Anonymous (nobody) Summary: Setting socket timeout crashes SSL Initial Comment: This bug was fixed in Python 2.3 but has resurfaced in Python 2.4 The original bug report can be found at: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=673797&group_id=5470 The method urlopen both in urllib and in urllib2 crashes if socket.setdefaulttimeout has been called. Below is a cut and paste when using the function in urllib. >>> import socket >>> socket.setdefaulttimeout(30.0) >>> import urllib >>> urllib.urlopen('https://members.tufts- health.com/memindex.html') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 180, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 374, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 794, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 675, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 642, in send self.connect() File "C:\Python24\lib\httplib.py", line 1069, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (2, 'The operation did not complete (read)') Thanks a ton! ---------------------------------------------------------------------- Comment By: Malte Helmert (maltehelmert) Date: 2005-06-20 17:12 Message: Logged In: YES user_id=1131890 Same problem here with Python 2.4 (#1, Jan 13 2005, 20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a minimal piece of code that fails (substitute a valid IMAP server accepting SSL connections): === start code snippet === import imaplib, socket socket.setdefaulttimeout(10.0) imaplib.IMAP4_SSL("imap.whatever.invalid") === end code snippet === This fails with the following traceback: === start traceback === Traceback (most recent call last): File "./imap_bug.py", line 3, in ? imaplib.IMAP4_SSL("imap.whatever.invalid") File "/usr/local/lib/python2.4/imaplib.py", line 1101, in __init__ IMAP4.__init__(self, host, port) File "/usr/local/lib/python2.4/imaplib.py", line 181, in __init__ self.welcome = self._get_response() File "/usr/local/lib/python2.4/imaplib.py", line 876, in _get_response resp = self._get_line() File "/usr/local/lib/python2.4/imaplib.py", line 969, in _get_line line = self.readline() File "/usr/local/lib/python2.4/imaplib.py", line 1135, in readline char = self.sslobj.read(1) socket.sslerror: The read operation timed out === end traceback === Remove the socket.setdefaulttimeout call and it works properly. The problem is not due to a slow network connection or overloaded server -- the script fails for all kinds of timeouts (1, 10, 100 seconds), but without a timeout the response is near-instantaneous. ---------------------------------------------------------------------- Comment By: Tarek Ziad? (tarek-ziade) Date: 2005-05-19 15:53 Message: Logged In: YES user_id=1163510 having same issue here, using imaplib thru ssl :/ >>> import socket >>> socket.setdefaulttimeout(10) >>> i = imaplib.IMAP4_SSL('mail.xxxx.com') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib/python2.4/imaplib.py", line 181, in __init__ self.welcome = self._get_response() File "/usr/lib/python2.4/imaplib.py", line 876, in _get_response resp = self._get_line() File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line line = self.readline() File "/usr/lib/python2.4/imaplib.py", line 1136, in readline char = self.sslobj.read(1) socket.sslerror: The read operation timed out so i can't get timeouts with ssl in imap :/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470 From noreply at sourceforge.net Mon Jun 20 18:54:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 09:54:38 -0700 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: anothermax (yetanothermax) >Assigned to: Michael Hudson (mwh) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-20 17:54 Message: Logged In: YES user_id=6656 Fixed, in Misc/NEWS revision 1.1301 Modules/threadmodule.c revision 2.64 Python/pystate.c revision 2.42 (I made a tiny tweak in addition to the latest patch attached to this report). yetanothermax: Thanks for the report, and the testing of patches! ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 15:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-17 13:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 11:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 13:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 12:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 10:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 09:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 21:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 20:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 07:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Mon Jun 20 20:11:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 11:11:54 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 11:17 Message generated for change (Comment added) made by rjs_org You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- >Comment By: Ray Schumacher (rjs_org) Date: 2005-06-20 11:11 Message: Logged In: YES user_id=287034 No, since we have now used the PyObject_AsReadBuffer(). We use ctypes to transfer data returned from an C-API A/D driver directly to Numeric arrays via address. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 10:26 Message: Logged In: YES user_id=35752 Calling PyObject_AsReadBuffer() is the proper way to get the address. It should work with older versions of Python as well. The buffer() object was changed in 2.4 to no longer keep a pointer to buffer memory, only the underlying PyObject. It would be possible to make the repr look the same as pre-2.4 Python. Do you still care? ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 12:04 Message: Logged In: YES user_id=287034 In 2.3, the actual adress of the first element of an array could be parsed for doing a memmove(), and now, not, which breaks some older code. If this is a "more Pythonic" feature, then OK; the previous resolution said "Fixed in bufferobject.c 2.25." without remark. I assumed that it had been restored to the previous. I now have: ptr = tpcnv[a.typecode()]() pythonapi.PyObject_AsReadBuffer(py_object(a), byref(ptr), byref(c_int())) ptr.refed_array = a instead of: split(repr(buffer(a)))[5][:-1] to get/use an address with ctypes... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-17 10:52 Message: Logged In: YES user_id=35752 The repr of a buffer() object has indeed changed. I don't see how that's a bug though. ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 10:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 11:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Mon Jun 20 21:22:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 12:22:41 -0700 Subject: [ python-Bugs-1224347 ] int/long unification and hex() Message-ID: Bugs item #1224347, was opened at 2005-06-20 12: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=1224347&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: int/long unification and hex() Initial Comment: There seems to be a bit of an inconsistancy with int/long unification while using hex(). Specifically; >>> hex(int(987259835)) '0x3ad863bb' >>> hex(long(987259835)) '0x3AD863BBL' I understand that longs will have the trailing 'L' until Py3k, but I believe the capitalization should be consistant. If consistancy is desired, I believe that lowercase should be the standard, being that string.encode('hex') also produces lowercase. If the cases are supposed to be different, or making the change would produce known backwards incompatibility for some set of modules, feel free to close this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470 From noreply at sourceforge.net Tue Jun 21 01:44:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 16:44:45 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Martin v. L?wis (loewis) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-06-21 01:44 Message: Logged In: YES user_id=142612 The bug has been reproduced with a 90Mbytes bz2 file containing more than 4Gbytes of fairly similar documents. I've diagnosed the same problem with large offsets. Thanks for the patch. Platform: WinXP Intel P4, Python 2.4.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-19 00:05 Message: Logged In: YES user_id=80475 Martin, please look at this when you get a chance. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-13 03:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Tue Jun 21 05:32:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 20:32:51 -0700 Subject: [ python-Bugs-1221424 ] buffer() object broken. Message-ID: Bugs item #1221424, was opened at 2005-06-15 18:17 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ray Schumacher (rjs_org) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: Same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470: Still broken in 2.4.1...! C:\projects\temp\fftw>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> i = Numeric.zeros(8) >>> repr(buffer(i)) '' >>> repr(buffer("")) '' (Numeric v23.8) ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-20 18:11 Message: Logged In: YES user_id=287034 No, since we have now used the PyObject_AsReadBuffer(). We use ctypes to transfer data returned from an C-API A/D driver directly to Numeric arrays via address. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:26 Message: Logged In: YES user_id=35752 Calling PyObject_AsReadBuffer() is the proper way to get the address. It should work with older versions of Python as well. The buffer() object was changed in 2.4 to no longer keep a pointer to buffer memory, only the underlying PyObject. It would be possible to make the repr look the same as pre-2.4 Python. Do you still care? ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 19:04 Message: Logged In: YES user_id=287034 In 2.3, the actual adress of the first element of an array could be parsed for doing a memmove(), and now, not, which breaks some older code. If this is a "more Pythonic" feature, then OK; the previous resolution said "Fixed in bufferobject.c 2.25." without remark. I assumed that it had been restored to the previous. I now have: ptr = tpcnv[a.typecode()]() pythonapi.PyObject_AsReadBuffer(py_object(a), byref(ptr), byref(c_int())) ptr.refed_array = a instead of: split(repr(buffer(a)))[5][:-1] to get/use an address with ctypes... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-17 17:52 Message: Logged In: YES user_id=35752 The repr of a buffer() object has indeed changed. I don't see how that's a bug though. ---------------------------------------------------------------------- Comment By: Ray Schumacher (rjs_org) Date: 2005-06-17 17:31 Message: Logged In: YES user_id=287034 repr(buffer("")) used to return: now returns: >>> repr(buffer("")) '' same as: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-16 18:49 Message: Logged In: YES user_id=35752 Please explain exactly what you think is broken about the buffer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470 From noreply at sourceforge.net Tue Jun 21 08:10:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Jun 2005 23:10:01 -0700 Subject: [ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents Message-ID: Bugs item #1224621, was opened at 2005-06-21 06:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: ------ import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 From noreply at sourceforge.net Tue Jun 21 09:15:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 00:15:59 -0700 Subject: [ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents Message-ID: Bugs item #1224621, was opened at 2005-06-21 01:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) >Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: ------ import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 From noreply at sourceforge.net Tue Jun 21 09:47:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 00:47:52 -0700 Subject: [ python-Bugs-1224672 ] rsplit introduces spurious CR Message-ID: Bugs item #1224672, was opened at 2005-06-21 07:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 From noreply at sourceforge.net Tue Jun 21 09:54:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 00:54:20 -0700 Subject: [ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents Message-ID: Bugs item #1224621, was opened at 2005-06-21 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: ------ import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 02:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/tokenize.py 1.38 and 1.36.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 From noreply at sourceforge.net Tue Jun 21 09:58:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 00:58:52 -0700 Subject: [ python-Bugs-1224672 ] rsplit introduces spurious CR Message-ID: Bugs item #1224672, was opened at 2005-06-21 02:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 02:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 From noreply at sourceforge.net Tue Jun 21 10:27:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 01:27:26 -0700 Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno Message-ID: Bugs item #1223937, was opened at 2005-06-20 01:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) >Assigned to: Peter ?strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 From noreply at sourceforge.net Tue Jun 21 12:24:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 03:24:26 -0700 Subject: [ python-Bugs-1047540 ] Turtle.py hangs Idle Message-ID: Bugs item #1047540, was opened at 2004-10-15 13:51 Message generated for change (Comment added) made by tso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1047540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taro Ogawa (tso) Assigned to: Nobody/Anonymous (nobody) Summary: Turtle.py hangs Idle Initial Comment: 1 line fix: After line 336's: root.destroy() insert root.quit() [Since IDLE is Tkinter based, the implict quit can't happen immediately. Worse, the shell has difficulty resetting and using a ^C can leave a zombie process] -T. ---------------------------------------------------------------------- >Comment By: Taro Ogawa (tso) Date: 2005-06-21 20:24 Message: Logged In: YES user_id=121025 I've tracked down some more info: It also happens on XP using 2.4.1 and Idle 1.1.1. The way to trigger it is to start IDLE with no subprocess. The way that I got that to happen is to right click on Turtle.py in Windows Explorer, and select "Edit with IDLE". While the fix that I suggested still cures it, it may be possible to achieve a better general solution by leaving turtle.py alone, and fixing IDLE... -T. ---------------------------------------------------------------------- Comment By: Taro Ogawa (tso) Date: 2004-10-25 10:46 Message: Logged In: YES user_id=121025 Sorry - should have included this: NT4, Python 2.3.3 [This isn't an isolated case - I've had problems with other programs behaving similarly on my XP box (using 2.3.4), eg the pygame demos]. Windows only thing...? -T. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-24 10:35 Message: Logged In: YES user_id=80475 What version of Python are you using? I cannot reproduce this on Py2.3 or on Py2.4b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1047540&group_id=5470 From noreply at sourceforge.net Tue Jun 21 17:52:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 08:52:22 -0700 Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno Message-ID: Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Peter ?strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 From noreply at sourceforge.net Tue Jun 21 18:08:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 09:08:29 -0700 Subject: [ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE Message-ID: Bugs item #1220113, was opened at 2005-06-14 07:04 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter ?strand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-21 18:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behav?our. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 From noreply at sourceforge.net Tue Jun 21 20:56:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 11:56:22 -0700 Subject: [ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail Message-ID: Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Nobody/Anonymous (nobody) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : ------------ Test 1 --------------- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. ------------ Test 2 --------------- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. ------------ Test 3 --------------- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 From noreply at sourceforge.net Tue Jun 21 22:13:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 13:13:25 -0700 Subject: [ python-Bugs-1223937 ] subprocess.py abuse of errno Message-ID: Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Peter ?strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-21 22:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 From noreply at sourceforge.net Tue Jun 21 22:20:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 13:20:02 -0700 Subject: [ python-Bugs-1225107 ] inspect.isclass() fails with custom __getattr__ Message-ID: Bugs item #1225107, was opened at 2005-06-21 14:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225107&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Kloth (jkloth) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.isclass() fails with custom __getattr__ Initial Comment: inspect.isclass() can return True for instances of classes which define a __getattr__ method. For example: >>> class Namespace(unicode): ... def __getattr__(self, attr): ... return '<%s>' % (self + attr) ... >>> inspect.isclass(Namespace('foo')) True Changing inspect.isclass() to: return isinstance(object, (types.ClassType, type)) solves this issue. The check for __bases__ is no longer need due to type/class unification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225107&group_id=5470 From noreply at sourceforge.net Wed Jun 22 08:12:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Jun 2005 23:12:11 -0700 Subject: [ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE Message-ID: Bugs item #1220113, was opened at 2005-06-14 15:04 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter ?strand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2005-06-22 16:12 Message: Logged In: YES user_id=46639 I can't think of any uses cases for wanting to create an inaccessible pipe and give it to the child. Wanting to pass a closed file handle is common. It is needed when calling a program that behaves differently if its stdin is a terminal or not. Or when you simply would prefer the subprocess to die if it attempts to read from its stdin rather than block. Using Popen instead of call is s simpler workaround than creating and closing a file descriptor and passing it in. Perhaps what is needed is a new constant, subprocess.CLOSED which creates a new file descriptor and closes it? This would be useful for Popen too, allowing call() to remain a think and trivially documented wrapper? ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-22 02:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behav?our. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 From noreply at sourceforge.net Wed Jun 22 10:45:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 01:45:21 -0700 Subject: [ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE Message-ID: Bugs item #1220113, was opened at 2005-06-14 07:04 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter ?strand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-22 10:45 Message: Logged In: YES user_id=344921 >Wanting to pass a closed file handle is common. This is not my experience. >It is needed when calling a program that behaves differently if its stdin >is a terminal or not. Such programs are quite uncommon, and usually, it's a bad idea to make such checks anyway. >Or when you simply would prefer the subprocess to die if it attempts to >read from its stdin rather than block For this case, I would say that it's more common to pass /dev/null than a closed file descriptor. It's uncommon with shell scripts that does "someprogram <&4711". It's much more common with "someprogram Using Popen instead of call is s simpler workaround than >creating and closing a file descriptor and passing it in. How would you use Popen in this case? >Perhaps what is needed is a new constant, subprocess.CLOSED >which creates a new file descriptor and closes it? This >would be useful for Popen too, allowing call() to remain a >think and trivially documented wrapper? It's not very hard to get an unused FD: closed_fd = os.open("/dev/null", os.O_RDONLY); os.close(closed_fd) I'm a bit reluctant to add a new constant when you can solve the problem anyway with one line of code. Also, we'll need to think about the platform portability a bit. Currently, I think that if we should add anything at all, it should be a constant like subprocess.NULL, which would be basically like open("/dev/null"), but also portable to Windows. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2005-06-22 08:12 Message: Logged In: YES user_id=46639 I can't think of any uses cases for wanting to create an inaccessible pipe and give it to the child. Wanting to pass a closed file handle is common. It is needed when calling a program that behaves differently if its stdin is a terminal or not. Or when you simply would prefer the subprocess to die if it attempts to read from its stdin rather than block. Using Popen instead of call is s simpler workaround than creating and closing a file descriptor and passing it in. Perhaps what is needed is a new constant, subprocess.CLOSED which creates a new file descriptor and closes it? This would be useful for Popen too, allowing call() to remain a think and trivially documented wrapper? ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-21 18:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behav?our. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 From noreply at sourceforge.net Wed Jun 22 12:56:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 03:56:19 -0700 Subject: [ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail Message-ID: Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) >Assigned to: Walter D?rwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : ------------ Test 1 --------------- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. ------------ Test 2 --------------- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. ------------ Test 3 --------------- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 From noreply at sourceforge.net Wed Jun 22 14:14:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 05:14:46 -0700 Subject: [ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail Message-ID: Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by nlehuen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter D?rwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : ------------ Test 1 --------------- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. ------------ Test 2 --------------- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. ------------ Test 3 --------------- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... ---------------------------------------------------------------------- >Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 From noreply at sourceforge.net Wed Jun 22 14:22:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 05:22:52 -0700 Subject: [ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail Message-ID: Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by nlehuen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter D?rwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : ------------ Test 1 --------------- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. ------------ Test 2 --------------- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. ------------ Test 3 --------------- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... ---------------------------------------------------------------------- >Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=61056 Turns out testing the CVS version was not so lengthy... So yes, this is fixed in the current CVS version ! Regards, Nicolas ---------------------------------------------------------------------- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 From noreply at sourceforge.net Wed Jun 22 14:22:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 05:22:57 -0700 Subject: [ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail Message-ID: Bugs item #1225059, was opened at 2005-06-21 20:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Walter D?rwald (doerwalter) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : ------------ Test 1 --------------- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. ------------ Test 2 --------------- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. ------------ Test 3 --------------- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=89016 Closing the report. Thanks for the quick followup. ---------------------------------------------------------------------- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:22 Message: Logged In: YES user_id=61056 Turns out testing the CVS version was not so lengthy... So yes, this is fixed in the current CVS version ! Regards, Nicolas ---------------------------------------------------------------------- Comment By: Nicolas Lehuen (nlehuen) Date: 2005-06-22 14:14 Message: Logged In: YES user_id=61056 I have not enough time to test the CVS version right now, but if I change the encoding header from : # -*- coding: CP1252 -*- to : # -*- coding: iso-8859-1 -*- then everything is OK. So I guess this is really a duplicate of others bugs related to the CP1252 encoder ? Thanks for your reply ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-06-22 12:56 Message: Logged In: YES user_id=89016 This is indead a duplicate of bug #1175396 and related ones. Your problem should be fixed in the current CVS version. Can you retry with the current CVS version? As a possible workaround you might want to change the encoding from cp-1252 to iso-8859-1. Does this fix anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 From noreply at sourceforge.net Wed Jun 22 16:43:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 07:43:27 -0700 Subject: [ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization Message-ID: Bugs item #1225584, was opened at 2005-06-22 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Miseler (amiseler) Assigned to: Nobody/Anonymous (nobody) Summary: crash in gcmodule.c on python reinitialization Initial Comment: i have a c++ windows application with embedded python interpreter. this code crashs: Py_Initialize(); PyRun_SimpleString("import gc"); Py_Finalize(); Py_Initialize(); PyRun_SimpleString("import gc"); // <--- BOOM the problem seems to be the global var "garbage" in gcmodule.c the var isn't cleared in the reinitialization and becomes an invalid pointer. setting it to NULL in Py_Finalize fixes the crash. i use python version 2.3.4 but a short look at the 2.4.1 source indicates that the problem is still there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 From noreply at sourceforge.net Wed Jun 22 17:59:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 08:59:42 -0700 Subject: [ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization Message-ID: Bugs item #1225584, was opened at 2005-06-22 15:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Miseler (amiseler) Assigned to: Nobody/Anonymous (nobody) Summary: crash in gcmodule.c on python reinitialization Initial Comment: i have a c++ windows application with embedded python interpreter. this code crashs: Py_Initialize(); PyRun_SimpleString("import gc"); Py_Finalize(); Py_Initialize(); PyRun_SimpleString("import gc"); // <--- BOOM the problem seems to be the global var "garbage" in gcmodule.c the var isn't cleared in the reinitialization and becomes an invalid pointer. setting it to NULL in Py_Finalize fixes the crash. i use python version 2.3.4 but a short look at the 2.4.1 source indicates that the problem is still there. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-22 16:59 Message: Logged In: YES user_id=6656 Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you in a position to check that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 From noreply at sourceforge.net Wed Jun 22 20:09:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 11:09:06 -0700 Subject: [ python-Bugs-1225705 ] os.environ documentation should mention unsetenv Message-ID: Bugs item #1225705, was opened at 2005-06-22 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Wellington (bwelling) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ documentation should mention unsetenv Initial Comment: The (current) documentation for os.environ says: --- If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. --- Some platforms (Solaris 8 and 9, at least) have putenv() but not unsetenv(), which means that setting environment variables by assigning values in os.environ works, but unsetting them by deleting from os.environ doesn't. This is confusing, and should at least be documented (if for no other reason than no one else should waste several hours figuring this out). This was tested with Python 2.4.1 and earlier versions. I'd suggest documenting os.unsetenv() in 6.1.1 (Process Parameters) of the manual, and modifying the above text to say something like: --- If the platform supports the putenv() and unsetenv() functions, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when an entry in the mapping is added or changed, and unsetenv() will be called automatically when an entry is deleted. --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 From noreply at sourceforge.net Wed Jun 22 20:10:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Jun 2005 11:10:49 -0700 Subject: [ python-Bugs-1224347 ] int/long unification and hex() Message-ID: Bugs item #1224347, was opened at 2005-06-20 15:22 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: int/long unification and hex() Initial Comment: There seems to be a bit of an inconsistancy with int/long unification while using hex(). Specifically; >>> hex(int(987259835)) '0x3ad863bb' >>> hex(long(987259835)) '0x3AD863BBL' I understand that longs will have the trailing 'L' until Py3k, but I believe the capitalization should be consistant. If consistancy is desired, I believe that lowercase should be the standard, being that string.encode('hex') also produces lowercase. If the cases are supposed to be different, or making the change would produce known backwards incompatibility for some set of modules, feel free to close this bug report. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-06-22 14:10 Message: Logged In: YES user_id=593130 The trailing L is perhaps easier to see as not a digit if other letters are lowercase: 0x3ad863bbL, versus above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224347&group_id=5470 From noreply at sourceforge.net Thu Jun 23 10:11:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 01:11:39 -0700 Subject: [ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization Message-ID: Bugs item #1225584, was opened at 2005-06-22 16:43 Message generated for change (Comment added) made by amiseler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Miseler (amiseler) Assigned to: Nobody/Anonymous (nobody) Summary: crash in gcmodule.c on python reinitialization Initial Comment: i have a c++ windows application with embedded python interpreter. this code crashs: Py_Initialize(); PyRun_SimpleString("import gc"); Py_Finalize(); Py_Initialize(); PyRun_SimpleString("import gc"); // <--- BOOM the problem seems to be the global var "garbage" in gcmodule.c the var isn't cleared in the reinitialization and becomes an invalid pointer. setting it to NULL in Py_Finalize fixes the crash. i use python version 2.3.4 but a short look at the 2.4.1 source indicates that the problem is still there. ---------------------------------------------------------------------- >Comment By: Alexander Miseler (amiseler) Date: 2005-06-23 10:11 Message: Logged In: YES user_id=693638 yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage) to initgc. that *MIGHT* fix the crash. but only by simply never releasing the garbage list. the garbage variable is still never reset to NULL and therefore no new garbage list is created after reinitialization. besides: the incref is only in gcinit, but the list can be created in gcinit OR in handle_finalizers (and while i was looking at it in the debugger it always was handle_finalizers). i guess the proper way to fix it would be a cleanup function for the gcmodule that is called by Py_Finalize. the cleanup function should do a decref (if Neils incref stays in, i'm not sure if it is needed) and then reset the global vars. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 17:59 Message: Logged In: YES user_id=6656 Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you in a position to check that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 From noreply at sourceforge.net Thu Jun 23 10:22:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 01:22:47 -0700 Subject: [ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization Message-ID: Bugs item #1225584, was opened at 2005-06-22 15:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Miseler (amiseler) >Assigned to: Neil Schemenauer (nascheme) Summary: crash in gcmodule.c on python reinitialization Initial Comment: i have a c++ windows application with embedded python interpreter. this code crashs: Py_Initialize(); PyRun_SimpleString("import gc"); Py_Finalize(); Py_Initialize(); PyRun_SimpleString("import gc"); // <--- BOOM the problem seems to be the global var "garbage" in gcmodule.c the var isn't cleared in the reinitialization and becomes an invalid pointer. setting it to NULL in Py_Finalize fixes the crash. i use python version 2.3.4 but a short look at the 2.4.1 source indicates that the problem is still there. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-23 09:22 Message: Logged In: YES user_id=6656 At this point you might be thinking that Py_NewInterpreter/ Py_EndInterpreter loops are not the best tested things in the world. You'd be right. Neil's fix *does* fix the crash, but also shares PyObject's between interpreter states, which is a bit of a no-no, but otoh, this problem is far from unique to gcmodule.c. > besides: the incref is only in gcinit, but the list can be > created in gcinit OR in handle_finalizers (and while i was > looking at it in the debugger it always was handle_finalizers). That slightly misses the point -- the reason you got a crash was because the PyModule_AddObject initgc stole a reference to garbage, so when the module got cleaned up, it got deallocated despite there still being a reference to it in the module level global. If initgc is never run, the refcount of garbage stays at 1. > i guess the proper way to fix it would be a cleanup function > for the gcmodule that is called by Py_Finalize. Yeah, but quite a lot of modules could do with that, I think. Do you have the energy to work on a 'proper' solution? I don't. ---------------------------------------------------------------------- Comment By: Alexander Miseler (amiseler) Date: 2005-06-23 09:11 Message: Logged In: YES user_id=693638 yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage) to initgc. that *MIGHT* fix the crash. but only by simply never releasing the garbage list. the garbage variable is still never reset to NULL and therefore no new garbage list is created after reinitialization. besides: the incref is only in gcinit, but the list can be created in gcinit OR in handle_finalizers (and while i was looking at it in the debugger it always was handle_finalizers). i guess the proper way to fix it would be a cleanup function for the gcmodule that is called by Py_Finalize. the cleanup function should do a decref (if Neils incref stays in, i'm not sure if it is needed) and then reset the global vars. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 16:59 Message: Logged In: YES user_id=6656 Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you in a position to check that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 From noreply at sourceforge.net Thu Jun 23 11:15:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 02:15:34 -0700 Subject: [ python-Bugs-1224672 ] rsplit introduces spurious CR Message-ID: Bugs item #1224672, was opened at 2005-06-21 07:47 Message generated for change (Comment added) made by rprosser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. ---------------------------------------------------------------------- >Comment By: Richard Prosser (rprosser) Date: 2005-06-23 09:15 Message: Logged In: YES user_id=599403 False alarm - Unix issues CR/LF sequence with a tty appararently, and I am using ssh with pexpect. I have confirmed this via 'od'. See http://pexpect.sourceforge.net/ for details. Apologies. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 07:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 From noreply at sourceforge.net Thu Jun 23 12:03:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 03:03:14 -0700 Subject: [ python-Bugs-1224672 ] rsplit introduces spurious CR Message-ID: Bugs item #1224672, was opened at 2005-06-21 09:47 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 12:03 Message: Logged In: YES user_id=1188172 Closing as Invalid, then. ---------------------------------------------------------------------- Comment By: Richard Prosser (rprosser) Date: 2005-06-23 11:15 Message: Logged In: YES user_id=599403 False alarm - Unix issues CR/LF sequence with a tty appararently, and I am using ssh with pexpect. I have confirmed this via 'od'. See http://pexpect.sourceforge.net/ for details. Apologies. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 09:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 From noreply at sourceforge.net Thu Jun 23 14:39:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 05:39:40 -0700 Subject: [ python-Bugs-1041501 ] SimpleXMLRPCServer example is broken Message-ID: Bugs item #1041501, was opened at 2004-10-06 14:31 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 Please note that this 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.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer example is broken Initial Comment: Section 11.21.1 of the library reference (SimpleXMLRPCServer Objects) includes this class definition: class MyFuncs: def div(self, x, y) : return div(x,y) This is given to the sample server as in instance object. The problem is that there is no global div() function so attempting to call div() from XML-RPC returns a Fault with a NameError. ---------------------------------------------------------------------- >Comment By: Kent Johnson (kjohnson) Date: 2005-06-23 12:39 Message: Logged In: YES user_id=49695 Reopened because a similar fix is needed on the page 11.23.2 CGIXMLRPCRequestHandler ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-08 18:34 Message: Logged In: YES user_id=11375 Fixed; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 From noreply at sourceforge.net Thu Jun 23 15:26:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 06:26:36 -0700 Subject: [ python-Feature Requests-1226256 ] Add Jason Orendorff's path module to stdlib Message-ID: Feature Requests item #1226256, was opened at 2005-06-23 13:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add Jason Orendorff's path module to stdlib Initial Comment: Jason Orendorff has produced an excellent path module which has an OOP approach to path, directory, and file manipulation, as well as including some new convenience functions. In my opinion, it allows much more Pythonic path manipulation than the functions in os and os.path. It is quite stable and includes unit tests. I and many others have been using it for years. http://www.jorendorff.com/articles/python/path/ I am requesting that it be added to the stdlib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 From noreply at sourceforge.net Thu Jun 23 18:03:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 09:03:52 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 20:24 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-23 18:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 12:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Thu Jun 23 18:05:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 09:05:09 -0700 Subject: [ python-Bugs-1180160 ] subprocess.Popen fails with closed stdout Message-ID: Bugs item #1180160, was opened at 2005-04-10 13:41 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: neuhauser (neuhauser) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen fails with closed stdout Initial Comment: I have a piece of code that gets run in a script that has its stdout closed: import sys sys.stdout = sys.stderr c = subprocess.Popen (..., stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.STDOUT) and this is what I get: Sending SVNR/permissions Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Traceback (most recent call last): (...) File ".../__init__.py", line 40, in run stderr = subprocess.STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 554, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 986, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory This is the child_traceback: File "/usr/local/lib/python2.4/subprocess.py", line 955, in _execute_child File "/usr/local/lib/python2.4/os.py", line 341, in execvp File "/usr/local/lib/python2.4/os.py", line 379, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory http://docs.python.org/lib/node230.html claims that "PIPE indicates that a new pipe to the child should be created" which doesn't seem to be the case. Subversion code that runs the script can be seen at http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_repos/hooks.c (run_hook_cmd()). ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-06-23 18:05 Message: Logged In: YES user_id=344921 No response in over 2 months. Closing. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-04-14 21:26 Message: Logged In: YES user_id=344921 I can't se anything in your report that indicates that a closed stdout is the problem. execvp() says "No such file or directory", which means that the file you are trying to execute doesn't exist. Do you have any reason to believe that this error message is not true? It would help if you could give me a working *Python* example, indicating the problem. The source http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_repos/hooks.c is written in C, not Python... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180160&group_id=5470 From noreply at sourceforge.net Thu Jun 23 19:30:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 10:30:47 -0700 Subject: [ python-Bugs-1226404 ] Can't take sequence slice past 32K Message-ID: Bugs item #1226404, was opened at 2005-06-23 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 From noreply at sourceforge.net Thu Jun 23 19:36:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 10:36:19 -0700 Subject: [ python-Bugs-1226404 ] Can't take sequence slice past 32K Message-ID: Bugs item #1226404, was opened at 2005-06-23 19:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 19:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 From noreply at sourceforge.net Thu Jun 23 19:36:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 10:36:29 -0700 Subject: [ python-Bugs-1226404 ] Can't take sequence slice past 32K Message-ID: Bugs item #1226404, was opened at 2005-06-23 13:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-06-23 13:36 Message: Logged In: YES user_id=31435 Something's confused here. x[y, z] doesn't ask for a slice, it's trying to index x by the two-tuple (y, z). x[y:z] (with a colon) is the way to ask for a slice. I don't have any trouble with slice notation regardless of how large the slice bounds are, but of course a sequence complains if you try to index it with a tuple. >>> x = 'spam' * 16000 >>> len(x[34000:34100]) # slice notation 100 >>> len(x[34000, 34100]) # trying to index with a tuple Traceback (most recent call last): File "", line 1, in ? TypeError: string indices must be integers Is that all there is to this? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 13:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 From noreply at sourceforge.net Thu Jun 23 19:49:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 10:49:19 -0700 Subject: [ python-Bugs-1226404 ] Can't take sequence slice past 32K Message-ID: Bugs item #1226404, was opened at 2005-06-23 18:30 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-23 18:49 Message: Logged In: YES user_id=6656 Battle of the dueling updates! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-06-23 18:36 Message: Logged In: YES user_id=31435 Something's confused here. x[y, z] doesn't ask for a slice, it's trying to index x by the two-tuple (y, z). x[y:z] (with a colon) is the way to ask for a slice. I don't have any trouble with slice notation regardless of how large the slice bounds are, but of course a sequence complains if you try to index it with a tuple. >>> x = 'spam' * 16000 >>> len(x[34000:34100]) # slice notation 100 >>> len(x[34000, 34100]) # trying to index with a tuple Traceback (most recent call last): File "", line 1, in ? TypeError: string indices must be integers Is that all there is to this? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 18:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 From noreply at sourceforge.net Thu Jun 23 20:34:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Jun 2005 11:34:45 -0700 Subject: [ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization Message-ID: Bugs item #1225584, was opened at 2005-06-22 14:43 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Miseler (amiseler) Assigned to: Neil Schemenauer (nascheme) Summary: crash in gcmodule.c on python reinitialization Initial Comment: i have a c++ windows application with embedded python interpreter. this code crashs: Py_Initialize(); PyRun_SimpleString("import gc"); Py_Finalize(); Py_Initialize(); PyRun_SimpleString("import gc"); // <--- BOOM the problem seems to be the global var "garbage" in gcmodule.c the var isn't cleared in the reinitialization and becomes an invalid pointer. setting it to NULL in Py_Finalize fixes the crash. i use python version 2.3.4 but a short look at the 2.4.1 source indicates that the problem is still there. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-06-23 18:34 Message: Logged In: YES user_id=35752 Well, the fact that some things are broken is not a good excuse to introduce more brokeness. I guess decrefing the gc.garbage list and letting any reference cycles contained in it leak is better than sharing objects between interpreters. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-23 08:22 Message: Logged In: YES user_id=6656 At this point you might be thinking that Py_NewInterpreter/ Py_EndInterpreter loops are not the best tested things in the world. You'd be right. Neil's fix *does* fix the crash, but also shares PyObject's between interpreter states, which is a bit of a no-no, but otoh, this problem is far from unique to gcmodule.c. > besides: the incref is only in gcinit, but the list can be > created in gcinit OR in handle_finalizers (and while i was > looking at it in the debugger it always was handle_finalizers). That slightly misses the point -- the reason you got a crash was because the PyModule_AddObject initgc stole a reference to garbage, so when the module got cleaned up, it got deallocated despite there still being a reference to it in the module level global. If initgc is never run, the refcount of garbage stays at 1. > i guess the proper way to fix it would be a cleanup function > for the gcmodule that is called by Py_Finalize. Yeah, but quite a lot of modules could do with that, I think. Do you have the energy to work on a 'proper' solution? I don't. ---------------------------------------------------------------------- Comment By: Alexander Miseler (amiseler) Date: 2005-06-23 08:11 Message: Logged In: YES user_id=693638 yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage) to initgc. that *MIGHT* fix the crash. but only by simply never releasing the garbage list. the garbage variable is still never reset to NULL and therefore no new garbage list is created after reinitialization. besides: the incref is only in gcinit, but the list can be created in gcinit OR in handle_finalizers (and while i was looking at it in the debugger it always was handle_finalizers). i guess the proper way to fix it would be a cleanup function for the gcmodule that is called by Py_Finalize. the cleanup function should do a decref (if Neils incref stays in, i'm not sure if it is needed) and then reset the global vars. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-22 15:59 Message: Logged In: YES user_id=6656 Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you in a position to check that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470 From noreply at sourceforge.net Fri Jun 24 11:41:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 02:41:26 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 13:18 Message generated for change (Comment added) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 06:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-23 00:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 13:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Fri Jun 24 14:35:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 05:35:19 -0700 Subject: [ python-Bugs-1226955 ] cPickle and pickle dump bug (inf float) Message-ID: Bugs item #1226955, was opened at 2005-06-24 14:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle and pickle dump bug (inf float) Initial Comment: An "inf float" can't be dumped in binary form. Python 2.4.1 (#1, Jun 10 2005, 16:30:55) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> import cPickle >>> pickle.dumps (10e5000) 'Finf\n.' >>> pickle.dumps (10e5000, pickle.HIGHEST_PROTOCOL) Traceback (most recent call last): File "", line 1, in ? File "/home/bolz/DLD/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/home/bolz/DLD/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/home/bolz/DLD/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/bolz/DLD/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226955&group_id=5470 From noreply at sourceforge.net Fri Jun 24 15:05:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 06:05:07 -0700 Subject: [ python-Bugs-1226969 ] segfault in os module Message-ID: Bugs item #1226969, was opened at 2005-06-24 13:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jacobo_es (jacobo_es) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in os module Initial Comment: python crashes when a bad parameters are passed to execl function of the os module: >>> import os >>> os.execl("/bin/bash") Segmentation Fault (core dumped) No matter the platform (on ppc raises a bus error) and the version of C compiler, always crashes, python versions used are 2.4.1 and 2.4c1. Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise and debian woody 3.0 (x86). However, on 2.2.3 version not crashes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 From noreply at sourceforge.net Fri Jun 24 15:19:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 06:19:37 -0700 Subject: [ python-Bugs-1226955 ] cPickle and pickle dump bug (inf float) Message-ID: Bugs item #1226955, was opened at 2005-06-24 13:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226955&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) >Assigned to: Michael Hudson (mwh) Summary: cPickle and pickle dump bug (inf float) Initial Comment: An "inf float" can't be dumped in binary form. Python 2.4.1 (#1, Jun 10 2005, 16:30:55) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> import cPickle >>> pickle.dumps (10e5000) 'Finf\n.' >>> pickle.dumps (10e5000, pickle.HIGHEST_PROTOCOL) Traceback (most recent call last): File "", line 1, in ? File "/home/bolz/DLD/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/home/bolz/DLD/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/home/bolz/DLD/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/bolz/DLD/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-06-24 14:19 Message: Logged In: YES user_id=6656 This should work in CVS HEAD. It's not very likely that it will get backported though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226955&group_id=5470 From noreply at sourceforge.net Fri Jun 24 16:53:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 07:53:55 -0700 Subject: [ python-Bugs-1226969 ] segfault in os module Message-ID: Bugs item #1226969, was opened at 2005-06-24 15:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jacobo_es (jacobo_es) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in os module Initial Comment: python crashes when a bad parameters are passed to execl function of the os module: >>> import os >>> os.execl("/bin/bash") Segmentation Fault (core dumped) No matter the platform (on ppc raises a bus error) and the version of C compiler, always crashes, python versions used are 2.4.1 and 2.4c1. Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise and debian woody 3.0 (x86). However, on 2.2.3 version not crashes. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-24 16:53 Message: Logged In: YES user_id=1188172 This behaviour was introduced with the fixing of bug #952953, where someone complained that he couldn't call execl with only one argument. I tried this directly on the C layer on Linux, and it segfaults too. Are there OSes where this is legal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 From noreply at sourceforge.net Fri Jun 24 20:01:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 11:01:42 -0700 Subject: [ python-Bugs-1227166 ] Queue class does not inherit object Message-ID: Bugs item #1227166, was opened at 2005-06-24 18:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vincent C?t?-Roy (jbabel) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class does not inherit object Initial Comment: Queue class does not inherit object, and thus is not a so-called new-style class. That means you can't sub-class it and do things like call super on it. One would expect all classes shipped with the Python library to inherit object, especially since it's so easy to apply such a change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227166&group_id=5470 From noreply at sourceforge.net Fri Jun 24 20:23:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 11:23:01 -0700 Subject: [ python-Bugs-1227181 ] CGIXMLRPCRequestHandler example uses nonexistant "div()" Message-ID: Bugs item #1227181, was opened at 2005-06-24 18:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227181&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: CGIXMLRPCRequestHandler example uses nonexistant "div()" Initial Comment: The example code in http://python.org/dev/doc/devel/lib/node551.html uses a "div" function that does not exist, and is slightly confusing for someone who just tries to copy-and-paste the code to see what it does. To make the relationship between the code there and the other SimpleXMLRPCServer code here: http://python.org/dev/doc/devel/lib/simple-xmlrpc-servers.html, the definition of the MyFuncs class should be identical. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227181&group_id=5470 From noreply at sourceforge.net Fri Jun 24 22:57:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Jun 2005 13:57:32 -0700 Subject: [ python-Bugs-1227181 ] CGIXMLRPCRequestHandler example uses nonexistant "div()" Message-ID: Bugs item #1227181, was opened at 2005-06-24 18:23 Message generated for change (Comment added) made by dyoo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227181&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: CGIXMLRPCRequestHandler example uses nonexistant "div()" Initial Comment: The example code in http://python.org/dev/doc/devel/lib/node551.html uses a "div" function that does not exist, and is slightly confusing for someone who just tries to copy-and-paste the code to see what it does. To make the relationship between the code there and the other SimpleXMLRPCServer code here: http://python.org/dev/doc/devel/lib/simple-xmlrpc-servers.html, the definition of the MyFuncs class should be identical. ---------------------------------------------------------------------- >Comment By: Danny Yoo (dyoo) Date: 2005-06-24 20:57 Message: Logged In: YES user_id=49843 oops, duplicate of SF#1041501. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227181&group_id=5470 From noreply at sourceforge.net Sat Jun 25 18:46:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 09:46:34 -0700 Subject: [ python-Bugs-1217152 ] Info from man python not in docs Message-ID: Bugs item #1217152, was opened at 2005-06-08 20:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217152&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Info from man python not in docs Initial Comment: Some of the information available from 'man python' is not available anywhere else in the docs. In particular there is no comprehensive, detailed listing of all the command line options and environment variables. Consequently this information is not available to users on platforms that don't support man, such as Windows. I suggest adding an appendix to the tutorial or language reference that includes the info from the man page. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 18:46 Message: Logged In: YES user_id=1188172 Closed as a duplicate of #469773. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217152&group_id=5470 From noreply at sourceforge.net Sat Jun 25 20:25:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 11:25:34 -0700 Subject: [ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail() Message-ID: Bugs item #1217513, was opened at 2005-06-09 14:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Omission in docs for smtplib.SMTP.sendmail() Initial Comment: In Library Reference 11.12.1 SMTP Objects, the description of the to_addrs parameter to SMTP.sendmail() is, "a list of RFC 822 to-address strings". In fact sendmail() also allows a single string to be passed as to_addrs. The comment in smtplib.py says, "to_addrs: A list of addresses to send this mail to. A barestring will be treated as a list with 1 address." I suggest the Library Reference be changed to say, "a list of RFC 822 to-address strings or a single to-address string" ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:25 Message: Logged In: YES user_id=1188172 Fixed by accepting patch #1227442. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&group_id=5470 From noreply at sourceforge.net Sat Jun 25 20:47:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 11:47:49 -0700 Subject: [ python-Bugs-1225705 ] os.environ documentation should mention unsetenv Message-ID: Bugs item #1225705, was opened at 2005-06-22 20:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Wellington (bwelling) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.environ documentation should mention unsetenv Initial Comment: The (current) documentation for os.environ says: --- If the platform supports the putenv() function, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when the mapping is modified. --- Some platforms (Solaris 8 and 9, at least) have putenv() but not unsetenv(), which means that setting environment variables by assigning values in os.environ works, but unsetting them by deleting from os.environ doesn't. This is confusing, and should at least be documented (if for no other reason than no one else should waste several hours figuring this out). This was tested with Python 2.4.1 and earlier versions. I'd suggest documenting os.unsetenv() in 6.1.1 (Process Parameters) of the manual, and modifying the above text to say something like: --- If the platform supports the putenv() and unsetenv() functions, this mapping may be used to modify the environment as well as query the environment. putenv() will be called automatically when an entry in the mapping is added or changed, and unsetenv() will be called automatically when an entry is deleted. --- ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 20:47 Message: Logged In: YES user_id=1188172 Fixed as Doc/lib/libos.tex r1.158, r1.146.2.4. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:17:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:17:42 -0700 Subject: [ python-Bugs-1202475 ] httplib docs mentioning HTTPConnection.getreply Message-ID: Bugs item #1202475, was opened at 2005-05-15 22:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: httplib docs mentioning HTTPConnection.getreply Initial Comment: ... instead of getresponse in the description of send(). Also, a general note or explanation like that could be given before the description of send(): """ You can send requests in two ways: either using the request() method as described above, which combines all request parameters, or using a sequence of putrequest(), zero or more times addheader(), endheaders() and then send(). """ It is sort of confusing in its current state. Oh yes, and while you're at it ;), you could add a note that the response object must be read completely before a new request can be sent. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 21:17 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libhttplib.tex r1.39, r1.38.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:24:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:24:48 -0700 Subject: [ python-Bugs-1227480 ] Two requests to one file are not done in parallel Message-ID: Bugs item #1227480, was opened at 2005-06-25 21: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=1227480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Franz (mmf1987) Assigned to: Nobody/Anonymous (nobody) Summary: Two requests to one file are not done in parallel Initial Comment: Hi! I am using Python for CGI scripting. I had a little cgi script (see the attached file). I saved it as test1.py - and tried to load it over HTTP. So everything is fine. But now I saw a very strange behaviour: I sent two parallel requests to the script (for example by sending two requests in two browser windows almost at the same time). My problem: The requests to the script seem NOT to be done in parallel: The first script prints "starting..." and after a short time "finished". And then in the other browser window the second request shows "starting...". But I expected that in both browser windows "starting" will be shown almost at the same time because the two requests are done in parallel. The strange behaviour goes on: If copied the test1.py and saved it as test2.py. Now I retried my test and sent two requests - but to these two identical files (that only differ in their filename). The the two requests seem to be done in parallel... (It tried my test on Fedora and Gentoo Linux, with Python 2.2 and Python 2.4, with different webservers (Apache and others), and with several different browsers - I always was the same.) I think the behaviour will be the same if I use my script on the command line... Best regards, Markus Franz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227480&group_id=5470 From noreply at sourceforge.net Sat Jun 25 21:55:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 12:55:50 -0700 Subject: [ python-Bugs-1190563 ] os.waitpid docs don't specify return value for WNOHANG Message-ID: Bugs item #1190563, was opened at 2005-04-26 22:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: jls (apjenkins) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.waitpid docs don't specify return value for WNOHANG Initial Comment: The library documentation for os.waitpid() does not specify what the return value should be if the os.WNOHANG flag is given, and the process still hasn't exited. p, v = os.waitpid(pid, os.WNOHANG) Through trial and error I discovered that in this case, os.waitpid returns the tuple (0, 0) if pid is still running. This should be in the documentation for os.waitpid(). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 21:55 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/lib/libos.tex r1.160, r1.146.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:02:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:02:34 -0700 Subject: [ python-Bugs-801992 ] cgi.CGIHTTPRequestHandler remembers QUERY_STRING Message-ID: Bugs item #801992, was opened at 2003-09-07 15:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Ivo Danihelka (fidlej) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.CGIHTTPRequestHandler remembers QUERY_STRING Initial Comment: Python 2.3+, Debian SID: cgi.CGIHTTPRequestHandler remembers QUERY_STRING from last query. If query is '', then condition "if query:" fails and env['QUERY_STRING'] is remembered from last query. Solution: --- /usr/lib/python2.3/CGIHTTPServer.py 2003-09-07 15:33:41.000000000 +0200 +++ CGIHTTPServer.py 2003-09-07 15:36:27.000000000 +0200 @@ -147,8 +147,7 @@ env['PATH_INFO'] = uqrest env['PATH_TRANSLATED'] = self.translate_path(uqrest) env['SCRIPT_NAME'] = scriptname - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query host = self.address_string() if host != self.client_address[0]: env['REMOTE_HOST'] = host ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:02 Message: Logged In: YES user_id=1188172 This is a duplicate of #777848, closing as such. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 05:40 Message: Logged In: YES user_id=80475 See the patch at www.python.org/sf/796772 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 21:48 Message: Logged In: YES user_id=21627 I believe the bug lies elsewhere: If we have fork, we shouldn't set the environment variables in the parent process, but only in the child process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=801992&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:08:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:08:09 -0700 Subject: [ python-Bugs-1175022 ] property example code error Message-ID: Bugs item #1175022, was opened at 2005-04-01 22:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: John Ridley (ojokimu) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: property example code error Initial Comment: The example code for 'property' in lib/built-in-funcs.html may produce an error if run "as is": Python 2.4.1 (#1, Mar 31 2005, 21:33:58) [GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 >>> class C(object): ... def getx(self): return self.__x ... def setx(self, value): self.__x = value ... def delx(self): del self.__x ... x = property(getx, setx, delx, "I'm the 'x' property.") ... >>> c=C() >>> c.x Traceback (most recent call last): File "", line 1, in ? File "", line 2, in getx AttributeError: 'C' object has no attribute '_C__x' The same goes for 'del c.x' (although not 'c.x = 0', of course). A more "typical" way of defining managed attributes would be to include an 'init' as follows: class C(object): def __init__(self): self.__x = None def getx(self): return self.__x def setx(self, value): self.__x = value def delx(self): del self.__x x = property(getx, setx, delx, "I'm the 'x' property.") ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:08 Message: Logged In: YES user_id=1188172 Thanks for the report; fixed as Doc/lib/libfuncs.tex r1.184, r1.175.2.4. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:33 Message: Logged In: YES user_id=81797 I agree, adding the __init__ to set a value would be useful. +1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:21:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:21:01 -0700 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 14:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:21 Message: Logged In: YES user_id=1188172 Closing this as Won't Fix, as mktemp is really deprecated now and shouldn't be used. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-11 11:29 Message: Logged In: YES user_id=792746 It is already hard to keep a system working in a changing world, so I see no necessity to needlessly introduce incompatibilities. Your comments are apreciated nonetheless. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 16:56 Message: Logged In: YES user_id=11105 Well, you could close the file (or even remove it, depending on your requirements), and pass the filename to the spawned program. Or, if you insist on using mktemp(), pass a prefix argument yourself? But I'm not really sure if this is what you need, so this is my last comment. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-10 15:17 Message: Logged In: YES user_id=792746 This is no option. In our system we need to spawn another program which doesn't accept file handles but wants to have a filename instead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 15:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Sat Jun 25 22:44:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 13:44:47 -0700 Subject: [ python-Bugs-1186072 ] tempnam doc doesn't include link to tmpfile Message-ID: Bugs item #1186072, was opened at 2005-04-19 17:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: tempnam doc doesn't include link to tmpfile Initial Comment: Both tmpnam and tempnam include references to tmpfile (as a preferred way of using temporary files). However, they don't include a link to the page where tmpfile is documented, and it is documented in a different (non-obvious) section of the ``os`` page. A link to the section containing tmpfile would be helpful. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 22:44 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/lib/libos.tex r1.161, r1.146.2.7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&group_id=5470 From noreply at sourceforge.net Sat Jun 25 23:04:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 14:04:32 -0700 Subject: [ python-Bugs-1166582 ] IterableUserDict not in docs Message-ID: Bugs item #1166582, was opened at 2005-03-19 19:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: IterableUserDict not in docs Initial Comment: There is no mention of UserDict.IterableUserDict in the docs (3.7 UserDict). Here is a suggested rewrite: class UserDict( [initialdata]) Class that simulates a dictionary. The instance's contents are kept in a regular dictionary, which is accessible via the data attribute of UserDict instances. If initialdata is provided, data is initialized with its contents; note that a reference to initialdata will not be kept, allowing it be used for other purposes. Note: For backward compatibility, instances of UserDict are not iterable. class IterableUserDict( [initialdata]) Subclass of UserDict that supports direct iteration (e.g. "for key in myDict"). In addition to supporting the methods and operations of mappings (see section 2.3.8), UserDict and IterableUserDict instances provide the following attribute: ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-25 23:04 Message: Logged In: YES user_id=1188172 Thanks for the report; fixed as Doc/lib/libuserdict.tex r1.27, r1.24.4.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&group_id=5470 From noreply at sourceforge.net Sat Jun 25 23:11:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 14:11:15 -0700 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2005-06-25 23:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 19:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 From noreply at sourceforge.net Sun Jun 26 00:05:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 15:05:12 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 20:56 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: M.-A. Lemburg (lemburg) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-26 00:05 Message: Logged In: YES user_id=174455 I tried to come up with a doc-patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-06-02 13:48 Message: Logged In: YES user_id=38388 A doc-patch would be nice. I don't like the general situation either. Unicode doesn't behave like this and I don't think string.lower() and .upper() should either, but there are users out there who think differently, so we might want to add a parameter which then allows modifying the type of mapping: string.lower(map='ascii') string.upper(map='latin-1') etc. Just an idea. PS: I'll be offline for two weeks now, so don't expect any more comments before then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:43 Message: Logged In: YES user_id=80475 Mark, do you have any thoughts on this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Sun Jun 26 01:15:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 16:15:09 -0700 Subject: [ python-Bugs-1226969 ] segfault in os module Message-ID: Bugs item #1226969, was opened at 2005-06-24 13:05 Message generated for change (Comment added) made by jacobo_es You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jacobo_es (jacobo_es) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in os module Initial Comment: python crashes when a bad parameters are passed to execl function of the os module: >>> import os >>> os.execl("/bin/bash") Segmentation Fault (core dumped) No matter the platform (on ppc raises a bus error) and the version of C compiler, always crashes, python versions used are 2.4.1 and 2.4c1. Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise and debian woody 3.0 (x86). However, on 2.2.3 version not crashes. ---------------------------------------------------------------------- >Comment By: jacobo_es (jacobo_es) Date: 2005-06-25 23:15 Message: Logged In: YES user_id=1302185 I tried this directly on the C layer, too, and not raises a signal 11, segmentation fault, just the function execl() isn't executed and the program flow goes, not raises a sigsegv, and that's not happen in the same way in python, that abort the python interpreter and dump a core file. -( tmp )- ./p execl not executed. -( tmp )- cat p.c #include int main() { execl("/bin/bash"); fprintf(stderr, "execl not executed.\n"); exit(-1); } ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-24 14:53 Message: Logged In: YES user_id=1188172 This behaviour was introduced with the fixing of bug #952953, where someone complained that he couldn't call execl with only one argument. I tried this directly on the C layer on Linux, and it segfaults too. Are there OSes where this is legal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 From noreply at sourceforge.net Sun Jun 26 08:19:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 23:19:45 -0700 Subject: [ python-Bugs-1226969 ] segfault in os module Message-ID: Bugs item #1226969, was opened at 2005-06-24 15:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jacobo_es (jacobo_es) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in os module Initial Comment: python crashes when a bad parameters are passed to execl function of the os module: >>> import os >>> os.execl("/bin/bash") Segmentation Fault (core dumped) No matter the platform (on ppc raises a bus error) and the version of C compiler, always crashes, python versions used are 2.4.1 and 2.4c1. Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise and debian woody 3.0 (x86). However, on 2.2.3 version not crashes. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 08:19 Message: Logged In: YES user_id=1188172 First, Python does not call the C execl functions, but translates them to execv calls. For execv called like Python does: ~/tmp> ./execv zsh: 15395 segmentation fault ./execv ~/tmp> cat execv.c #include #include int main() { const char* args[1]; args[0] = NULL; execv("/bin/bash", args); return errno; } For execl on the C layer, my Linux doesn't want that: ~/tmp> gcc -o execl execl.c execl.c: In function `main': execl.c:4: error: too few arguments to function 'execl' ~/tmp> cat execv.c #include int main() { execl("/bin/bash"); return 0; } ---------------------------------------------------------------------- Comment By: jacobo_es (jacobo_es) Date: 2005-06-26 01:15 Message: Logged In: YES user_id=1302185 I tried this directly on the C layer, too, and not raises a signal 11, segmentation fault, just the function execl() isn't executed and the program flow goes, not raises a sigsegv, and that's not happen in the same way in python, that abort the python interpreter and dump a core file. -( tmp )- ./p execl not executed. -( tmp )- cat p.c #include int main() { execl("/bin/bash"); fprintf(stderr, "execl not executed.\n"); exit(-1); } ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-24 16:53 Message: Logged In: YES user_id=1188172 This behaviour was introduced with the fixing of bug #952953, where someone complained that he couldn't call execl with only one argument. I tried this directly on the C layer on Linux, and it segfaults too. Are there OSes where this is legal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 From noreply at sourceforge.net Sun Jun 26 08:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Jun 2005 23:21:07 -0700 Subject: [ python-Bugs-1069410 ] import on Windows: please call SetErrorMode first Message-ID: Bugs item #1069410, was opened at 2004-11-19 15:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069410&group_id=5470 Please note that this message will contain 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 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: import on Windows: please call SetErrorMode first Initial Comment: Hi, We have a problem with "import" on Windows XP. If we attempt to import a missing Python module, an exception is raised. That's OK. If we attempt to import an existing Python module depending on a missing DLL, then the Windows runtime will pop up an error message, before the exception is raised by Python. That's not OK. I would expect an exception should be thrown, but I believe the Windows error message should not be displayed. I guess the error message originates in the win32 LoadLibrary function: http://msdn.microsoft.com/library/en-us/dllproc/base/loadlibrary.asp According to this documentation: To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function. SetErrorMode is documented here: http://msdn.microsoft.com/library/en-us/debug/base/seterrormode.asp I believe Python should handle the DLL error instead of letting the system handle it. The default behavior is not appropriate for most Python programs. The Python way of dealing with errors is raising an exception, not passing errors to the system and let it pop up platform specific error messages. We're running Python 2.3.4 on Windows XP. Background: The problems occurs when importing the PyMat library. This Matlab wrapper depends on a Matlab DLL. We don't know before hand whether Matlab is present or not on the system. We expect import pymat to raise an exception if Matlab is not installed. We don't want the user to have to click in the annoying control popped up by the Windows runtime. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 08:21 Message: Logged In: YES user_id=1188172 That seems to be a correct wish. Is there any problem with SetErrorMode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069410&group_id=5470 From noreply at sourceforge.net Sun Jun 26 15:37:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 06:37:33 -0700 Subject: [ python-Bugs-1227748 ] subprocess: inheritance of std descriptors inconsistent Message-ID: Bugs item #1227748, was opened at 2005-06-26 15:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andr? Malo (ndparker) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: inheritance of std descriptors inconsistent Initial Comment: The inheritance of std descriptors is inconsistent between Unix and Windows implementations. If one calls Popen with stdin = stdout = stderr = None, the caller's std descriptors are inherited on *x, but not on Windows, because of the following optimization (from subprocess.py r1.20): 655 def _get_handles(self, stdin, stdout, stderr): 656 """Construct and return tupel with IO objects: 657 p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite 658 """ 659 if stdin is None and stdout is None and stderr is None: 660 return (None, None, None, None, None, None) 661 I suggest to just remove those lines 659 and 660. The current workaround is to duplicate the handles by the application and supply an own STARTUPINFO structure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&group_id=5470 From noreply at sourceforge.net Sun Jun 26 19:47:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 10:47:56 -0700 Subject: [ python-Feature Requests-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname Message-ID: Feature Requests item #1110010, was opened at 2005-01-26 08:28 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname Initial Comment: One of the side effects of the new-style classes is that objects don't necessarily have __dict__ attached to them. It used to be possible to write things like def __str__(self): return "Node %(name)s, %(nlinks)d links, active: %(active)s" % self.__dict__ ... but this doesn't work if the class doesn't have a __dict__. Even if does, I'm not sure it will always get members from base classes. There is a 'vars' function; you could put 'vars(self)' in the above instead of self.__dict__, but it still doesn't work if the class doesn't have a __dict__. I can see different solutions for this: (1) change the 'string %' operator so that it allows %(.name)s, leading to a getattr() on the right-side argument rather than a getitem. return "Node %(.name)s, %(.nlinks)d links, active: %(.active)s" % self (2) Make a builtin like vars, but which works when the object doesn't have a __dict__ I.e. attrmap(x) would return a mapping which is bound to x, and reading attrmap(x)['attname'] is the same as getattr(x,'attname'). Thus return "Node %(name)s, %(nlinks)d links, active: %(active)s" % attrmap(self) This attrmap() function can be implemented in pure python, of course. I originally thought (1) made a lot of sense, but (2) seems to work just as well and doesn't require changing much. Also, (1) allows cases like "%(name)s %(.name2)s", which are not very useful, but are very likely to be created by accident; whereas in (2) you are deciding on the right of the '%' whether you are naming attributes or providing mapping keys. I'm not sure it's a good idea change 'vars' to have this behaviour, since vars(x).keys() currently works in a predictable way when vars(x) works; whereas attrmap(x).keys() may not be complete, or possible, even when attrmap(x) is useful. I.e. when x has a __getattr__ defined. On the other hand, vars(x) doesn't currently do much at all, so maybe it's possible to enhance it like this without breaking anything. The motivation for this came from the "%(name)s" issue, but the attrmap() function would be useful in other places e.g. processdata( infile, outfile, **attrmap(options)) ... where options might be obtained from optparse, e.g. Or, an attrmap can be used with the new Templates: string.Template('Node $name').substitute( attrmap(node)) Both of these examples will work with vars(), but only when the object actually has __dict__. This is why I'm thinking it may make sense to enhance vars: some code may be broken by the change; but other code, broken by new-style classes, may be unbroken by this change. The proxy could be writable, so that attrmap(x)['a'] = y is the same as x.a = y .. which could have more uses. A possible useful (possibly weird) variation: attrmap accepts 1 or more parameters, and the resulting proxy is bound to all of them. when attrmap(x,y,z)['a'] is done, the proxy will try x.a, y.a, z.a until one of them doesn't raise AttributeError. So it's equivalent to merging dictionaries. This would be useful in the %(name)s or Template cases, where you want information from several objects. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 10:47 Message: Logged In: YES user_id=341410 An implementation of the base attrmap functionality (as suggested by Reinhold in his post in python-dev)... class attrmap: def __init__(self, obj): self.obj = obj def __getitem__(self, key): return getattr(self.obj, key) To Gregory Smith: If you merely add the __getitem__ method with a 'self' as the first argument of getattr, you don't even need attrmap. As an aside, when I want dictionary-like behavior from my classes, I use a dictionary or something that implements a subset of the mapping protocol. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-11 16:51 Message: Logged In: YES user_id=21627 I think I would rather not to see this as a builtin, e.g. putting it into UserDict.AttrMap instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Sun Jun 26 21:47:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 12:47:06 -0700 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 12:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun Jun 26 22:01:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 13:01:36 -0700 Subject: [ python-Bugs-1180237 ] Python keeps file references after calling close methode Message-ID: Bugs item #1180237, was opened at 2005-04-10 08:20 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180237&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eelco (eternia) Assigned to: Nobody/Anonymous (nobody) Summary: Python keeps file references after calling close methode Initial Comment: I found this bug using a python script that: - first mounts a partition (os.system("mount") etc) - change a few files on this partition (f = open (); f.write; f.close) - umounts the partition (os.system("umount") etc) Strangely, the umount didn't work because of a filesystem busy error. Using fuser and lsof i traced this being busy back to the script itself. This is strange behavior because after changing the files on the mounted partition the close method was called which should close all references to the file on the partition. Finally the solution was to do f = 0. So if python has closed a file on a mount a open reference to that file will keep to exist until the script has ended or until the file object is nullified. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-06-26 13:01 Message: Logged In: YES user_id=971153 I also failed to reproduce the problem with a recent Python build on Debian (python session at the bottom) Suggest closing the bug. bagira:~/python> dist/src/python Python 2.5a0 (#18, Jun 2 2005, 17:12:48) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("mount /floppy") 0 >>> f=open("/floppy/test","w") >>> f.write('abcd') >>> f.close() >>> os.system('umount /floppy') 0 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-04-14 12:50 Message: Logged In: YES user_id=2772 I tried but can't reproduce this problem. After mounting a filesystem on /mnt/tmp, I ran the following in an interactive session: >>> f = open("/mnt/tmp/x", "w") >>> f.write("testing") >>> f.close() >>> import os; os.system("umount /mnt/tmp") 0 Did you write 'f.close()' or 'f.close'? The former closes the file, but the latter is a statement which has no effect. When you later executed 'f=0', the reference count of the-old-value-of-f dropped to 0 and the file was close()d impliclty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180237&group_id=5470 From noreply at sourceforge.net Sun Jun 26 22:23:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 13:23:02 -0700 Subject: [ python-Bugs-1072853 ] thisid not intialized in pindent.py script Message-ID: Bugs item #1072853, was opened at 2004-11-25 00:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niraj Bajpai (nbajpai) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: thisid not intialized in pindent.py script Initial Comment: Hi there, I am using python version 2.3.4. For some cases when using pindent.py with -c and -e option as follows, the variable "thisid" does not gets initialized before it hits line #310 ( current, firstkw, lastkw, topid = indent, thiskw, thiskw, thisid), this is traced all the way back to line #268 (for my case it fell in this else clause ... didn't try to look the exact scenario causing this) ... adding thisid = '' help fix the code for my scenario. If this fix is good for all scenario, please roll this over to main line code. Regards, Niraj ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:23 Message: Logged In: YES user_id=1188172 Fixed in CVS Tools/scripts/pindent.py r1.13, r1.12.12.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 23:32 Message: Logged In: YES user_id=31435 ann says that because rev 1.10 mechanically converted the whole file from tab indents to 4-space indents. I've never looked at this code, and never even used it. I care about reindent.py, but not pindent.py (it's Guido's baby, BTW). Unassigned myself. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 23:12 Message: Logged In: YES user_id=80475 Tim, cvs ann says this is your code. ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2004-11-25 03:50 Message: Logged In: YES user_id=1165734 I am running on solaris-8 and command I used is as follows: pindent.py -c -e This is for some special cases (I do not know, haven't digged into) and does not happen for all the mis-formatted files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 From noreply at sourceforge.net Sun Jun 26 22:34:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 13:34:43 -0700 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 11:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:34 Message: Logged In: YES user_id=1188172 Actually, your sys.stdout.encoding is set to something different than cp1250, which is why the result of DOS type looks the same as the one of print. This is because print observes sys.stdout.encoding, while sys.stdout.write uses the system default encoding, which is, as you set it, cp1250 and is displayed wrong on the console. Closing this bug, as it is currently expected behaviour (but will perhaps change when patch #1214889 is accepted). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:34 Message: Logged In: YES user_id=771873 Python 2.4.1 for Windows behaves the same way. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:26 Message: Logged In: YES user_id=771873 New observation: sys.stdout.write(s) behaves visually on the screen exactly as the raw_input(s) does. So, print does something more when displaying on the screen... Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Sun Jun 26 22:39:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 13:39:16 -0700 Subject: [ python-Bugs-1180237 ] Python keeps file references after calling close methode Message-ID: Bugs item #1180237, was opened at 2005-04-10 17:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180237&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Eelco (eternia) Assigned to: Nobody/Anonymous (nobody) Summary: Python keeps file references after calling close methode Initial Comment: I found this bug using a python script that: - first mounts a partition (os.system("mount") etc) - change a few files on this partition (f = open (); f.write; f.close) - umounts the partition (os.system("umount") etc) Strangely, the umount didn't work because of a filesystem busy error. Using fuser and lsof i traced this being busy back to the script itself. This is strange behavior because after changing the files on the mounted partition the close method was called which should close all references to the file on the partition. Finally the solution was to do f = 0. So if python has closed a file on a mount a open reference to that file will keep to exist until the script has ended or until the file object is nullified. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:39 Message: Logged In: YES user_id=1188172 I think so too and close this as Invalid. That the resources were freed when the file object was cleaned up shows that the submitter must have made a mistake since the destructor executes exactly the same code as close(). ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-06-26 22:01 Message: Logged In: YES user_id=971153 I also failed to reproduce the problem with a recent Python build on Debian (python session at the bottom) Suggest closing the bug. bagira:~/python> dist/src/python Python 2.5a0 (#18, Jun 2 2005, 17:12:48) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("mount /floppy") 0 >>> f=open("/floppy/test","w") >>> f.write('abcd') >>> f.close() >>> os.system('umount /floppy') 0 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-04-14 21:50 Message: Logged In: YES user_id=2772 I tried but can't reproduce this problem. After mounting a filesystem on /mnt/tmp, I ran the following in an interactive session: >>> f = open("/mnt/tmp/x", "w") >>> f.write("testing") >>> f.close() >>> import os; os.system("umount /mnt/tmp") 0 Did you write 'f.close()' or 'f.close'? The former closes the file, but the latter is a statement which has no effect. When you later executed 'f=0', the reference count of the-old-value-of-f dropped to 0 and the file was close()d impliclty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180237&group_id=5470 From noreply at sourceforge.net Sun Jun 26 22:55:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 13:55:42 -0700 Subject: [ python-Bugs-1066490 ] special methods become static Message-ID: Bugs item #1066490, was opened at 2004-11-15 07:46 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Michael Hudson (mwh) Summary: special methods become static Initial Comment: This *may* be a duplicate of 729913, but there's either additional info here, or this is actually different. The issue is that any special method (e.g. __call__, __str__, etc.) defined for a new-style (i.e. object-based) class seems to be static (i.e. unchangeable) with some special lookup applied for that method, but this doesn't seem to be the case for regular methods. class A: def foo(self): return 1 def __call__(self): return 2 def bar(self): return 3 def adjust(self): self.foo = self.bar self.__call__ = self.bar a = A() print a.foo(), a() a.adjust() print a.foo(), a() Will print: 1 2 3 3 But if the A is turned into a new-style class by changing the first line: class A(object): then the printed results are: 1 2 3 2 To the best of my understanding of the migration from classic classes to new-style classes (and metaclassing), this shouldn't occur. I have also tried various name munging for the special method (e.g. setting _B__call__, using setattr, etc.), but I haven't found the special trick yet. The attached script shows the example in more detail. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:55 Message: Logged In: YES user_id=1188172 It is not the case that the methods are unchangeable. See this example: class A(object): def __repr__(self): return 'repr' def new_repr(self): return 'new_repr' a = A() a.__repr__ = a.new_repr print a.__repr__() => prints "new_repr" print repr(a) => prints "repr" ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-12-22 20:00 Message: Logged In: YES user_id=6133 Thanks for the clarifcation. However IMHO it is wrong to have different behavior for different methods. To wit, if I defined a method, it is a bound method, and ergo a "self" initial argument is automatically supplied. However, a __repr__, even though I define it, acts as an unbound method, with the self argument having a default of the current instance but overrideable if an argument is supplied on the call. This means that the argument evaluation/passing is different for these types of builtins as opposed to other methods, both of which I have defined myself. This just doesn't seem right to me, which is why I'm re-opening this bug report... sorry to be annoying, but this definitely seems inconsistent and a better explanation. My current workaround is to do the following: class foo: def __str__(self): return my_str() def my_str(self): return 'something' So that I can do "foo.my_str = lambda self: return 'something else'". When what I should be able to do is: class foo: def __str__(self): return 'something' ... foo.__str__ = lambda self: return 'something else' ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 09:22 Message: Logged In: YES user_id=6656 Oh, sorry, I think I got that a bit wrong. The issue is more with bound/unbound methods -- given class O(object): def __repr__(self): ... should O.__repr__ be a bound method (O is an instance of type) or an unbound method so O.__repr__(O()) does what you expect? Python chooses the latter, but this means that you can't implement the builtin function repr as def repr(o): return o.__repr__() Hope this helps, a little at least. ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-11-15 15:29 Message: Logged In: YES user_id=6133 OK, I didn't find anything documenting this change anywhere (obviously). I read Guido's description of new-classes (www.python.org/2.2/descrintro.py) and the various documentation, but either I overlooked it therein or it's talked about somewhere else. I'm curious as to why special methods are treated specially in regards to this lookup. Specifically for your example, why wouldn't you just use the __repr__ attribute of o if it exists, instead of o's class, just like it does for non-special methods? Can you briefly explain this or provide me with a reference? Leaving this closed is OK with me since it's apparently known and expected... I'd just like to understand it a bit better. Sorry for the bandwidth, and Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 08:16 Message: Logged In: YES user_id=6656 The change you are observing is that special methods are now only looked up on the *class* of the object concerned. This, or something like this is actually unavoidable -- in >>> repr(o) what do you do if both o and the type of o define a __repr__ method? There are articles on new-style classes out there that should explain this in more depth. It probably could/should be documented better in the core -- there are bugs open to that effect already. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 From noreply at sourceforge.net Sun Jun 26 23:03:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 14:03:38 -0700 Subject: [ python-Bugs-1108948 ] Cookie.py produces invalid code Message-ID: Bugs item #1108948, was opened at 2005-01-25 10:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Cookie.py produces invalid code Initial Comment: The code in js_output in the Morsel class in Cookie.py produces invalid code, the scripting language should be specified by mimetype and not by language as per http://www.w3.org/TR/html401/interact/scripts.html also, the javascript line is missing an ending semi-colon attached a "patch" (new version of the function in question) present at least in 2.3 but still broken in current cvs A related matter: the existing documentation is poor, only after a substantial amount of code reading and googling I found out how to set attributes such as expires and path. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 23:03 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed as of Lib/Cookie.py r1.18. I do not backport this as some code might rely on the language HTML attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&group_id=5470 From noreply at sourceforge.net Sun Jun 26 23:13:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 14:13:04 -0700 Subject: [ python-Feature Requests-976880 ] mmap needs a rfind method Message-ID: Feature Requests item #976880, was opened at 2004-06-21 18:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=976880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Extension Modules >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: mmap needs a rfind method Initial Comment: It would be convenient to have an 'rfind' method equivalent to the string one; the only (slow, wasteful) alternative I can find is taking slices of the mmap, or using successive seek/read, followed by rindex. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 23:13 Message: Logged In: YES user_id=1188172 Moving to the RFE tracker. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 15:37 Message: Logged In: YES user_id=11375 The best way of seeing an rfind() method would be to implement it and submit a patch. (Otherwise it's a feature request, and processing bugs usually takes precendence over implementing features.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=976880&group_id=5470 From noreply at sourceforge.net Sun Jun 26 23:24:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 14:24:09 -0700 Subject: [ python-Bugs-1007046 ] os.startfile() doesn't accept Unicode filenames Message-ID: Bugs item #1007046, was opened at 2004-08-11 08:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Huening (huening) >Assigned to: Raymond Hettinger (rhettinger) Summary: os.startfile() doesn't accept Unicode filenames Initial Comment: WinXP, Python 2.3.4 os.startfile() seems to have problems with Unicode filenames. Example: >>> import tkFileDialog >>> import os >>> f = tkFileDialog.askopenfilename() >>> type(f) >>> os.startfile(f) Traceback (most recent call last): File "", line 1, in -toplevel- os.startfile(f) UnicodeEncodeError: 'ascii' codec can't encode characters in position 14-16: ordinal not in range(128) >>> ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 23:24 Message: Logged In: YES user_id=1188172 Attaching a patch which should fix that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 From noreply at sourceforge.net Sun Jun 26 23:35:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 14:35:00 -0700 Subject: [ python-Bugs-1100201 ] Cross-site scripting on BaseHTTPServer Message-ID: Bugs item #1100201, was opened at 2005-01-11 16:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Johnston (paj28) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Cross-site scripting on BaseHTTPServer Initial Comment: Hi, There is a minor XSS flaw in BaseHTTPServer, in the default error message, if you try connecting with a bad method name, e.g.: pugsley:/srv/www/htdocs # telnet risk 8000 Trying 192.168.3.52... Connected to risk. Escape character is '^]'. / HTTP/1.0 HTTP/1.0 501 Unsupported method ("") Server: SimpleHTTP/0.6 Python/2.3.4 Date: Tue, 11 Jan 2005 15:02:48 GMT Content-Type: text/html Connection: close Error response

Error response

Error code 501.

Message: Unsupported method ("").

Error code explanation: 501 = Server does not support this operation. Connection closed by foreign host. This is not likely to be a major security risk, but ideally it should be fixed. In addition it may be that other error messages exhibit this flaw, I haven't done a code audit. Credit for discovery: Richard Moore Best wishes, Paul ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 23:35 Message: Logged In: YES user_id=1188172 Thanks for the report. This is fixed as of Lib/BaseHTTPServer.py r1.30, r1.29.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&group_id=5470 From noreply at sourceforge.net Sun Jun 26 23:48:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 14:48:17 -0700 Subject: [ python-Bugs-1178145 ] urllib2.py assumes 206 is an error Message-ID: Bugs item #1178145, was opened at 2005-04-07 00:52 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.py assumes 206 is an error Initial Comment: I'm writting code that uses the Range header. The correct response is 206, but the urllib2.py is coded to treat any code that is not 200 as error. The correct code needs to treat 200 to 299 as success. The attached patch fixes the problem. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 23:48 Message: Logged In: YES user_id=1188172 It seems that jjlee is right. Closing as Fixed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:07 Message: Logged In: YES user_id=261020 Please close: this is already fixed in 2.4. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-04-08 18:17 Message: Logged In: YES user_id=764593 Please re-attach. SF didn't get the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:01:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:01:57 -0700 Subject: [ python-Bugs-1175848 ] poorly named variable in urllib2.py Message-ID: Bugs item #1175848, was opened at 2005-04-03 17:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Roy Smith (roysmith) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: poorly named variable in urllib2.py Initial Comment: This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local variable "server_version" is poorly named. The name makes it sound like it's the version of the HTTP (or whatever) server we're talking to. How about client_version or library_version or module_version? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:01 Message: Logged In: YES user_id=1188172 Fixed as of Lib/urllib2.py r1.82. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:10 Message: Logged In: YES user_id=261020 My, you're picky. ;-) Yes, that does seem a poor name, +1 on changing it to client_version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:07:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:07:35 -0700 Subject: [ python-Bugs-1155638 ] self.length shield exception in httplib Message-ID: Bugs item #1155638, was opened at 2005-03-03 08:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew P. Lentvorski, Jr. (bsder) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: self.length shield exception in httplib Initial Comment: Under certain conditions (I'm trying to open a Shoutcast stream), I wind up with the following exception from httplib: Traceback (most recent call last): File "/home/devel/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "avalanche.py", line 86, in run streamData = streamResponse.read(256) File "/home/devel/lib/python2.4/httplib.py", line 478, in read self.length -= len(s) TypeError: unsupported operand type(s) for -=: 'str' and 'int' Normally, self.length has many shields of the form "if self.length is None:"; however, self.length gets initialize to _UNKNOWN which is the string "UNKNOWN" rather than None. As such, all of the shields are useless. Am I using a deprecated library or something? I'm really surprised no one else has bumped into this. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:07 Message: Logged In: YES user_id=1188172 Thanks for the report! This is fixed as of Lib/httplib.py r1.95, r1.94.2.1. ---------------------------------------------------------------------- Comment By: Yusuke Shinyama (euske) Date: 2005-05-10 04:46 Message: Logged In: YES user_id=385990 I did bump into the same problem. Apparently when I got HTTP/0.9 connection, self.length is not initialized. Inserting a line into l.362 at httplib.py (v2.4) seems to solve this problem. I will also post a patch: if self.version == 9: self.chunked = 0 self.will_close = 1 self.msg = HTTPMessage(StringIO()) + self.length = None return ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:12:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:12:08 -0700 Subject: [ python-Bugs-1170279 ] BaseCookie does not call value_decode Message-ID: Bugs item #1170279, was opened at 2005-03-25 02:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Ryan Lovett (ryan) Assigned to: Nobody/Anonymous (nobody) Summary: BaseCookie does not call value_decode Initial Comment: Perhaps I'm misunderstanding its functionality, but I believe BaseCookie should be calling value_decode during __getitem__. I created a blowfish Cookie class with value_encode and value_decode methods, but when I invoke __getitem__, for example mycookie['mykey'], the cookie only returns encoded values. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:12 Message: Logged In: YES user_id=1188172 Duplicate of #1172011. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170279&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:24:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:24:02 -0700 Subject: [ python-Bugs-1172785 ] doctest.script_from_examples() result sometimes un-exec-able Message-ID: Bugs item #1172785, was opened at 2005-03-29 22:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jonathan E. Guyer (jguyer) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: doctest.script_from_examples() result sometimes un-exec-able Initial Comment: doctest.script_from_examples() can sometimes return results that cannot be passed to exec. The docstring for script_from_examples() itself is an example: guyer% python2.4 Python 2.4 (#1, Mar 10 2005, 18:08:38) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> text = ''' ... Here are examples of simple math. ... Python has super accurate integer addition ... >>> 2 + 2 ... 5 ... ... And very friendly error messages: ... ... >>> 1/0 ... To Infinity ... And ... Beyond ... ... You can use logic if you want: ... ... >>> if 0: ... ... blay ... ... blah ... ... ... ... Ho hum ... ''' >>> exec doctest.script_from_examples(text) Traceback (most recent call last): File "", line 1, in ? File "", line 21 # Ho hum ^ SyntaxError: invalid syntax The issue seems to be the lack of trailing '\n', which is documented as required by compile(), although not for exec. We never saw a problem with this in Python 2.3's doctest, probably because comment lines, such as "Ho hum", were stripped out and apparently adequate '\n' were appended. Python 2.4 on Mac OS X 10.3.8 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:24 Message: Logged In: YES user_id=1188172 Thanks for the report, this is fixed as of Lib/doctest.py r1.123, r1.120.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470 From noreply at sourceforge.net Mon Jun 27 00:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Jun 2005 15:32:52 -0700 Subject: [ python-Bugs-1058059 ] Can't read some http URLs using neither urllib, nor urllib2 Message-ID: Bugs item #1058059, was opened at 2004-11-01 11:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Vsevolod Novikov (nnseva) Assigned to: Nobody/Anonymous (nobody) Summary: Can't read some http URLs using neither urllib, nor urllib2 Initial Comment: HTTP connection maden by urllib, as well as by urllib2, on some URL sleeps forever (until timeout happens) on reading from the socket. The popular Linux 'wget' utility behaviour is the same. The Mozilla browser, as well as Internet Explorer browser read this URL successfully, over proxy, as well as directly. The example URL is: http://nds.nokia.com/uaprof/N3510ir100.xml The example code is: import urllib2 u = urllib2.urlopen('http://nds.nokia.com/uaprof/N3510ir100.xml') print u.info() print '-------------' for l in u : print l The urllib library does the same. Info list was (on the moment when I tried it last time): Accept-Ranges: bytes Date: Mon, 01 Nov 2004 10:29:58 GMT Content-Length: 9710 Content-Type: text/plain Cache-Control: no-cache Server: Netscape-Enterprise/4.1 X-WR-FLAGS: CCHOMode=7200:0:force Etag: "acbd4f76-6-25ee-40910c98" Last-modified: Thu, 29 Apr 2004 14:09:28 GMT Via: 1.1 saec-nokp02ca (NetCache NetApp/5.3.1R2) I have no idea why it happens. May be, the HTTP server waits some additional headers? In any case, it is not a good behaviour of the library, I think. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-27 00:32 Message: Logged In: YES user_id=1188172 I can't reproduce it too, with 2.4 and 2.5 CVS. If, as OP says, wget shows this behaviour too, it's likely that it was a bug in his OS's libraries. Closing as Invalid. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-08 14:03 Message: Logged In: YES user_id=1038590 I can't reproduce it either - Windows XP, Cygwin build of Python 2.4 CVS as of a day or two ago. OP needs to provide Python and OS version info - it may be a platform problem, or a problem with an early version of Python 2.3 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-11-01 14:37 Message: Logged In: YES user_id=89016 Work here without any problems: Python 2.3.4 (#2, Sep 29 2004, 18:56:11) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> d = urllib.urlopen ("http://nds.nokia.com/uaprof/N3510ir100.xml").read() >>> len(d) 9710 >>> d[:30] '\n