From noreply at sourceforge.net Thu Sep 1 00:04:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:04:23 -0700 Subject: [ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle Message-ID: Bugs item #750328, was opened at 2003-06-06 23:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 Please note that this 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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle fails to restore new-style class instance in a cycle Initial Comment: Here is code to demonstrate the problem. All asserts succeed except the last, showing that pickle and cPickle both handle a "classic" cycle correctly, but only cPickle handles new-style cycles correctly. It would appear that the problem is that the pure-Python pickle isn't putting the object into its 'memo' until *after* the object's state has been pickled. Thus, the identity is not preserved on unpickling. This may be true for other object types that use __reduce__, but I have not verified this. import pickle, cPickle class X: pass x = X() x.x = x x2 = cPickle.loads(cPickle.dumps(x)) assert x2.x is x2 x2 = pickle.loads(pickle.dumps(x)) assert x2.x is x2 class Y(object): pass y = Y() y.y = y y2 = cPickle.loads(cPickle.dumps(y)) assert y2.y is y2 # this fails y2 = pickle.loads(pickle.dumps(y)) assert y2.y is y2 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:04 Message: Logged In: YES user_id=1188172 Runs find in 2.5cvs too. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:34 Message: Logged In: YES user_id=1188172 Runs fine in Py2.4.1 too, so should it be considered fixed? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 05:00 Message: Logged In: YES user_id=80475 Another datapoint: This above script runs fine in Py2.3b2. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-06-08 22:23 Message: Logged In: YES user_id=666873 Compare bug 702858, which observes the same behaviour for copy.deepcopy. The common parts of pickle and copy really ought to be merged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:05:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:05:28 -0700 Subject: [ python-Bugs-763007 ] dl module not installed with 2.2.3 Message-ID: Bugs item #763007, was opened at 2003-06-30 07:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 Please note that this 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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Mike Messmore (salmo) Assigned to: Nobody/Anonymous (nobody) Summary: dl module not installed with 2.2.3 Initial Comment: I'm running Redhat 7.3 on an older PII. I was attemping to try out the python bindings for gstreamer when I discovered my build of python 2.2.3 was lacking the 'dl' module. I've installed RPMS built from the SRPMS available on the python.org site (with the non-redhat9 spec file). Looking around I have not found a reason for this, nor a way to go about fixing it, so I assume it is a bug. Whenever I try to run a gst-python example I get an ImportError stating the the dl module does not exist, as well as when I try to run test_dl.py in my /usr/lib/python2.2/test/ directory. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:05 Message: Logged In: YES user_id=1188172 Considered as out of date. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:36 Message: Logged In: YES user_id=1188172 Is this still an issue? The group is Python 2.2.3, so should it be considered out of date? ---------------------------------------------------------------------- Comment By: Mike Messmore (salmo) Date: 2003-07-01 07:31 Message: Logged In: YES user_id=121084 >From the output it seems to never try to compile dlmodule.c. I ran 'rpm --rebuild python2-2.2.3-1.src.rpm 2&>1 >python_build.txt' and grepped the resulting text for dlmodule.c and only found it placing the file in the build directory. It found dlfcn.h fine. If you need me to I can attach the python_build.txt file here, but I can't find any visable errors in the building process. By the way, feel free to let me know at any point if I'm doing something retarded. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 17:22 Message: Logged In: YES user_id=33168 What is the error when building dlmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 From noreply at sourceforge.net Thu Sep 1 00:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:09:18 -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: Closed >Resolution: Accepted 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-09-01 00:09 Message: Logged In: YES user_id=1188172 Checked in as Lib/HTMLParser.py r1.16, 1.15.2.1. ---------------------------------------------------------------------- Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 22: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 22: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 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 Thu Sep 1 00:11:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:11: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 21:59 Message generated for change (Comment added) made by niemeyer 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: Gustavo Niemeyer (niemeyer) Date: 2005-08-31 22:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 21:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 19: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 18: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 18: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 15: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 08: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 11: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 21: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 21: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 20: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 20: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 16: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 Sep 1 00:16:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:16:19 -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-09-01 00:16 Message: Logged In: YES user_id=1188172 No, you're the expert, so you'll get the honor of fixing it. :P ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-01 00:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- 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 Thu Sep 1 00:17:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 15:17:27 -0700 Subject: [ python-Bugs-1276587 ] dict('') doesn't raise a value error Message-ID: Bugs item #1276587, was opened at 2005-08-30 14:52 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470 Please note that this message 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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: dict('') doesn't raise a value error Initial Comment: The dict function will theoretically accept any sequence or bounded iterable that yields (key, value) tuples. A side effect is that dict('') is valid - producing an emtpy dictionary. dict(x) where x is *any* string other than '' fails with a ValueError. I suggest that dict('') ought to produce a ValueError to as a string is *never* a valid input to the dict function. The current situation allows obscure errors to pass unnoticed. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:17 Message: Logged In: YES user_id=1188172 Closing as Won't Fix, then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-30 16:39 Message: Logged In: YES user_id=31435 It's not theoretical: it's a fact that dict() accepts any iterable producing iterables each producing 2 objects (the latter don't have to be tuples; a (key, value) tuple is just one kind of iterable producing 2 objects; e.g., dict(["ab"]) == {'a': 'b'}). An empty str meets the input requirements, so there's no way to stop this without special-case type-sniffing. That's very unattractive, in part because it's impossible to guess which kinds of empty iterables would necessarily lead to an exception when passed to dict() had they not been empty. For example, passing an empty array.array (of any flavor) to dict() also constructs an empty dict. The universe of iterable objects is vast. Keeping it uniform and easy to explain (an empty iterable produces an empty dict) seems better to me than adding a maze of special cases that's bound to change over time ("except for an empty str" ... "oh, or an empty unicode" ... "oh, or an empty array.array" ... "oh, or an empty file" ... "oh, oops, guess not, cuz a file with two lines works fine" ... etc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470 From noreply at sourceforge.net Thu Sep 1 06:49:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 21:49:28 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 23: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=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Nobody/Anonymous (nobody) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Thu Sep 1 08:37:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 23:37:20 -0700 Subject: [ python-Bugs-1278102 ] help() broken, especially on Windows Message-ID: Bugs item #1278102, was opened at 2005-08-31 23: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=1278102&group_id=5470 Please note that this message will contain 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: Bryan G. Olson (bryango) Assigned to: Nobody/Anonymous (nobody) Summary: help() broken, especially on Windows Initial Comment: The for loop that pydoc.Helper's __init__ uses to find the location of Python docs doesn't work. It will reject the standard setting of 'http://www.python.org/doc/current/lib/'. Also, the loop should probably break after setting self.docdir. On Windows, setting PYTHONDOCS to the installation's doc directory will not make it work, because the doc is now distributed as a single file, 'Python24.chm', so there is no 'lib' sub-directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&group_id=5470 From noreply at sourceforge.net Thu Sep 1 10:27:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 01:27:58 -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 lemburg 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: M.-A. Lemburg (lemburg) Date: 2005-09-01 10:27 Message: Logged In: YES user_id=38388 The path looks OK, but I can't test it on Windows (os.startfile() is only available on Windows). A note on style: you should always try to keep lines shorter than 80 characters, e.g.: --- CVS-Python/Modules/posixmodule.c 2005-08-15 10:15:27.000000000 +0200 +++ Dev-Python/Modules/posixmodule.c 2005-09-01 10:23:06.555633134 +0200 @@ -7248,7 +7248,8 @@ { char *filepath; HINSTANCE rc; - if (!PyArg_ParseTuple(args, "s:startfile", &filepath)) + if (!PyArg_ParseTuple(args, "et:startfile", + Py_FileSystemDefaultEncoding, &filepath)) return NULL; Py_BEGIN_ALLOW_THREADS rc = ShellExecute((HWND)0, NULL, filepath, NULL, NULL, SW_SHOWNORMAL); ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 07:18 Message: Logged In: YES user_id=80475 I'm unicode illiterate. Passing to MAL for review. ---------------------------------------------------------------------- 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 Thu Sep 1 11:07:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 02:07:54 -0700 Subject: [ python-Bugs-1278102 ] help() broken, especially on Windows Message-ID: Bugs item #1278102, was opened at 2005-09-01 08:37 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&group_id=5470 Please note that this message will contain 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: Bryan G. Olson (bryango) >Assigned to: Ka-Ping Yee (ping) Summary: help() broken, especially on Windows Initial Comment: The for loop that pydoc.Helper's __init__ uses to find the location of Python docs doesn't work. It will reject the standard setting of 'http://www.python.org/doc/current/lib/'. Also, the loop should probably break after setting self.docdir. On Windows, setting PYTHONDOCS to the installation's doc directory will not make it work, because the doc is now distributed as a single file, 'Python24.chm', so there is no 'lib' sub-directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278102&group_id=5470 From noreply at sourceforge.net Thu Sep 1 12:56:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 03:56:47 -0700 Subject: [ python-Feature Requests-853698 ] pythonw.exe should not flash DOS windows Message-ID: Feature Requests item #853698, was opened at 2003-12-04 00:49 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=853698&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Amir Helzer (eehelzer) Assigned to: Nobody/Anonymous (nobody) Summary: pythonw.exe should not flash DOS windows Initial Comment: Python version 2.3. I'm using pythonw (and py2exe) to build a windows application. When new processes are launched, using os.system() or os.spawn a DOS windows flashes for a moment and then vanishes. It makes the application look funny. When the same application is run via python (and not pythonw) this doesn't happen. New processes don't create a flashing DOS window. It would be nice if pythonw.exe could function similar to python.exe, just without the constant DOS window in the background. The same behavior occures when running the program via pythonw.exe <fname.py> or when compiling with py2exe -w. Amir ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 12:56 Message: Logged In: YES user_id=1188172 Closing as Won't Fix, then. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-18 11:04 Message: Logged In: YES user_id=21627 The "flashing window" is created by the Microsoft C library, in its system() and spawn() implementations. If you don't want that window, you need to use CreateProcess instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=853698&group_id=5470 From noreply at sourceforge.net Thu Sep 1 13:55:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 04:55:44 -0700 Subject: [ python-Bugs-1278906 ] invalid syntax in os.walk() first example Message-ID: Bugs item #1278906, was opened at 2005-09-01 13:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 Please note that this 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: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: invalid syntax in os.walk() first example Initial Comment: Hi! The first example code block in the documentation for os.walk() has invalid syntax in it. The docs are available here: http://www.python.org/doc/current/lib/os-file-dir.html#l2h-1466 This is the example code block: import os from os.path import join, getsize for root, dirs, files in os.walk('python/Lib/email'): print root, "consumes", print sum(getsize(join(root, name)) for name in files), print "bytes in", len(files), "non-directory files" if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories Line 5 has the the invalid syntax: print sum(getsize(join(root, name)) for name in files), The example works if brackets are added like so: print sum([getsize(join(root, name)) for name in files]), I recommend that someone responsible should make this update in the docs. You guys are brilliant. Thanks for a splendid language with docs to match! Cheers! /Joel Hedlund PhD student, IFM Bioinfomatics, Link?ping University ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 From noreply at sourceforge.net Thu Sep 1 14:22:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 05:22:33 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Thu Sep 1 14:44:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 05:44:57 -0700 Subject: [ python-Bugs-1278906 ] invalid syntax in os.walk() first example Message-ID: Bugs item #1278906, was opened at 2005-09-01 06:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: invalid syntax in os.walk() first example Initial Comment: Hi! The first example code block in the documentation for os.walk() has invalid syntax in it. The docs are available here: http://www.python.org/doc/current/lib/os-file-dir.html#l2h-1466 This is the example code block: import os from os.path import join, getsize for root, dirs, files in os.walk('python/Lib/email'): print root, "consumes", print sum(getsize(join(root, name)) for name in files), print "bytes in", len(files), "non-directory files" if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories Line 5 has the the invalid syntax: print sum(getsize(join(root, name)) for name in files), The example works if brackets are added like so: print sum([getsize(join(root, name)) for name in files]), I recommend that someone responsible should make this update in the docs. You guys are brilliant. Thanks for a splendid language with docs to match! Cheers! /Joel Hedlund PhD student, IFM Bioinfomatics, Link?ping University ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 07:44 Message: Logged In: YES user_id=80475 I suspect you are using Py2.4 documentation while running Py2.3 or earlier. In Py2.4, the bracketless syntax was introduced with new semantics which produce a similar result but run with a generator instead of a list comprehension, resulting in a significant savings in memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 From noreply at sourceforge.net Thu Sep 1 14:54:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 05:54:48 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 23:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) >Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 07:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Thu Sep 1 14:57:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 05:57:35 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 04:34 Message generated for change (Comment added) made by cmobarry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_pwd fails on 64bit system (Opteron) Initial Comment: test test_pwd failed -- Traceback (most recent call last): File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum $ cat /proc/version Linux version 2.4.21-20.ELsmp (bhcompile at dolly.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18 20:34:58 EDT 2004 Processor is AMD Opteron 2.4MHz ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-09-01 08:57 Message: Logged In: YES user_id=1035073 The suggested patch by heffler worked brilliantly for my 64 bit environment. Thanks. My bug submission was on 2005-08-03 14:40. ---------------------------------------------------------------------- Comment By: Marvin Heffler (heffler) Date: 2005-08-11 14:19 Message: Logged In: YES user_id=298758 I think I figued out the problem with python handling uids and gids greater than 2147483647 when using the grp.getgrgid and pwd.getpwuid functions. Both of the functions call PyArg_ParseTuple with a type of "i", thus indicating the argument is a signed integer. Instead they should be using "I" (upper-case i) for an unsigned integer. The fix is fairly simple. Here are the two patches necessary to the python source: diff -Naur Python-2.4.orig/Modules/grpmodule.c Python- 2.4/Modules/grpmodule.c --- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 16:06:00.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -0400 @@ -87,7 +87,7 @@ { int gid; struct group *p; - if (!PyArg_ParseTuple(args, "i:getgrgid", &gid)) + if (!PyArg_ParseTuple(args, "I:getgrgid", &gid)) return NULL; if ((p = getgrgid(gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python- 2.4/Modules/pwdmodule.c --- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 16:07:23.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -0400 @@ -104,7 +104,7 @@ { int uid; struct passwd *p; - if (!PyArg_ParseTuple(args, "i:getpwuid", &uid)) + if (!PyArg_ParseTuple(args, "I:getpwuid", &uid)) return NULL; if ((p = getpwuid(uid)) == NULL) { PyErr_Format(PyExc_KeyError, Hopefully, someone from the python project can verify my patch and get it incorporated into a future release. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-08-03 14:40 Message: Logged In: YES user_id=1035073 The same error occurs for an Intel P4-521 processor running RedHat Enterprise Linux WS v4 Intel EM64T 64bit. $ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005 test test_grp failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum test test_pwd failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-03-17 04:20 Message: Logged In: YES user_id=358087 I've tried the patch - no luck :-( I'm stealing time on these machines since they belong to another group. However I see that SF's compile farm (http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) have an AMD64 host (amd64-linux1) Maybe you can shorten the loop ... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 17:17 Message: Logged In: YES user_id=89016 On a 32bit system adding the line nobody:x:4294967294:65534:nobody:/:/bin/false to /etc/passwd pwd.getpwall() gives me an entry: ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') and pwd.getpwuid(-2) gives me ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') Maybe for 64bit systems the SETI macro should use PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can you try the following patch? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-17 03:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-16 20:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 04:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Thu Sep 1 16:15:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 07:15:12 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 Please note that this message 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: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-31 08:50 Message: Logged In: YES user_id=133955 > Those two answers suggest this RFE is unnecessary. If you > guys agree, please close. If not, I'll ponder it further. > Right now, I'm disinclined to introduce a method that I > think is awkward to use. Well, closing the request is fine for me. Although I don't think choose() would be very awkward to use, we can probably live without it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 15:06 Message: Logged In: YES user_id=80475 For the record, here are some research results. Java's set objects do not have a choose() method: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html In contrast, SETL does provide a function for extracting arbitrary elements. The empty set case is handled by returning Om which is a singleton object guaranteed not to be an element of any set. The Om value is especially useful in SETL because it can be passed upward through other functions (much in the same way that NANs can trickle through a calculation without killing it). Python has no equivalent of Om. http://www.cs.nyu.edu/~bacon/setl-doc.html#arb Core Perl only has arrays and hashes. Mathematica provides set operations on lists (union, intersection, complement). Rather than having a set specific function for extraction, list functions are used. The one providing choose-like functionality is First(). It is equivalent to indexing: a[0] http://documents.wolfram.com/mathematica/functions/First ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 06:47 Message: Logged In: YES user_id=80475 > > Question for everyone: Is there any known application for > > choose() that isn't met by pop()/add() irrespective of > > whether it "feels right"? [Antoine] > I don't think so indeed. [mwh] > Mmm, the "v, = s" approach hadn't occurred to me and it > seems ok. Those two answers suggest this RFE is unnecessary. If you guys agree, please close. If not, I'll ponder it further. Right now, I'm disinclined to introduce a method that I think is awkward to use. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-30 02:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need"). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 18:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 17:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 15:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 14:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 14:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 13:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 12:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Thu Sep 1 18:00:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 09:00:20 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 22:49 Message generated for change (Comment added) made by alenlpeacock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- Comment By: Alen Peacock (alenlpeacock) Date: 2005-09-01 10:00 Message: Logged In: YES user_id=1239721 I'm attaching a minimal program that demonstrates the behavior. You'll need twisted installed to run it. I've tested on python 2.4.1 and 2.4.14, both produce the error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 06:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Thu Sep 1 18:04:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 09:04:33 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 23:49 Message generated for change (Comment added) made by alengarbage You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- >Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 11:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Alen Peacock (alenlpeacock) Date: 2005-09-01 11:00 Message: Logged In: YES user_id=1239721 I'm attaching a minimal program that demonstrates the behavior. You'll need twisted installed to run it. I've tested on python 2.4.1 and 2.4.14, both produce the error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 07:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Thu Sep 1 18:04:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 09:04:46 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 23:49 Message generated for change (Comment added) made by alengarbage You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- >Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 11:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 11:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Alen Peacock (alenlpeacock) Date: 2005-09-01 11:00 Message: Logged In: YES user_id=1239721 I'm attaching a minimal program that demonstrates the behavior. You'll need twisted installed to run it. I've tested on python 2.4.1 and 2.4.14, both produce the error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 07:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Thu Sep 1 20:28:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 11:28:46 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 20:28 Message: Logged In: YES user_id=38388 Thanks, Walter. StreamRecorder is not broken: it works as advertised (see the .__init__() doc-string and interface) and yes, this means that only stateless encodings can be used, such as e.g. UTF-16-LE, simply because the encode and decode functions are defined as being stateless. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Thu Sep 1 22:06:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 13:06:07 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13: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=1280061&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Thu Sep 1 22:35:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 13:35:53 -0700 Subject: [ python-Bugs-1267884 ] crash recursive __getattr__ Message-ID: Bugs item #1267884, was opened at 2005-08-24 06:22 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 Please note that this message 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: Duplicate Priority: 5 Submitted By: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: ------------8<------------- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) ------------8<------------- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:35 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 From noreply at sourceforge.net Thu Sep 1 22:37:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 13:37:21 -0700 Subject: [ python-Bugs-1267884 ] crash recursive __getattr__ Message-ID: Bugs item #1267884, was opened at 2005-08-24 06:22 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 Please note that this message 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: Duplicate Priority: 5 Submitted By: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: ------------8<------------- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) ------------8<------------- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:37 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding a cross-reference note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:35 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 From noreply at sourceforge.net Thu Sep 1 22:39:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 13:39:26 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 19:43 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message 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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 16:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 08:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 09:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 09:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 09:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 03:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 17:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 17:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 11:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 22:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Thu Sep 1 23:38:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 14:38:13 -0700 Subject: [ python-Bugs-1277718 ] Lambda and deepcopy Message-ID: Bugs item #1277718, was opened at 2005-08-31 16:10 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: Lambda and deepcopy Initial Comment: Howdy -- I have a class that has an attribute that is a dictionary that contains an object that has a kword argument that is a lambda. Confused yet? Simplified example: import copy class Foo: def __init__(self, fn=None): self.fn = fn class Bar: d = {'foobar': Foo(fn=lambda x: x*x)} def cp(self): self.xerox = copy.deepcopy(self.d) When I execute: b = Bar() b.cp() Using Python version: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin I get: Traceback (most recent call last): File "", line 1, in ? File "", line 5, in cp File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 270, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 307, in _deepcopy_inst state = deepcopy(state, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 270, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 206, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 338, in _reconstruct y = callable(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py", line 92, in __newobj__ return cls.__new__(cls, *args) TypeError: function() takes at least 2 arguments (0 given) I've googled for deepcopy and lambda and found somebody else asking the same question on a LUG somewhere, but they gave no advice and nobody else seems to have run into this. Any ideas on what the problem is/how to get around it? Thanks! -jag ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 17:38 Message: Logged In: YES user_id=593130 Python does not have lambdas. It has functions. Among other ways, they can be produced by lambda expressions. The *only* residue of lambda origin is the otherwise invalid .func_name ''. General bug-seeking advice: 1. If you can, upgrade to at least 2.3.5, the last 2.3 series release, with its several bug fixes. 2. If at all possible, test code with the lastest release. Each release has numerous bug fixes. (But not needed here.) 3. Reduce code to the minimum needed to get the apparent buggy behavior. You code is mostly noise for this purpose. I believe copy.deepcopy(lambda x: x) would be sufficient to get an exception. 4. Read (or reread) the manual for the modules and methods giving you trouble. From http://docs.python.org/lib/module-copy.html and from http://www.python.org/doc/2.3/lib/module-copy.html: "This version does not copy types like module, class, function..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470 From noreply at sourceforge.net Fri Sep 2 00:29:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 15:29:48 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-08-31 23:49 Message generated for change (Comment added) made by alengarbage You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- >Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 17:29 Message: Logged In: YES user_id=1338323 Here's an even more minimal snippet of code that produces the error. Nothing but a logger and a thread. No need for twisted anything. Ignore the previous example. Does this code do something to abuse the logging facility? ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 11:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 11:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Alen Peacock (alenlpeacock) Date: 2005-09-01 11:00 Message: Logged In: YES user_id=1239721 I'm attaching a minimal program that demonstrates the behavior. You'll need twisted installed to run it. I've tested on python 2.4.1 and 2.4.14, both produce the error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 07:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Fri Sep 2 02:04:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Sep 2005 17:04:54 -0700 Subject: [ python-Bugs-761452 ] HTMLParser chokes on my.yahoo.com output Message-ID: Bugs item #761452, was opened at 2003-06-26 21:11 Message generated for change (Comment added) made by tmick 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: Closed Resolution: Accepted 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: Trent Mick (tmick) Date: 2005-09-02 00:04 Message: Logged In: YES user_id=34892 ...and subsequently backed out in r1.15.2.2 and r1.17. Reverting previous checkin. This breaks too much of HTMLParser to be applied without thought. Anyway, such malformed HTML is better handled by something like BeautifulSoup. Apologies, Reinhold, if you were getting to this. I just happened to notice this while reading python-checkins. Cheers. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 22:09 Message: Logged In: YES user_id=1188172 Checked in as Lib/HTMLParser.py r1.16, 1.15.2.1. ---------------------------------------------------------------------- Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 20: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 20: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 12:24 Message: Logged In: YES user_id=1188172 Should it be applied, then? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 15: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 02: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 Fri Sep 2 10:43:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 01:43:40 -0700 Subject: [ python-Bugs-1278906 ] invalid syntax in os.walk() first example Message-ID: Bugs item #1278906, was opened at 2005-09-01 13:55 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: invalid syntax in os.walk() first example Initial Comment: Hi! The first example code block in the documentation for os.walk() has invalid syntax in it. The docs are available here: http://www.python.org/doc/current/lib/os-file-dir.html#l2h-1466 This is the example code block: import os from os.path import join, getsize for root, dirs, files in os.walk('python/Lib/email'): print root, "consumes", print sum(getsize(join(root, name)) for name in files), print "bytes in", len(files), "non-directory files" if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories Line 5 has the the invalid syntax: print sum(getsize(join(root, name)) for name in files), The example works if brackets are added like so: print sum([getsize(join(root, name)) for name in files]), I recommend that someone responsible should make this update in the docs. You guys are brilliant. Thanks for a splendid language with docs to match! Cheers! /Joel Hedlund PhD student, IFM Bioinfomatics, Link?ping University ---------------------------------------------------------------------- >Comment By: YoHell (yohell) Date: 2005-09-02 10:43 Message: Logged In: YES user_id=1008220 Yes, you are very correct. ;-) Can I suggest putting a note on the updated syntax somewhere in the vicinity? Thanks again! /Joel ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 14:44 Message: Logged In: YES user_id=80475 I suspect you are using Py2.4 documentation while running Py2.3 or earlier. In Py2.4, the bracketless syntax was introduced with new semantics which produce a similar result but run with a generator instead of a list comprehension, resulting in a significant savings in memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1278906&group_id=5470 From noreply at sourceforge.net Fri Sep 2 11:40:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 02:40:44 -0700 Subject: [ python-Bugs-1267884 ] crash recursive __getattr__ Message-ID: Bugs item #1267884, was opened at 2005-08-24 10:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 Please note that this message 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: Duplicate Priority: 5 Submitted By: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: ------------8<------------- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) ------------8<------------- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-02 09:40 Message: Logged In: YES user_id=4771 This is indeed a bug similar to 1202533: the infinite recursion is in C, and doesn't go through the user-defined __getattr__(). The sample code snippet is definitely strange: it mixes object.__getattribute__() with an old-style class, i.e. one that doesn't inherit from 'object'. This code would work as expected if C were inheriting from 'object'. Instead, what occurs in this crash is that the __str__ of InstanceType calls __getattr__, which calls object.__getattribute__(c, '__str__'); the latter returns a so-called method wrapper object, which means essentially a method object bound to a C function. In this case the C function is again the __str__ of InstanceType. So this __str__ ends up calling itself infinitely. A more direct way to expose the bug is: from types import * class C: __str__ = InstanceType.__str__ str(C()) Clearly, all special methods are affected: class C: __add__ = InstanceType.__add__ C()+1 It should be fixed together with [ 1202533 ], if the latter is ever fixed. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:37 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding a cross-reference note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:35 Message: Logged In: YES user_id=593130 I believe this is essentially the same as open bug [ 1202533 ] a bunch of infinite C recursions Closing as duplicate and adding note to 1202533. Reopen if a fix to the above, if and when there is one, does not fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 From noreply at sourceforge.net Fri Sep 2 12:05:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 03:05:48 -0700 Subject: [ python-Bugs-1277903 ] logging module broken for multiple threads? Message-ID: Bugs item #1277903, was opened at 2005-09-01 04:49 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Lenny G. Arbage (alengarbage) Assigned to: Vinay Sajip (vsajip) Summary: logging module broken for multiple threads? Initial Comment: After upgrading from python 2.2, I noticed that the logging facility doesn't seem to work in my code anymore. As far as I can tell, after spending a bit of time isolating the problem, this is an issue with threading. In the main thread, logging works without a hitch. In the secondary thread (which is run via twisted.reactor), any attempt to write to the log results in: Traceback (most recent call last): File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit self.stream.write(fs % msg) ValueError: I/O operation on closed file The code that initializes the logger is as follows: logger = logging.getLogger('mylogger') screenhandler = logging.StreamHandler() screenhandler.setLevel(logging.INFO) logger.addHandler(self.screenhandler) logfile = "/tmp/testlog" if os.path.isfile(logfile): os.remove(logfile) handler = logging.FileHandler(logfile) formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(logging.INFO) Alone, this works fine. It is only when a the second thread does a 'logger = logging.getLogger('mylogger') and subsequently calls 'logger.log()' that the above error is produced. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-02 10:05 Message: Logged In: YES user_id=308438 The problem is occurring because the main thread exits, which causes shutdown of the logging system via an atexit hook. If you add either of the following lines at the end of your __name__ == "__main__" clause: raw_input("Press a key:") or mythread.join() Then the thread continues to run: 2005-09-02 10:23:37,023 2564 INFO: logging initialized 2005-09-02 10:23:37,023 2564 INFO: initializing MyThread 2005-09-02 10:23:37,023 2564 INFO: test (before starting thread) 2005-09-02 10:23:37,032 2220 INFO: MyThread starting 2005-09-02 10:23:37,032 2564 INFO: test (after starting thread) 2005-09-02 10:23:37,032 2220 INFO: MyThread ticking... 2005-09-02 10:23:39,036 2220 INFO: MyThread ticking... 2005-09-02 10:23:41,039 2220 INFO: MyThread ticking... 2005-09-02 10:23:43,042 2220 INFO: MyThread ticking... 2005-09-02 10:23:45,045 2220 INFO: MyThread ticking... 2005-09-02 10:23:47,048 2220 INFO: MyThread ticking... (I modified the format string to show the thread ID in the logged message). Hence, this is not a bug and I am closing this entry as "Invalid". ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 22:29 Message: Logged In: YES user_id=1338323 Here's an even more minimal snippet of code that produces the error. Nothing but a logger and a thread. No need for twisted anything. Ignore the previous example. Does this code do something to abuse the logging facility? ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 16:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Lenny G. Arbage (alengarbage) Date: 2005-09-01 16:04 Message: Logged In: YES user_id=1338323 file attached ---------------------------------------------------------------------- Comment By: Alen Peacock (alenlpeacock) Date: 2005-09-01 16:00 Message: Logged In: YES user_id=1239721 I'm attaching a minimal program that demonstrates the behavior. You'll need twisted installed to run it. I've tested on python 2.4.1 and 2.4.14, both produce the error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-01 12:54 Message: Logged In: YES user_id=80475 It looks to me like you've created a race condition that became evident only when switching Python versions. Assigning to Vijay so he can give advice on the best way to code this (most likely by moving resource competing calls to the main thread). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277903&group_id=5470 From noreply at sourceforge.net Fri Sep 2 13:01:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 04:01:47 -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: Closed >Resolution: Wont Fix 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-09-02 13:01 Message: Logged In: YES user_id=1188172 Yes, thanks for noting, it was still on my todo list... ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2005-09-02 02:04 Message: Logged In: YES user_id=34892 ...and subsequently backed out in r1.15.2.2 and r1.17. Reverting previous checkin. This breaks too much of HTMLParser to be applied without thought. Anyway, such malformed HTML is better handled by something like BeautifulSoup. Apologies, Reinhold, if you were getting to this. I just happened to notice this while reading python-checkins. Cheers. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:09 Message: Logged In: YES user_id=1188172 Checked in as Lib/HTMLParser.py r1.16, 1.15.2.1. ---------------------------------------------------------------------- Comment By: Robert Walsh (rjwalsh) Date: 2005-06-01 22: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 22: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 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 Fri Sep 2 14:10:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 05:10:51 -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 (Settings changed) made by arigo 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)) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-02 12:10 Message: Logged In: YES user_id=4771 Reopening this bug report: this might fix the problem at hand, but it breaks inspect.getsource() on cases where it used to work. See attached example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 07: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 Fri Sep 2 14:40:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 05:40:08 -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 (Comment added) made by arigo 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)) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-02 12:40 Message: Logged In: YES user_id=4771 Here is a proposed patch. It relaxes the dedent policy a bit. It assumes that the first line may already have some initial indentation, as is the case when tokenizing from the middle of a file (as inspect.getsource() does). It should also be back-ported to 2.4, given that the previous patch was. For 2.4, only the non-test part of the patch applies cleanly; I suggest to ignore the test part and just apply it, given that there are much more tests in 2.5 for inspect.getsource() anyway. The whole issue of inspect.getsource() being muddy anyway, I will go ahead and check this patch in unless someone spots a problem. For now the previously-applied patch makes parts of PyPy break with an uncaught IndentationError. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 12:10 Message: Logged In: YES user_id=4771 Reopening this bug report: this might fix the problem at hand, but it breaks inspect.getsource() on cases where it used to work. See attached example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 07: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 Fri Sep 2 14:50:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 05:50:42 -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: 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)) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 07:40 Message: Logged In: YES user_id=4771 Here is a proposed patch. It relaxes the dedent policy a bit. It assumes that the first line may already have some initial indentation, as is the case when tokenizing from the middle of a file (as inspect.getsource() does). It should also be back-ported to 2.4, given that the previous patch was. For 2.4, only the non-test part of the patch applies cleanly; I suggest to ignore the test part and just apply it, given that there are much more tests in 2.5 for inspect.getsource() anyway. The whole issue of inspect.getsource() being muddy anyway, I will go ahead and check this patch in unless someone spots a problem. For now the previously-applied patch makes parts of PyPy break with an uncaught IndentationError. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 07:10 Message: Logged In: YES user_id=4771 Reopening this bug report: this might fix the problem at hand, but it breaks inspect.getsource() on cases where it used to work. See attached example. ---------------------------------------------------------------------- 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 Fri Sep 2 18:43:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 09:43:17 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13:06 Message generated for change (Comment added) made by meonkeys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- >Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 09:43 Message: Logged In: YES user_id=259388 Here's a simpler, more precise test case (also attached): import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'; format = '%B' time.strptime(date, format) Here's the error I see: Traceback (most recent call last): File "de_strptime_fail_simple.py", line 4, in ? time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 329, in strptime month = locale_time.f_month.index(found_dict['B'].lower()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Fri Sep 2 20:33:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 11:33:54 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-09-02 20:33 Message: Logged In: YES user_id=89016 OK, now I'm beginning to understand the docstring. Nevertheless I think having a class that uses stateful codecs at both ends would be useful. If you want, I can give this a try (after I'm back from vactation in four weeks). Closing the report as fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 20:28 Message: Logged In: YES user_id=38388 Thanks, Walter. StreamRecorder is not broken: it works as advertised (see the .__init__() doc-string and interface) and yes, this means that only stateless encodings can be used, such as e.g. UTF-16-LE, simply because the encode and decode functions are defined as being stateless. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Fri Sep 2 21:14:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 12:14:05 -0700 Subject: [ python-Bugs-1280924 ] PyDateTime_Check references static object Message-ID: Bugs item #1280924, was opened at 2005-09-02 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280924&group_id=5470 Please note that this message will contain 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: PyDateTime_Check references static object Initial Comment: In trying to use the C API for datetime objects, we noticed that PyDateTime_Check references PyDateTime_DateTimeType, which is declared static in datetimemodule.c. This is true for 2.3, 2.4 and CVS. That suggests that either PyDateTime_Check is supposed to only be used in the datetime module (in which case it is incorrectly named or its definition is in the wrong file) or the static and statichere declarations need to be removed from it. On the assumption that PyDateTime_Check is supposed to be publically used, I'm going to opt for the latter fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280924&group_id=5470 From noreply at sourceforge.net Fri Sep 2 21:49:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 12:49:25 -0700 Subject: [ python-Bugs-1280924 ] PyDateTime_Check references static object Message-ID: Bugs item #1280924, was opened at 2005-09-02 14:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280924&group_id=5470 Please note that this message will contain 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: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: PyDateTime_Check references static object Initial Comment: In trying to use the C API for datetime objects, we noticed that PyDateTime_Check references PyDateTime_DateTimeType, which is declared static in datetimemodule.c. This is true for 2.3, 2.4 and CVS. That suggests that either PyDateTime_Check is supposed to only be used in the datetime module (in which case it is incorrectly named or its definition is in the wrong file) or the static and statichere declarations need to be removed from it. On the assumption that PyDateTime_Check is supposed to be publically used, I'm going to opt for the latter fix. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-02 14:49 Message: Logged In: YES user_id=44345 After looking things over a bit I realize that in 2.4 there are two versions of the check macros and that the check macros in 2.3 were probably intended to only be used from within the module itself since there was no fully defined C API. I'm going to close this, but others feel free to reopen in case my original thoughts were more correct than I now think. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280924&group_id=5470 From noreply at sourceforge.net Fri Sep 2 22:37:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 13:37:45 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) >Assigned to: Brett Cannon (bcannon) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-09-02 13:37 Message: Logged In: YES user_id=357491 Can you let me know what time.strftime() outputs for your test case, specifically what type of basestring (str or unicode)? ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 09:43 Message: Logged In: YES user_id=259388 Here's a simpler, more precise test case (also attached): import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'; format = '%B' time.strptime(date, format) Here's the error I see: Traceback (most recent call last): File "de_strptime_fail_simple.py", line 4, in ? time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 329, in strptime month = locale_time.f_month.index(found_dict['B'].lower()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Fri Sep 2 22:57:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 13:57:34 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13:06 Message generated for change (Comment added) made by meonkeys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- >Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 13:57 Message: Logged In: YES user_id=259388 I get a str from time.strftime(). >>> import time >>> time.strftime('%B') 'September' >>> time.strftime('%B').__class__ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-02 13:37 Message: Logged In: YES user_id=357491 Can you let me know what time.strftime() outputs for your test case, specifically what type of basestring (str or unicode)? ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 09:43 Message: Logged In: YES user_id=259388 Here's a simpler, more precise test case (also attached): import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'; format = '%B' time.strptime(date, format) Here's the error I see: Traceback (most recent call last): File "de_strptime_fail_simple.py", line 4, in ? time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 329, in strptime month = locale_time.f_month.index(found_dict['B'].lower()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Fri Sep 2 23:05:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 14:05:13 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13:06 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 Please note that this message will contain a full 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: Wont Fix Priority: 5 Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-09-02 14:05 Message: Logged In: YES user_id=357491 OK, then that settles it. If time.strftime() ever returned unicode, I would say this needs fixing. But since time.strptime() is meant to be the mirror opposite of time.strftime(), I am going to close this as "Won't Fix". If time.strftime() ever gets changed to return unicode, then I will fix it. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 13:57 Message: Logged In: YES user_id=259388 I get a str from time.strftime(). >>> import time >>> time.strftime('%B') 'September' >>> time.strftime('%B').__class__ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-02 13:37 Message: Logged In: YES user_id=357491 Can you let me know what time.strftime() outputs for your test case, specifically what type of basestring (str or unicode)? ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 09:43 Message: Logged In: YES user_id=259388 Here's a simpler, more precise test case (also attached): import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'; format = '%B' time.strptime(date, format) Here's the error I see: Traceback (most recent call last): File "de_strptime_fail_simple.py", line 4, in ? time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 329, in strptime month = locale_time.f_month.index(found_dict['B'].lower()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Sat Sep 3 00:14:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 15:14:52 -0700 Subject: [ python-Bugs-1281032 ] xml.sax.expatreader doesn't pass encoding to ParserCreate Message-ID: Bugs item #1281032, was opened at 2005-09-02 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader doesn't pass encoding to ParserCreate Initial Comment: The ParserCreate function in the expat module accepts an encoding argument, presumably for use when the encoding is not provided in the XML document. This function is invoked by the reset() method of the ExpatParser class in xml.sax.expatreader. The encoding, if provided, is available from the InputSource object stored in the self._source variable, but the value is not passed along to ParserCreate. This bug is present in Python 2.4.1. I believe the correct fix is to change lines 246 and 247 in Lib/xml/ sax/expatreader.py from self._parser = expat.ParserCreate(None, " ", intern=self._interning) to self._parser = expat.ParserCreate(self._source.getEncoding (), " ", intern=self._interning) and line 252 from self._parser = expat.ParserCreate(intern = self._interning) to self._parser = expat.ParserCreate(self._source.getEncoding (), intern = self._interning) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281032&group_id=5470 From noreply at sourceforge.net Sat Sep 3 01:30:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 16:30:05 -0700 Subject: [ python-Feature Requests-1281053 ] non-sequence map() arguments for optimization Message-ID: Feature Requests item #1281053, was opened at 2005-09-02 16:30 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=1281053&group_id=5470 Please note that this message will contain 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: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 From noreply at sourceforge.net Sat Sep 3 08:43:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2005 23:43:06 -0700 Subject: [ python-Feature Requests-1281053 ] non-sequence map() arguments for optimization Message-ID: Feature Requests item #1281053, was opened at 2005-09-03 01:30 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 Please note that this message will contain 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: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 08:43 Message: Logged In: YES user_id=1188172 Use a list comprehension: [function(item, anObject) for item in myList] or, if you must use map, map(lambda item: function(item, anObject), myList) And please direct such questions to comp.lang.python in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 From noreply at sourceforge.net Sat Sep 3 09:50:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 00:50:45 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 09:50 Message: Logged In: YES user_id=1188172 Applied the newest patch. The warnings should be gone now. bz2module.c r1.26, 1.23.2.3. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 19:52 Message: Logged In: YES user_id=80475 The new patch works fine on this end. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-27 19:13 Message: Logged In: YES user_id=31435 Raymond, did you read the error output and verify that you're not suffering from the sample3.bz2 problem it explains? """ All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. """ Since the error you saw did come from sample3.bz2, that would be a good thing to check ;-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 19:02 Message: Logged In: YES user_id=1188172 Tackled the two warnings (tell() should return a long int if 64 bits) with new patch. I can't see the error in your output. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 18:31 Message: Logged In: YES user_id=80475 The latest patch gives me the following: --------------------Configuration: bz2 - Win32 Debug-------------------- Compiling... bz2module.c C:\py25\Modules\bz2module.c(1143) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data C:\py25\Modules\bz2module.c(1143) : warning C4761: integral size mismatch in argument; conversion supplied lib /out:libbz2.lib blocksort.obj huffman.obj crctable.obj randtable.obj compress.obj decompress.obj bzlib.obj Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2 bzip2.c libbz2.lib setargv.obj bzip2.c cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2recover bzip2recover.c bzip2recover.c type words1 Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. .\bzip2 -1 < sample1.ref > sample1.rb2 .\bzip2 -2 < sample2.ref > sample2.rb2 .\bzip2 -3 < sample3.ref > sample3.rb2 .\bzip2 -d < sample1.bz2 > sample1.tst .\bzip2 -d < sample2.bz2 > sample2.tst .\bzip2 -ds < sample3.bz2 > sample3.tst All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. fc sample1.bz2 sample1.rb2 Comparing files sample1.bz2 and sample1.rb2 FC: no differences encountered fc sample2.bz2 sample2.rb2 Comparing files sample2.bz2 and sample2.rb2 FC: no differences encountered fc sample3.bz2 sample3.rb2 Comparing files sample3.bz2 and sample3.rb2 ****** sample3.bz2 BZh31AY&SY??3? ??uU???`??2 ???I%@? ??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R? ****** sample3.rb2 BZh31AY&SY???> ?# ?A?J3?????z? ??7U?{??C2 ?l }??? ****** fc sample1.tst sample1.ref Comparing files sample1.tst and sample1.ref FC: no differences encountered fc sample2.tst sample2.ref Comparing files sample2.tst and sample2.ref FC: no differences encountered fc sample3.tst sample3.ref Comparing files sample3.tst and sample3.ref FC: no differences encountered Linking... bz2_d.pyd - 1 error(s), 2 warning(s) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 16:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 14:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 14:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Sep 3 12:31:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 03:31:00 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-03 12:31 Message: Logged In: YES user_id=38388 If you think there's a use case, yes. Enjoy your vacation ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-02 20:33 Message: Logged In: YES user_id=89016 OK, now I'm beginning to understand the docstring. Nevertheless I think having a class that uses stateful codecs at both ends would be useful. If you want, I can give this a try (after I'm back from vactation in four weeks). Closing the report as fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 20:28 Message: Logged In: YES user_id=38388 Thanks, Walter. StreamRecorder is not broken: it works as advertised (see the .__init__() doc-string and interface) and yes, this means that only stateless encodings can be used, such as e.g. UTF-16-LE, simply because the encode and decode functions are defined as being stateless. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Sat Sep 3 17:18:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 08:18:45 -0700 Subject: [ python-Bugs-1281291 ] Erroneous \url command in python.sty Message-ID: Bugs item #1281291, was opened at 2005-09-03 17: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=1281291&group_id=5470 Please note that this 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: Rory Yorke (ryorke) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous \url command in python.sty Initial Comment: The \url and \ulink commands in texinputs/python.sty produce erroneous PDF files. This can be fairly easily tested using GhostScript (see the attached log file for an example). The current Python 2.4.1 PDF docs (as downloadable from www.python.org) have this error. Although the error does not prevent correct rendering in viewers such as gv, xpdf or acroread, the link is absent. The attached patch partially addresses this, by changing the arguments to the \pdfstart command used. The changes are taken straight from texmf/tex/latex/hyperref/hpdftex.def; that file has the following version header: %% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz, %% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $ I don't pretend to understand the TeX code, but it does fix some of the problem. Some URLs, like http://sourceforge.net/bugs/?group_id=5470, are not linked to correctly. That particular URL becomes http://sourceforge.net/bugs/?groupunhbox%20voidb at x%20penalty%20 at M%20hskip%20z at skip%20unhbox%20voidb at x%20kern%20.06emvbox%20{hrule%20width.3em}discretionary%20{-}{}{}penalty%20 at M%20hskip%20z at skip%20id=5470 -- I guess that has something to do with the underscore. The diff was generated relative to Python CVS head of 3 Sept 2005; the python.sty file had version 1.113. The python executable used was 2.4.1, not CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470 From noreply at sourceforge.net Sat Sep 3 18:26:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 09:26:21 -0700 Subject: [ python-Feature Requests-1281053 ] non-sequence map() arguments for optimization Message-ID: Feature Requests item #1281053, was opened at 2005-09-02 18:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 Please note that this message will contain 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: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:26 Message: Logged In: YES user_id=80475 from itertools import imap, repeat list(imap(function, myList, repeat(anObject))) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 01:43 Message: Logged In: YES user_id=1188172 Use a list comprehension: [function(item, anObject) for item in myList] or, if you must use map, map(lambda item: function(item, anObject), myList) And please direct such questions to comp.lang.python in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 From noreply at sourceforge.net Sat Sep 3 18:36:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 09:36:12 -0700 Subject: [ python-Feature Requests-1281053 ] non-sequence map() arguments for optimization Message-ID: Feature Requests item #1281053, was opened at 2005-09-02 18:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 Please note that this message will contain 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: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:36 Message: Logged In: YES user_id=80475 Or just: map(function, myList, repeat(anObject, len(myList))) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:26 Message: Logged In: YES user_id=80475 from itertools import imap, repeat list(imap(function, myList, repeat(anObject))) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 01:43 Message: Logged In: YES user_id=1188172 Use a list comprehension: [function(item, anObject) for item in myList] or, if you must use map, map(lambda item: function(item, anObject), myList) And please direct such questions to comp.lang.python in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 From noreply at sourceforge.net Sat Sep 3 19:01:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 10:01:40 -0700 Subject: [ python-Bugs-1275719 ] discrepancy between str.__cmp__ and unicode.__cmp__ Message-ID: Bugs item #1275719, was opened at 2005-08-29 09:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470 Please note that this message 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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: discrepancy between str.__cmp__ and unicode.__cmp__ Initial Comment: I had the surprise, while wanted to use str.__cmp__ as the cmp argument to list.sort(), that it seems buggy compared to unicode.__cmp__, and that these methods seem implemented quite differently (they have a different type): $ python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode.__cmp__ >>> str.__cmp__ >>> u'a'.__cmp__(u'b') -1 >>> 'a'.__cmp__('b') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'str' object has no attribute '__cmp__' >>> unicode.__cmp__(u'a', u'b') -1 >>> str.__cmp__('a', 'b') Traceback (most recent call last): File "", line 1, in ? TypeError: expected 1 arguments, got 2 Am I missing something ? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 12:01 Message: Logged In: YES user_id=80475 In the absence of a defined __cmp__ method for string objects, str.__cmp__ inherits type.__cmp__ which is used for comparing types. That is why you can sort a list of types: >>> sorted([int, complex, float, str, dict, list, tuple]) [, , , , , , ] ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 10:35 Message: Logged In: YES user_id=133955 You are right, I also forgot there is a builtin cmp() function that works like expected. Still str.__cmp__'s behaviour is a bit puzzling to me... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-29 10:16 Message: Logged In: YES user_id=1188172 String comparison is done with rich compare methods, namely __lt__, __le__, __gt__, __ge__ and __eq__, __ne__. Why str.__cmp__ exists and 'a'.__cmp__ does not, I cannot say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470 From noreply at sourceforge.net Sat Sep 3 20:17:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 11:17:32 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 10:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) >Assigned to: Martin v. L?wis (loewis) Summary: test_pwd fails on 64bit system (Opteron) Initial Comment: test test_pwd failed -- Traceback (most recent call last): File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum $ cat /proc/version Linux version 2.4.21-20.ELsmp (bhcompile at dolly.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18 20:34:58 EDT 2004 Processor is AMD Opteron 2.4MHz ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 20:17 Message: Logged In: YES user_id=1188172 Is the patch safe to apply? I think so, I haven't seen a negative uid/gid yet. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-09-01 14:57 Message: Logged In: YES user_id=1035073 The suggested patch by heffler worked brilliantly for my 64 bit environment. Thanks. My bug submission was on 2005-08-03 14:40. ---------------------------------------------------------------------- Comment By: Marvin Heffler (heffler) Date: 2005-08-11 20:19 Message: Logged In: YES user_id=298758 I think I figued out the problem with python handling uids and gids greater than 2147483647 when using the grp.getgrgid and pwd.getpwuid functions. Both of the functions call PyArg_ParseTuple with a type of "i", thus indicating the argument is a signed integer. Instead they should be using "I" (upper-case i) for an unsigned integer. The fix is fairly simple. Here are the two patches necessary to the python source: diff -Naur Python-2.4.orig/Modules/grpmodule.c Python- 2.4/Modules/grpmodule.c --- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 16:06:00.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -0400 @@ -87,7 +87,7 @@ { int gid; struct group *p; - if (!PyArg_ParseTuple(args, "i:getgrgid", &gid)) + if (!PyArg_ParseTuple(args, "I:getgrgid", &gid)) return NULL; if ((p = getgrgid(gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python- 2.4/Modules/pwdmodule.c --- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 16:07:23.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -0400 @@ -104,7 +104,7 @@ { int uid; struct passwd *p; - if (!PyArg_ParseTuple(args, "i:getpwuid", &uid)) + if (!PyArg_ParseTuple(args, "I:getpwuid", &uid)) return NULL; if ((p = getpwuid(uid)) == NULL) { PyErr_Format(PyExc_KeyError, Hopefully, someone from the python project can verify my patch and get it incorporated into a future release. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-08-03 20:40 Message: Logged In: YES user_id=1035073 The same error occurs for an Intel P4-521 processor running RedHat Enterprise Linux WS v4 Intel EM64T 64bit. $ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005 test test_grp failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum test test_pwd failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-03-17 10:20 Message: Logged In: YES user_id=358087 I've tried the patch - no luck :-( I'm stealing time on these machines since they belong to another group. However I see that SF's compile farm (http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) have an AMD64 host (amd64-linux1) Maybe you can shorten the loop ... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 23:17 Message: Logged In: YES user_id=89016 On a 32bit system adding the line nobody:x:4294967294:65534:nobody:/:/bin/false to /etc/passwd pwd.getpwall() gives me an entry: ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') and pwd.getpwuid(-2) gives me ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') Maybe for 64bit systems the SETI macro should use PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can you try the following patch? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-17 09:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-17 02:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 10:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Sat Sep 3 22:16:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 13:16:53 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 22:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Sun Sep 4 00:12:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 15:12:34 -0700 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 01:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Sun Sep 4 01:20:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 16:20:48 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 15:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 18:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Sun Sep 4 02:36:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Sep 2005 17:36:52 -0700 Subject: [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 07:17 Message generated for change (Comment added) made by ekid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Please note that this message will contain a full 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: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- Comment By: Dmitry Vukolov (ekid) Date: 2005-09-04 04:36 Message: Logged In: YES user_id=1000960 The problem still exists in Python 2.4.1 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 23:37 Message: Logged In: YES user_id=752496 richard seems to reproduced it on Py2.3, changing the group to it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2005-01-17 01:01 Message: Logged In: YES user_id=6405 This is still an issue. python -c 'import webbrowser;webbrowser.open("http://www.google.com/")' on a system using KDE will exhibit the break. I posted a patch to fix the behaviour in my last message. I just noticed that I invoked diff the wrong way around (though the explanation still stands) - a correct invocation: --- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208 +1100 +++ /usr/lib/python2.3/webbrowser.py 2005-01-17 08:59:58.269989095 +1100 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:26 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: Richard Jones (richard) Date: 2003-08-20 04:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 04:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 23:43 Message: Logged In: YES user_id=198518 A week after posting <slrnb5iu1s.t8.matt at sake.mondoinfo.com> ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 16:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Sun Sep 4 12:19:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 03:19:13 -0700 Subject: [ python-Bugs-1281556 ] exception when unpickling array.array objects Message-ID: Bugs item #1281556, was opened at 2005-09-04 20: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=1281556&group_id=5470 Please note that this message will contain a full 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: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: exception when unpickling array.array objects Initial Comment: Note 1: same error for pickle and cPickle Note 2: pickle.dumps and cPickle.dumps produce different results [see below] -- is this expected? Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, cPickle, array >>> ia = array.array('i',[3,2,1]) >>> ia array('i', [3, 2, 1]) >>> pia = pickle.dumps(ia, -1) >>> pia '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> cia = cPickle.dumps(ia, -1) >>> pia == cia False >>> cia '\x80\x02carray\narray\nq\x01)\x81q\x02.' >>> pickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) >>> pickle.loads(cia) [same as above] >>> cPickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? TypeError: array() takes at least 1 argument (0 given) >>> cPickle.loads(cia) [same as above] >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 From noreply at sourceforge.net Sun Sep 4 12:21:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 03:21:21 -0700 Subject: [ python-Bugs-1281556 ] exception when unpickling array.array objects Message-ID: Bugs item #1281556, was opened at 2005-09-04 20:19 Message generated for change (Settings changed) made by sjmachin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 Please note that this message will contain a full 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: John Machin (sjmachin) >Assigned to: Raymond Hettinger (rhettinger) Summary: exception when unpickling array.array objects Initial Comment: Note 1: same error for pickle and cPickle Note 2: pickle.dumps and cPickle.dumps produce different results [see below] -- is this expected? Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, cPickle, array >>> ia = array.array('i',[3,2,1]) >>> ia array('i', [3, 2, 1]) >>> pia = pickle.dumps(ia, -1) >>> pia '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> cia = cPickle.dumps(ia, -1) >>> pia == cia False >>> cia '\x80\x02carray\narray\nq\x01)\x81q\x02.' >>> pickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) >>> pickle.loads(cia) [same as above] >>> cPickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? TypeError: array() takes at least 1 argument (0 given) >>> cPickle.loads(cia) [same as above] >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 From noreply at sourceforge.net Sun Sep 4 12:41:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 03:41:32 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-04 06:16 Message generated for change (Comment added) made by sjmachin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 20:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-04 09:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Sun Sep 4 12:46:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 03:46:08 -0700 Subject: [ python-Bugs-1281556 ] exception when unpickling array.array objects Message-ID: Bugs item #1281556, was opened at 2005-09-04 20:19 Message generated for change (Comment added) made by sjmachin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 Please note that this message will contain a full 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: John Machin (sjmachin) Assigned to: Raymond Hettinger (rhettinger) Summary: exception when unpickling array.array objects Initial Comment: Note 1: same error for pickle and cPickle Note 2: pickle.dumps and cPickle.dumps produce different results [see below] -- is this expected? Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, cPickle, array >>> ia = array.array('i',[3,2,1]) >>> ia array('i', [3, 2, 1]) >>> pia = pickle.dumps(ia, -1) >>> pia '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> cia = cPickle.dumps(ia, -1) >>> pia == cia False >>> cia '\x80\x02carray\narray\nq\x01)\x81q\x02.' >>> pickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) >>> pickle.loads(cia) [same as above] >>> cPickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? TypeError: array() takes at least 1 argument (0 given) >>> cPickle.loads(cia) [same as above] >>> ---------------------------------------------------------------------- >Comment By: John Machin (sjmachin) Date: 2005-09-04 20:46 Message: Logged In: YES user_id=480138 Refer bug report 1281383. Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 From noreply at sourceforge.net Sun Sep 4 15:28:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 06:28:59 -0700 Subject: [ python-Bugs-1281556 ] exception when unpickling array.array objects Message-ID: Bugs item #1281556, was opened at 2005-09-04 05:19 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 Please note that this message will contain a full 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: John Machin (sjmachin) >Assigned to: Nobody/Anonymous (nobody) Summary: exception when unpickling array.array objects Initial Comment: Note 1: same error for pickle and cPickle Note 2: pickle.dumps and cPickle.dumps produce different results [see below] -- is this expected? Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, cPickle, array >>> ia = array.array('i',[3,2,1]) >>> ia array('i', [3, 2, 1]) >>> pia = pickle.dumps(ia, -1) >>> pia '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> cia = cPickle.dumps(ia, -1) >>> pia == cia False >>> cia '\x80\x02carray\narray\nq\x01)\x81q\x02.' >>> pickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) >>> pickle.loads(cia) [same as above] >>> cPickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? TypeError: array() takes at least 1 argument (0 given) >>> cPickle.loads(cia) [same as above] >>> ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 05:46 Message: Logged In: YES user_id=480138 Refer bug report 1281383. Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 From noreply at sourceforge.net Sun Sep 4 19:30:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 10:30:13 -0700 Subject: [ python-Bugs-1281692 ] urllib violates rfc 959 Message-ID: Bugs item #1281692, was opened at 2005-09-04 19:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 Please note that this message will contain a full 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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 From noreply at sourceforge.net Mon Sep 5 00:43:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 15:43:15 -0700 Subject: [ python-Bugs-999042 ] Compiler module doesn't handle global statement correctly Message-ID: Bugs item #999042, was opened at 2004-07-27 22:15 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470 Please note that this message will contain a full 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: Jim Fulton (dcjim) >Assigned to: Neil Schemenauer (nascheme) Summary: Compiler module doesn't handle global statement correctly Initial Comment: If we don't use the compiler module: >>> code = 'global x\nx=1' >>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2 >>> d1, d2 ({'__builtins__': {}, 'x': 1}, {}) with the compiler module: >>> code = compiler.compile('global x\nx=1', 'd', 'exec') >>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2 >>> d1, d2 ({'__builtins__': {}}, {'x': 1}) global is ignored ---------------------------------------------------------------------- Comment By: Darek Suchojad (dsuch) Date: 2005-04-29 22:04 Message: Logged In: YES user_id=954779 Hi, I have submitted a simple fix some time ago python.org/sf/1090482, do you think it is correct? ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2004-07-28 14:01 Message: Logged In: YES user_id=73023 Also in 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470 From noreply at sourceforge.net Mon Sep 5 03:15:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Sep 2005 18:15:19 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 10:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-04 21:15 Message: Logged In: YES user_id=31435 dt.py imports fine (except for the ImportError the OP mentioned) under current CVS HEAD and under current 2.4 maintenance branch, on Windows XP Pro SP2, so closing this as fixed. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 12:56 Message: Logged In: YES user_id=89016 Copying codecs.py from current CVS (2.4 branch) over your codecs.py (making a backup first) should be sufficient to test this. You can this version from http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Lib/codecs.py?rev=1.35.2.9 ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-20 05:37 Message: Logged In: YES user_id=1181710 It's ok if I remove coding declaration. I have no access to current cvs, but if someone send me a zip with latest version, I can try it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-07-19 12:19 Message: Logged In: YES user_id=89016 This bug should be fixed in the current CVS version. So, can you retry with current CVS? As a workaround you might also want to remove the PEP 263 coding declaration if you don't have any special character in your file. ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-19 12:05 Message: Logged In: YES user_id=1181710 I have a similar problem with an other file (log.py). On my computer ( Windows 2000 ) this 2 files ( log.py and dt.py ) works with python 2.4 but raise a syntax error on python 2.4.1 : D:\dvt\tmp\bug2_4_1>python -c "import log" Traceback (most recent call last): File "", line 1, in ? File "D:\dvt\tmp\bug2_4_1\log.py", line 356 w = 72 ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 10:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Mon Sep 5 23:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Sep 2005 14:12:17 -0700 Subject: [ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers Message-ID: Bugs item #1282539, was opened at 2005-09-05 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 Please note that this message will contain a full 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: Fons Dijkstra (fdij) Assigned to: Nobody/Anonymous (nobody) Summary: logging.shutdown() not correct for chained handlers Initial Comment: Consider the following code: import logging import logging.handlers if __name__ == "__main__": fh = logging.handlers.RotatingFileHandler("log.txt") mh = logging.handlers.MemoryHandler(1024, logging.ERROR, fh) logging.getLogger().addHandler(mh) logging.getLogger().warning("next statement crashes") logging.shutdown() which results in a crash due to operating on a closed file. The reason is that the shutdown flushes and closes all handlers in undefined order. In above case, first the 'fh' handlers is flushes and closed then the 'mh' handler. The solution is to first flush all handlers times the number of handlers before closing them. Thus (omitting error handling): def shutdown(): for i in range(len(_handlers)): for h in _handlers.keys(): h.flush() for h in _handlers.keys(): h.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 From noreply at sourceforge.net Tue Sep 6 06:46:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Sep 2005 21:46:24 -0700 Subject: [ python-Bugs-1282647 ] socket.getaddrinfo() bug for IPv6 enabled platforms Message-ID: Bugs item #1282647, was opened at 2005-09-06 10: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=1282647&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ganesan Rajagopal (rganesan) Assigned to: Nobody/Anonymous (nobody) Summary: socket.getaddrinfo() bug for IPv6 enabled platforms Initial Comment: ====== getaddrinfo(host, port[, family[, socktype[, proto[, flags]]]]) Resolves the host/port argument, into a sequence of 5-tuples that contain all the necessary argument for the sockets manipulation. host is a domain name, a string representation of IPv4/v6 address or None. port is a string service name (like 'http'), a numeric port number or None. ====== On Linux (and FreeBSD and probably other IPv6 enabled hosts), port as a number raises a socket exception ====== $ 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 socket >>> socket.getaddrinfo('6bone.net', 'http') [(10, 1, 6, '', ('2001:5c0:0:2::24', 80, 0, 0)), (2, 1, 6, '', ('209.71.226.24', 80))] >>> socket.getaddrinfo('6bone.net', 80) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-8, 'Servname not supported for ai_socktype') ====== Since, on Windows 2003 Server (no IPv6) and Solaris 2.8 (no IPv6), the call works correctly, I am filing this bug as platform specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282647&group_id=5470 From noreply at sourceforge.net Tue Sep 6 17:37:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 08:37:52 -0700 Subject: [ python-Feature Requests-1283110 ] Give __len__() advice for "don't know" Message-ID: Feature Requests item #1283110, was opened at 2005-09-06 11: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=1283110&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Give __len__() advice for "don't know" Initial Comment: A class may wish to define __len__() despite that it doesn't know how many objects iterating an instance may produce. The docs should give advice for this case. They should also explicitly point out that the result of __len__() is generally taken to be a _hint_ (functions like map(), tuple(), etc., may preallocate space based on __len__()'s result, but adjust to the actual number of objects produced). Tail end of a related thread: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470 From noreply at sourceforge.net Tue Sep 6 20:04:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 11:04:25 -0700 Subject: [ python-Bugs-1280061 ] time.strptime() fails with unicode date string, de_DE locale Message-ID: Bugs item #1280061, was opened at 2005-09-01 13:06 Message generated for change (Comment added) made by meonkeys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 Please note that this message will contain a full 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: Wont Fix Priority: 5 Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() fails with unicode date string, de_DE locale Initial Comment: Trying to parse a German date string fails in Python 2.4.1. Test case attached. Since there's no indenting, I suppose the test case can also be pasted here: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'10. September 2005 um 17:26' format = '%d. %B %Y um %H:%M' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- >Comment By: Adam Monsen (meonkeys) Date: 2005-09-06 11:04 Message: Logged In: YES user_id=259388 Ok, sounds good. For anyone trying to work around this, unicode date strings should be encoded to simple Python strings (type of str) before passing into strptime. Here's an updated version of the aforementioned test case demonstrating an acceptable workaround: import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'.encode() format = '%B' time.strptime(date, format) -- Adam Monsen http://adammonsen.com/ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-02 14:05 Message: Logged In: YES user_id=357491 OK, then that settles it. If time.strftime() ever returned unicode, I would say this needs fixing. But since time.strptime() is meant to be the mirror opposite of time.strftime(), I am going to close this as "Won't Fix". If time.strftime() ever gets changed to return unicode, then I will fix it. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 13:57 Message: Logged In: YES user_id=259388 I get a str from time.strftime(). >>> import time >>> time.strftime('%B') 'September' >>> time.strftime('%B').__class__ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-02 13:37 Message: Logged In: YES user_id=357491 Can you let me know what time.strftime() outputs for your test case, specifically what type of basestring (str or unicode)? ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-02 09:43 Message: Logged In: YES user_id=259388 Here's a simpler, more precise test case (also attached): import locale, time locale.setlocale(locale.LC_TIME, 'de_DE') date = u'September'; format = '%B' time.strptime(date, format) Here's the error I see: Traceback (most recent call last): File "de_strptime_fail_simple.py", line 4, in ? time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 329, in strptime month = locale_time.f_month.index(found_dict['B'].lower()) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1280061&group_id=5470 From noreply at sourceforge.net Tue Sep 6 21:12:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 12:12:50 -0700 Subject: [ python-Bugs-1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message Message-ID: Bugs item #1283289, was opened at 2005-09-06 15:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 Please note that this 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: japierro (japierro) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords gives misleading error message Initial Comment: Python 2.3.3 on Windows XP If the user supplies one valid and one invalid keyword to a function that defines two required keyword arguments, PyArg_ParseTupleAndKeywords will raise this exception: TypeError: function takes exactly 2 arguments (1 given) If, in getargs.c, vgetargskeywords, the check for "extraneous keywords" were done near the top of the function, a more meaningful exception would be thrown: TypeError: 'bad' is an invalid keyword argument for this function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 From noreply at sourceforge.net Wed Sep 7 02:18:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 17:18:50 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-07 00: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=1283491&group_id=5470 Please note that this 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: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Wed Sep 7 05:11:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 20:11:42 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-06 19:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 Please note that this 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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-06 22:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Wed Sep 7 05:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 20:12:52 -0700 Subject: [ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers Message-ID: Bugs item #1282539, was opened at 2005-09-05 16:12 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 Please note that this message will contain a full 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: Fons Dijkstra (fdij) >Assigned to: Vinay Sajip (vsajip) Summary: logging.shutdown() not correct for chained handlers Initial Comment: Consider the following code: import logging import logging.handlers if __name__ == "__main__": fh = logging.handlers.RotatingFileHandler("log.txt") mh = logging.handlers.MemoryHandler(1024, logging.ERROR, fh) logging.getLogger().addHandler(mh) logging.getLogger().warning("next statement crashes") logging.shutdown() which results in a crash due to operating on a closed file. The reason is that the shutdown flushes and closes all handlers in undefined order. In above case, first the 'fh' handlers is flushes and closed then the 'mh' handler. The solution is to first flush all handlers times the number of handlers before closing them. Thus (omitting error handling): def shutdown(): for i in range(len(_handlers)): for h in _handlers.keys(): h.flush() for h in _handlers.keys(): h.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 From noreply at sourceforge.net Wed Sep 7 07:24:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Sep 2005 22:24:59 -0700 Subject: [ python-Feature Requests-1283110 ] Give __len__() advice for "don't know" Message-ID: Feature Requests item #1283110, was opened at 2005-09-06 10:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Give __len__() advice for "don't know" Initial Comment: A class may wish to define __len__() despite that it doesn't know how many objects iterating an instance may produce. The docs should give advice for this case. They should also explicitly point out that the result of __len__() is generally taken to be a _hint_ (functions like map(), tuple(), etc., may preallocate space based on __len__()'s result, but adjust to the actual number of objects produced). Tail end of a related thread: ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 00:24 Message: Logged In: YES user_id=80475 FWIW, I had explored this topic at some length with Guido's input and arrived at somewhat similar guidance. At any given time, a dynamic object with a __len__() method should report accurately or not at all (raising a TypeError). Accurate means that at that moment, len(d) == len(list(d)). Subsequent mutations may affect the length and the __len__() method is expected to adjust accordingly. For more notes on the subject, see the module docstring for Lib/test/test_iterlen.py In the face of dynamic inputs, consumer functions like map() must regard the reported lengths as estimates. However, that should not lower the standards for objects reporting their length. That number should continue to have some meaning such as the point-in-time invariant described above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1283110&group_id=5470 From noreply at sourceforge.net Wed Sep 7 13:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 04:12:17 -0700 Subject: [ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers Message-ID: Bugs item #1282539, was opened at 2005-09-05 21:12 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 Please note that this message will contain a full 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: Fons Dijkstra (fdij) Assigned to: Vinay Sajip (vsajip) Summary: logging.shutdown() not correct for chained handlers Initial Comment: Consider the following code: import logging import logging.handlers if __name__ == "__main__": fh = logging.handlers.RotatingFileHandler("log.txt") mh = logging.handlers.MemoryHandler(1024, logging.ERROR, fh) logging.getLogger().addHandler(mh) logging.getLogger().warning("next statement crashes") logging.shutdown() which results in a crash due to operating on a closed file. The reason is that the shutdown flushes and closes all handlers in undefined order. In above case, first the 'fh' handlers is flushes and closed then the 'mh' handler. The solution is to first flush all handlers times the number of handlers before closing them. Thus (omitting error handling): def shutdown(): for i in range(len(_handlers)): for h in _handlers.keys(): h.flush() for h in _handlers.keys(): h.close() ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-07 11:12 Message: Logged In: YES user_id=308438 There is indeed a problem - thanks for the report. Rather than your proposed solution, I would rather add another internal list, _handlerList, which holds the handlers in *reverse* order of creation. When shutting down, (a copy of) this list is used for the iteration rather than _handlers.keys(). I may remove _handlers in the future - I can't remember why I made it a dict rather than a list. Will check into CVS soon, then mark this as Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 From noreply at sourceforge.net Wed Sep 7 14:30:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 05:30:49 -0700 Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with unicode paths Message-ID: Bugs item #1283895, was opened at 2005-09-07 14: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=1283895&group_id=5470 Please note that this 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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.abspath() / os.chdir() buggy with unicode paths Initial Comment: Hi, Under Windows Explorer, one can create directory names using characters not belonging to the user locale. For example, one of our users created a directory named "C:\Mes Documents\コピー ～ solipsis_svn". Unfortunately, when trying to manipulate such a pathname, os.path.abspath() and os.chdir() don't work hand in hand. os.path.abspath() uses the garbled directory name as displayed by the command prompt and then os.chdir() refuses the path: C:\>cd "C:\Mes Documents\??? ~ solipsis_svn" C:\Mes Documents\??? ~ solipsis_svn>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import os >>> os.curdir '.' >>> os.path.abspath(os.curdir) 'C:\Mes Documents\??? ~ solipsis_svn' >>> os.chdir(os.path.abspath(os.curdir)) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'C:\Mes Documents\??? ~ solipsis_svn' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 From noreply at sourceforge.net Wed Sep 7 14:36:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 05:36:18 -0700 Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with unicode paths Message-ID: Bugs item #1283895, was opened at 2005-09-07 14:30 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 Please note that this 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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.abspath() / os.chdir() buggy with unicode paths Initial Comment: Hi, Under Windows Explorer, one can create directory names using characters not belonging to the user locale. For example, one of our users created a directory named "C:\Mes Documents\コピー ～ solipsis_svn". Unfortunately, when trying to manipulate such a pathname, os.path.abspath() and os.chdir() don't work hand in hand. os.path.abspath() uses the garbled directory name as displayed by the command prompt and then os.chdir() refuses the path: C:\>cd "C:\Mes Documents\??? ~ solipsis_svn" C:\Mes Documents\??? ~ solipsis_svn>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import os >>> os.curdir '.' >>> os.path.abspath(os.curdir) 'C:\Mes Documents\??? ~ solipsis_svn' >>> os.chdir(os.path.abspath(os.curdir)) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'C:\Mes Documents\??? ~ solipsis_svn' >>> ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-09-07 14:36 Message: Logged In: YES user_id=133955 > "C:\Mes Documents\コピー ～ solipsis_svn" Gasp. Sourceforge escapes HTML entities instead of showing the real characters... These are Japanese characters, btw. It's easy to copy/paste some Japanese characters from a Web site and paste them into Windows Explorer to create a directory (at least it works with Mozilla Firefox). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 From noreply at sourceforge.net Wed Sep 7 21:02:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 12:02:03 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-07 00:18 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 Please note that this 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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- >Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 03:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Wed Sep 7 21:02:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 12:02:32 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-07 00:18 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 Please note that this 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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- >Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 03:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Wed Sep 7 23:16:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 14:16:36 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 01:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) Assigned to: Martin v. L?wis (loewis) Summary: test_pwd fails on 64bit system (Opteron) Initial Comment: test test_pwd failed -- Traceback (most recent call last): File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum $ cat /proc/version Linux version 2.4.21-20.ELsmp (bhcompile at dolly.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18 20:34:58 EDT 2004 Processor is AMD Opteron 2.4MHz ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-07 14:16 Message: Logged In: YES user_id=33168 See this patch which looks like it may fix the same problem (among others). https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 11:17 Message: Logged In: YES user_id=1188172 Is the patch safe to apply? I think so, I haven't seen a negative uid/gid yet. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-09-01 05:57 Message: Logged In: YES user_id=1035073 The suggested patch by heffler worked brilliantly for my 64 bit environment. Thanks. My bug submission was on 2005-08-03 14:40. ---------------------------------------------------------------------- Comment By: Marvin Heffler (heffler) Date: 2005-08-11 11:19 Message: Logged In: YES user_id=298758 I think I figued out the problem with python handling uids and gids greater than 2147483647 when using the grp.getgrgid and pwd.getpwuid functions. Both of the functions call PyArg_ParseTuple with a type of "i", thus indicating the argument is a signed integer. Instead they should be using "I" (upper-case i) for an unsigned integer. The fix is fairly simple. Here are the two patches necessary to the python source: diff -Naur Python-2.4.orig/Modules/grpmodule.c Python- 2.4/Modules/grpmodule.c --- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 16:06:00.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -0400 @@ -87,7 +87,7 @@ { int gid; struct group *p; - if (!PyArg_ParseTuple(args, "i:getgrgid", &gid)) + if (!PyArg_ParseTuple(args, "I:getgrgid", &gid)) return NULL; if ((p = getgrgid(gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python- 2.4/Modules/pwdmodule.c --- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 16:07:23.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -0400 @@ -104,7 +104,7 @@ { int uid; struct passwd *p; - if (!PyArg_ParseTuple(args, "i:getpwuid", &uid)) + if (!PyArg_ParseTuple(args, "I:getpwuid", &uid)) return NULL; if ((p = getpwuid(uid)) == NULL) { PyErr_Format(PyExc_KeyError, Hopefully, someone from the python project can verify my patch and get it incorporated into a future release. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-08-03 11:40 Message: Logged In: YES user_id=1035073 The same error occurs for an Intel P4-521 processor running RedHat Enterprise Linux WS v4 Intel EM64T 64bit. $ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005 test test_grp failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum test test_pwd failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-03-17 01:20 Message: Logged In: YES user_id=358087 I've tried the patch - no luck :-( I'm stealing time on these machines since they belong to another group. However I see that SF's compile farm (http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) have an AMD64 host (amd64-linux1) Maybe you can shorten the loop ... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 14:17 Message: Logged In: YES user_id=89016 On a 32bit system adding the line nobody:x:4294967294:65534:nobody:/:/bin/false to /etc/passwd pwd.getpwall() gives me an entry: ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') and pwd.getpwuid(-2) gives me ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') Maybe for 64bit systems the SETI macro should use PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can you try the following patch? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-17 00:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-16 17:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 01:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Thu Sep 8 00:36:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 15:36:08 -0700 Subject: [ python-Bugs-1284341 ] re nested conditional matching (?()) doesn't work Message-ID: Bugs item #1284341, was opened at 2005-09-07 18:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 Please note that this 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: Erik Demaine (edemaine) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re nested conditional matching (?()) doesn't work Initial Comment: Here is a simple regular expression that should match \o, \{o}, {\o}, and \{o}}: (This example arose as a simplification of a general accent matcher for LaTeX/BibTeX.) r = re.compile(r'(\{)?\"(\{)?(.)(?(2)\})(?(1)\})') However, it fails on two out of four of the desired matches: r.search(r'\o) ## returns None (WRONG) r.search(r\{o}').group() ## returns '\"{o}"' (CORRECT) r.search(r'{\o).group() ## returns \"o} (WRONG) r.search(r{\{o}}').group() ## returns '{\"{o}}' (CORRECT) The third case is particularly bizarre. Incidentally, the behavior is different if '(.)' is replaced by '.' (incorrect in different ways). I have tested this on Python 2.4.1 on Windows and a CVS version on Linux. I do not believe it is a platform issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 From noreply at sourceforge.net Thu Sep 8 01:09:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 16:09:58 -0700 Subject: [ python-Bugs-1284341 ] re nested conditional matching (?()) doesn't work Message-ID: Bugs item #1284341, was opened at 2005-09-07 18:36 Message generated for change (Comment added) made by edemaine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 Please note that this 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: Erik Demaine (edemaine) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re nested conditional matching (?()) doesn't work Initial Comment: Here is a simple regular expression that should match \o, \{o}, {\o}, and \{o}}: (This example arose as a simplification of a general accent matcher for LaTeX/BibTeX.) r = re.compile(r'(\{)?\"(\{)?(.)(?(2)\})(?(1)\})') However, it fails on two out of four of the desired matches: r.search(r'\o) ## returns None (WRONG) r.search(r\{o}').group() ## returns '\"{o}"' (CORRECT) r.search(r'{\o).group() ## returns \"o} (WRONG) r.search(r{\{o}}').group() ## returns '{\"{o}}' (CORRECT) The third case is particularly bizarre. Incidentally, the behavior is different if '(.)' is replaced by '.' (incorrect in different ways). I have tested this on Python 2.4.1 on Windows and a CVS version on Linux. I do not believe it is a platform issue. ---------------------------------------------------------------------- >Comment By: Erik Demaine (edemaine) Date: 2005-09-07 19:09 Message: Logged In: YES user_id=265183 Whoops, I just updated CVS to the latest HEAD and discovered that the problem has already been solved. Nice work! Sorry about the extraneous report, but let me turn this into a request that the fix go into 2.4.2, not just 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 From noreply at sourceforge.net Thu Sep 8 04:37:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 19:37:24 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-06 19:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 Please note that this 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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 21:37 Message: Logged In: YES user_id=80475 """ >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? """ FYI, the answer is no. The requirement for parenthesis cannot change. To see why, parse this: f(g(t) for t in a, b). ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-09-07 14:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-09-07 14:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-06 22:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Thu Sep 8 07:26:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 22:26:33 -0700 Subject: [ python-Bugs-1284496 ] traceback module can return undecodable byte strings Message-ID: Bugs item #1284496, was opened at 2005-09-08 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284496&group_id=5470 Please note that this 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: traceback module can return undecodable byte strings Initial Comment: The traceback module does not attempt to validate the string representation of exceptions or enforce any character set restrictions. It implements garbage in, garbage out: >>> import traceback >>> try: ... value = u'hello'.encode('utf16') ... raise ValueError('Invalid value %s' % value) ... except: ... traceback.format_exc() ... 'Traceback (most recent call last):\n File "", line 2, in ?\nValueError: Invalid value \xff\xfeh\x00e\x00l\x00l\x00o\x00\n' So if an exception is raised that is not pure ASCII, we end up with a traceback in an unknown encoding, and possibly in no valid encoding at all. This is problematic to applications which work with Unicode strings internally, as when they try to report the error they need to convert the traceback to ASCII and they will get an encoding exception (non Unicode applications tend to just spit out the byte stream and let the user deal with it). Raising an exception that resets your xterm's title is left as an excercise to the reader ;) Should the traceback module sanitize tracebacks it returns, or is the burden on the application (eg. the Python interactive interpreter, cgitb etc.) to sanitize tracebacks using something like: traceback = traceback.decode('ascii', 'replace').encode('ascii', 'backslashreplace') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284496&group_id=5470 From noreply at sourceforge.net Thu Sep 8 08:04:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 23:04:31 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 13:16 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Raymond Hettinger (rhettinger) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 03:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 16:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Thu Sep 8 08:16:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 23:16:01 -0700 Subject: [ python-Bugs-968430 ] error flattening complex smime signed message Message-ID: Bugs item #968430, was opened at 2004-06-07 20:34 Message generated for change (Comment added) made by hta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Please note that this message will contain 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: Ludovico Magnocavallo (ludo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem ---------------------------------------------------------------------- Comment By: Harald Tveit Alvestrand (hta) Date: 2005-09-08 06:16 Message: Logged In: YES user_id=12193 Adding my voice that the bug is important. This is now the chief culprit in breaking signed messages in my usage of signed email on the net; that "signtures are so often broken" is one argument people often use against using signed email. ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-25 09:37 Message: Logged In: YES user_id=42389 In case it is any help, I tried to find the problem in the source. I don't speak python, so I can't fix anything, but I do speak C, so it's quite readable. :-) It seems to me that the problem is in Lib/email/Message.py, in particular in _parseparam and _get_params_preserve. Both these functions call strip() on the object several times (which seems a bit overdone anyway ;-) ), which I presume removes all whitespace around them. I think the whitespace should somehow be saved (not stripping will probably break many programs, so that's not a good idea), so it can be used again when the header is written. set_param should of course also fill this value, so new params get a defined separation (although the empty string is quite acceptable). How this should be implemented I gladly leave to someone who actually speaks Python. :-) ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 11:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 From noreply at sourceforge.net Thu Sep 8 08:18:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 23:18:54 -0700 Subject: [ python-Bugs-1281692 ] urllib violates rfc 959 Message-ID: Bugs item #1281692, was opened at 2005-09-04 10:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 Please note that this message will contain a full 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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 From noreply at sourceforge.net Thu Sep 8 08:36:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2005 23:36:40 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 15:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Nobody/Anonymous (nobody) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-08 01:36 Message: Logged In: YES user_id=80475 I think you're misunderstanding. Direct pickling of arrays does raise a TypeError. It would be nice if it also did as an object attribute; however, I'm not bothered by it enough to spend development time tracing down the issue and then altering otherwise correct Py2.4 code just to generate a prettier message. It is enough for me that the docs do not promise pickling, that a message is generated by a direct attempt to pickle, that the OP's buggy code eventually errors out, and that everything works fine in Py2.5. I have no objections to someone finding a way to generate a better error message but think the time would better be spent elsewhere. >>> from array import array >>> from pickle import dumps, loads >>> ia = array('i', [3,2,1]) >>> ib = loads(dumps(ia)) Traceback (most recent call last): . . . TypeError: can't pickle array objects ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 01:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 05:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 18:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Thu Sep 8 15:51:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 06:51:11 -0700 Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really working Message-ID: Bugs item #1284928, was opened at 2005-09-08 16:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 Please note that this message will contain 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: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 From noreply at sourceforge.net Thu Sep 8 18:37:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 09:37:35 -0700 Subject: [ python-Bugs-1285086 ] urllib.quote is too slow Message-ID: Bugs item #1285086, was opened at 2005-09-08 12: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=1285086&group_id=5470 Please note that this message will contain a full 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: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote is too slow Initial Comment: 'urllib.quote' delegates to '_fast_quote' for the common case that the user has passed no 'safe' argument. However, '_fast_quote' isn't really very fast, especially for the case that it doesn't need to quote anything. Zope (and presumably other web frameworks) can end up calling 'quote' dozens, hundreds, even thousands of times to render a page, which makes this a potentially big win for them. I will attach a speed test script which demonstrates the speed penalty, along with a patch which implements the speedup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 From noreply at sourceforge.net Thu Sep 8 21:39:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 12:39:19 -0700 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 16:16 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 6 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-08 15:39 Message: Logged In: YES user_id=593130 http://python.org/sf/1281556 appears to be a duplicate. You wish to close it too? (I won't, don't know enough here.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-08 02:36 Message: Logged In: YES user_id=80475 I think you're misunderstanding. Direct pickling of arrays does raise a TypeError. It would be nice if it also did as an object attribute; however, I'm not bothered by it enough to spend development time tracing down the issue and then altering otherwise correct Py2.4 code just to generate a prettier message. It is enough for me that the docs do not promise pickling, that a message is generated by a direct attempt to pickle, that the OP's buggy code eventually errors out, and that everything works fine in Py2.5. I have no objections to someone finding a way to generate a better error message but think the time would better be spent elsewhere. >>> from array import array >>> from pickle import dumps, loads >>> ia = array('i', [3,2,1]) >>> ib = loads(dumps(ia)) Traceback (most recent call last): . . . TypeError: can't pickle array objects ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 02:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 06:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 19:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Thu Sep 8 22:17:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 13:17:30 -0700 Subject: [ python-Bugs-1285325 ] Call to cmd.exe fails Message-ID: Bugs item #1285325, was opened at 2005-09-08 16: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=1285325&group_id=5470 Please note that this 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: Alex Luso (delenca) Assigned to: Nobody/Anonymous (nobody) Summary: Call to cmd.exe fails Initial Comment: A python script calling another program through cmd.exe fails on one PC running Win XP but works fine in another. Both computers are running Win XP Pro SP2 and both were set up with the same versions of software (Python 2.4.1) and have the same environmental variables assigned. The specific error reported is: ------- ERROR Window 16 bit MS-DOS Subsystem C:\Python24\python.exe The NTVDM CPU has encountered an illegal instruction CS:0552 IP:ad0d5 OP:8f 66 4c 8f 4f Choose 'Close' to terminate application ------- The script that causes the problem is: ------------ import os import sys debug = 1 rd = os.environ['RIBBONS_HOME'] cmd = "python %s/elmo/ribbonsData.py" % rd if debug: print cmd os.system(cmd) while 1: pass ------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285325&group_id=5470 From noreply at sourceforge.net Thu Sep 8 22:29:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 13:29:17 -0700 Subject: [ python-Bugs-1285325 ] Call to cmd.exe fails Message-ID: Bugs item #1285325, was opened at 2005-09-08 16:17 Message generated for change (Settings changed) made by delenca You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285325&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Submitted By: Alex Luso (delenca) Assigned to: Nobody/Anonymous (nobody) Summary: Call to cmd.exe fails Initial Comment: A python script calling another program through cmd.exe fails on one PC running Win XP but works fine in another. Both computers are running Win XP Pro SP2 and both were set up with the same versions of software (Python 2.4.1) and have the same environmental variables assigned. The specific error reported is: ------- ERROR Window 16 bit MS-DOS Subsystem C:\Python24\python.exe The NTVDM CPU has encountered an illegal instruction CS:0552 IP:ad0d5 OP:8f 66 4c 8f 4f Choose 'Close' to terminate application ------- The script that causes the problem is: ------------ import os import sys debug = 1 rd = os.environ['RIBBONS_HOME'] cmd = "python %s/elmo/ribbonsData.py" % rd if debug: print cmd os.system(cmd) while 1: pass ------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285325&group_id=5470 From noreply at sourceforge.net Fri Sep 9 00:31:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 15:31:11 -0700 Subject: [ python-Bugs-1285440 ] Digest Authentication not working in all cases Message-ID: Bugs item #1285440, was opened at 2005-09-08 22: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=1285440&group_id=5470 Please note that this 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: Jakob Simon-Gaarde (jsgaarde99) Assigned to: Nobody/Anonymous (nobody) Summary: Digest Authentication not working in all cases Initial Comment: I feel I better report this as a bug, since urllib2's digest authentication handler fails where others succeed. I have been trying to authenticate against an IIS server at Microsoft hosting MapPoint SOAP services. The host requres Digest authentication but urllib2 fails to authenticate with the credentials I have recieved. When I authenticate using firefox the browser I imediately succeed and gain access to a browsable service API. C# dotnet's SOAP client also succeeds in authenticating. Therefore I have made my own conclusion that urllib.HTTPDigestAuthHandler must be doing something wrong. I can provide the authentication credentials needed to test and correct the bug, but this would have to be through an email, so I don't break to many laws. In the attached file is the script I have used to provoke the digest challenge. Jakob Simon-Gaarde ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285440&group_id=5470 From noreply at sourceforge.net Fri Sep 9 03:01:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 18:01:07 -0700 Subject: [ python-Bugs-1285086 ] urllib.quote is too slow Message-ID: Bugs item #1285086, was opened at 2005-09-08 11:37 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 Please note that this message will contain a full 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: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote is too slow Initial Comment: 'urllib.quote' delegates to '_fast_quote' for the common case that the user has passed no 'safe' argument. However, '_fast_quote' isn't really very fast, especially for the case that it doesn't need to quote anything. Zope (and presumably other web frameworks) can end up calling 'quote' dozens, hundreds, even thousands of times to render a page, which makes this a potentially big win for them. I will attach a speed test script which demonstrates the speed penalty, along with a patch which implements the speedup. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-09-08 20:01 Message: Logged In: YES user_id=2772 Tested on Python 2.4.0. The patch fails on the first chunk because the list of imports don't match. The urllib_fast_quote_speed_test.py doesn't run once urllib has been patched. I reverted the patch to urllib.py and re-ran. I got "faster" values from 0.758 to 0.964. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 From noreply at sourceforge.net Fri Sep 9 04:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 19:30:33 -0700 Subject: [ python-Bugs-1285086 ] urllib.quote is too slow Message-ID: Bugs item #1285086, was opened at 2005-09-08 12:37 Message generated for change (Comment added) made by tseaver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 Please note that this message will contain a full 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: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote is too slow Initial Comment: 'urllib.quote' delegates to '_fast_quote' for the common case that the user has passed no 'safe' argument. However, '_fast_quote' isn't really very fast, especially for the case that it doesn't need to quote anything. Zope (and presumably other web frameworks) can end up calling 'quote' dozens, hundreds, even thousands of times to render a page, which makes this a potentially big win for them. I will attach a speed test script which demonstrates the speed penalty, along with a patch which implements the speedup. ---------------------------------------------------------------------- >Comment By: Tres Seaver (tseaver) Date: 2005-09-08 22:30 Message: Logged In: YES user_id=127625 I'm attaching a patch against 2.4's version ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-09-08 21:01 Message: Logged In: YES user_id=2772 Tested on Python 2.4.0. The patch fails on the first chunk because the list of imports don't match. The urllib_fast_quote_speed_test.py doesn't run once urllib has been patched. I reverted the patch to urllib.py and re-ran. I got "faster" values from 0.758 to 0.964. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 From noreply at sourceforge.net Fri Sep 9 04:35:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Sep 2005 19:35:58 -0700 Subject: [ python-Bugs-1285086 ] urllib.quote is too slow Message-ID: Bugs item #1285086, was opened at 2005-09-08 12:37 Message generated for change (Comment added) made by tseaver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 Please note that this message will contain a full 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: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote is too slow Initial Comment: 'urllib.quote' delegates to '_fast_quote' for the common case that the user has passed no 'safe' argument. However, '_fast_quote' isn't really very fast, especially for the case that it doesn't need to quote anything. Zope (and presumably other web frameworks) can end up calling 'quote' dozens, hundreds, even thousands of times to render a page, which makes this a potentially big win for them. I will attach a speed test script which demonstrates the speed penalty, along with a patch which implements the speedup. ---------------------------------------------------------------------- >Comment By: Tres Seaver (tseaver) Date: 2005-09-08 22:35 Message: Logged In: YES user_id=127625 Note that the speed test script shows equivalent speedups for both 2.3 and 2.4, ranging from 90% (for the empty string) down to 73% (for a string with a single character). The more "normal" cases range from 82% to 89% speedups. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-09-08 22:30 Message: Logged In: YES user_id=127625 I'm attaching a patch against 2.4's version ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-09-08 21:01 Message: Logged In: YES user_id=2772 Tested on Python 2.4.0. The patch fails on the first chunk because the list of imports don't match. The urllib_fast_quote_speed_test.py doesn't run once urllib has been patched. I reverted the patch to urllib.py and re-ran. I got "faster" values from 0.758 to 0.964. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285086&group_id=5470 From noreply at sourceforge.net Fri Sep 9 11:40:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Sep 2005 02:40:24 -0700 Subject: [ python-Bugs-1285809 ] re special sequence '\w' Message-ID: Bugs item #1285809, was opened at 2005-09-09 09: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=1285809&group_id=5470 Please note that this 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: re special sequence '\w' Initial Comment: >>> rexp = re.compile('\w', re.LOCALE) >>> rexp.findall('_') ['_'] >>> '_'.isalnum() False While the Python docs say, that the underscore is supported, I strongly ask why this is so? The problem is that I want to match a sequence of alphanumeric characters but excluding the underscore. If you defined \w to not support "_" anymore, people could easily check for the "_" as well with \w|_ . My locale is "de_DE" but it does affect other locales as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285809&group_id=5470 From noreply at sourceforge.net Fri Sep 9 15:08:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Sep 2005 06:08:17 -0700 Subject: [ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with unicode paths Message-ID: Bugs item #1283895, was opened at 2005-09-07 22:30 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 Please note that this 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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.abspath() / os.chdir() buggy with unicode paths Initial Comment: Hi, Under Windows Explorer, one can create directory names using characters not belonging to the user locale. For example, one of our users created a directory named "C:\Mes Documents\コピー ～ solipsis_svn". Unfortunately, when trying to manipulate such a pathname, os.path.abspath() and os.chdir() don't work hand in hand. os.path.abspath() uses the garbled directory name as displayed by the command prompt and then os.chdir() refuses the path: C:\>cd "C:\Mes Documents\??? ~ solipsis_svn" C:\Mes Documents\??? ~ solipsis_svn>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import os >>> os.curdir '.' >>> os.path.abspath(os.curdir) 'C:\Mes Documents\??? ~ solipsis_svn' >>> os.chdir(os.path.abspath(os.curdir)) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'C:\Mes Documents\??? ~ solipsis_svn' >>> ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2005-09-09 23:08 Message: Logged In: YES user_id=12579 This is using byte string arguments causing byte string processing rather than unicode calls with unicode processing. Windows code that may encounter file paths outside the default locale should stick to unicode for paths. Try converting os.curdir to unicode before calling other functions: os.path.abspath(unicode(os.curdir)) ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-09-07 22:36 Message: Logged In: YES user_id=133955 > "C:\Mes Documents\コピー ～ solipsis_svn" Gasp. Sourceforge escapes HTML entities instead of showing the real characters... These are Japanese characters, btw. It's easy to copy/paste some Japanese characters from a Web site and paste them into Windows Explorer to create a directory (at least it works with Mozilla Firefox). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 From noreply at sourceforge.net Fri Sep 9 21:54:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Sep 2005 12:54:53 -0700 Subject: [ python-Bugs-1281556 ] exception when unpickling array.array objects Message-ID: Bugs item #1281556, was opened at 2005-09-04 05:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 Please note that this message will contain a full 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: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: exception when unpickling array.array objects Initial Comment: Note 1: same error for pickle and cPickle Note 2: pickle.dumps and cPickle.dumps produce different results [see below] -- is this expected? Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, cPickle, array >>> ia = array.array('i',[3,2,1]) >>> ia array('i', [3, 2, 1]) >>> pia = pickle.dumps(ia, -1) >>> pia '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> cia = cPickle.dumps(ia, -1) >>> pia == cia False >>> cia '\x80\x02carray\narray\nq\x01)\x81q\x02.' >>> pickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) >>> pickle.loads(cia) [same as above] >>> cPickle.loads(pia) Traceback (most recent call last): File "", line 1, in ? TypeError: array() takes at least 1 argument (0 given) >>> cPickle.loads(cia) [same as above] >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-09 14:54 Message: Logged In: YES user_id=80475 Duplicate of 1281383. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 05:46 Message: Logged In: YES user_id=480138 Refer bug report 1281383. Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281556&group_id=5470 From noreply at sourceforge.net Sat Sep 10 05:45:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Sep 2005 20:45:52 -0700 Subject: [ python-Feature Requests-1285086 ] urllib.quote is too slow Message-ID: Feature Requests item #1285086, was opened at 2005-09-08 11:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1285086&group_id=5470 Please note that this message will contain 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: 2 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.quote is too slow Initial Comment: 'urllib.quote' delegates to '_fast_quote' for the common case that the user has passed no 'safe' argument. However, '_fast_quote' isn't really very fast, especially for the case that it doesn't need to quote anything. Zope (and presumably other web frameworks) can end up calling 'quote' dozens, hundreds, even thousands of times to render a page, which makes this a potentially big win for them. I will attach a speed test script which demonstrates the speed penalty, along with a patch which implements the speedup. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-09 22:45 Message: Logged In: YES user_id=80475 Checked in a speed-up for Py2.5. See Lib/urllib.py 1.169. The check-in provides fast-quoting for all cases (not just for the default safe argument). Even the fast path is quicker. With translation for both safe and unsafe characters, it saves len(s) trips through the eval loop, computes of non-safe replacements just once, and eliminates the if-logic. The new table is collision free and has no failed lookups, so each lookup requires exactly one probe. One my machine, timings improved by a factor of two to three depending on the length of input and number of escaped characters. The check-in also simplifies and speeds-up quote_plus() by using str.replace() instead of a split Leaving this SF report open because the OP's idea may possibly provide further improvement -- the checkin itself was done because it is a clear win over the existing version. The OP's patch uses regexps to short-circuit when no changes are needed. Unless the regexp is cheap and short-circuits often, the cost of testing will likely exceed the average amount saved. Determining whether the regexp is cheaper than the checked-in version just requires a few timings. But, determining the short-circuit percentage requires collecting statistics from real programs with real data. For the idea to be a winner, regexps have to be much faster than the map/lookup/join step AND the short-circuit case must occur frequently. Am lowering the priority until a better patch is received along with timings and statistical evidence demonstrating a significant improvement. Also, reclassifying as a Feature Request because the existing code is functioning as documented and passing tests. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-09-08 21:35 Message: Logged In: YES user_id=127625 Note that the speed test script shows equivalent speedups for both 2.3 and 2.4, ranging from 90% (for the empty string) down to 73% (for a string with a single character). The more "normal" cases range from 82% to 89% speedups. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-09-08 21:30 Message: Logged In: YES user_id=127625 I'm attaching a patch against 2.4's version ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-09-08 20:01 Message: Logged In: YES user_id=2772 Tested on Python 2.4.0. The patch fails on the first chunk because the list of imports don't match. The urllib_fast_quote_speed_test.py doesn't run once urllib has been patched. I reverted the patch to urllib.py and re-ran. I got "faster" values from 0.758 to 0.964. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1285086&group_id=5470 From noreply at sourceforge.net Mon Sep 12 13:40:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 04:40:00 -0700 Subject: [ python-Bugs-1288615 ] Python code.interact() and UTF-8 locale Message-ID: Bugs item #1288615, was opened at 2005-09-12 13: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=1288615&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Python code.interact() and UTF-8 locale Initial Comment: Hi, I found a bug in Python interactive command line (program python alone: looks to be code.interact() function in code.py). With UTF-8 locale, the command << u"?" >> returns << u'\xc3\xa9' >> and not << u'\xE9' >>. Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3 \xA9 in UTF-8. Another example of the bug: #-*- coding: UTF-8 -*- code = "u\%s\" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Result : u'\xc3\xa9' Excepted result : u'\xe9' After long hours of debuging (read Python documentation, debug Python with gdb, read Python C source code, ...) I found the origin of the bug: function parsestr() in Python/compile.c. This function translate a string to a unicode string (or a classic string). The problem is when the encoding declaration doesn't exist: the string isn't converted. Solution to the first code: #-*- coding: ascii -*- code = """#-*- coding: UTF-8 -*- u\%s\""" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Proposition: u"..." and unicode("...") should use sys.stdin.encoding by default. They will work as unicode("...", sys.stdin.encoding). Or easier, the compiler should use sys.stdin.encoding and not ascii as default encoding. Sorry if someone already reported this bug. And, is it a bug or a feature ? ;-) Bye, Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470 From noreply at sourceforge.net Mon Sep 12 14:46:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 05:46:32 -0700 Subject: [ python-Bugs-1288615 ] Python code.interact() and UTF-8 locale Message-ID: Bugs item #1288615, was opened at 2005-09-12 13:40 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Python code.interact() and UTF-8 locale Initial Comment: Hi, I found a bug in Python interactive command line (program python alone: looks to be code.interact() function in code.py). With UTF-8 locale, the command << u"?" >> returns << u'\xc3\xa9' >> and not << u'\xE9' >>. Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3 \xA9 in UTF-8. Another example of the bug: #-*- coding: UTF-8 -*- code = "u\%s\" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Result : u'\xc3\xa9' Excepted result : u'\xe9' After long hours of debuging (read Python documentation, debug Python with gdb, read Python C source code, ...) I found the origin of the bug: function parsestr() in Python/compile.c. This function translate a string to a unicode string (or a classic string). The problem is when the encoding declaration doesn't exist: the string isn't converted. Solution to the first code: #-*- coding: ascii -*- code = """#-*- coding: UTF-8 -*- u\%s\""" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Proposition: u"..." and unicode("...") should use sys.stdin.encoding by default. They will work as unicode("...", sys.stdin.encoding). Or easier, the compiler should use sys.stdin.encoding and not ascii as default encoding. Sorry if someone already reported this bug. And, is it a bug or a feature ? ;-) Bye, Haypo ---------------------------------------------------------------------- >Comment By: STINNER Victor (haypo) Date: 2005-09-12 14:46 Message: Logged In: YES user_id=365388 Ok ok, after long discution with RexFi on IRC, I understood that Python can't *guess* string encoding ... I agree with that, system locale or source encoding are not a good choice. But ... Python console have a bug. It uses raw_input(). So I wrote a patch to just add the right unicode cast. But Python console don't looks to be code.interact(). I attach the patch to this comment. Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470 From noreply at sourceforge.net Mon Sep 12 23:41:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 14:41:10 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Tue Sep 13 00:04:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 15:04:55 -0700 Subject: [ python-Bugs-1289136 ] distutils extension library path bug on cygwin Message-ID: Bugs item #1289136, was opened at 2005-09-12 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=1289136&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils extension library path bug on cygwin Initial Comment: A while back I reported a problem on the Cygwin mailing list where all python extension packages would fail "python setup.py install" at the link step due to a mangled lib dir (-L) option. distutils was producing a link line with "-L.", instead of the desired "-L/usr/lib/python2.4/config". I've finally rooted out the cause of this problem. The relevant code is the if-block starting at line 188 of: /usr/lib/python2.4/distutils/command/build_ext.py I've reproduced that block here for clarity of discussion (indentation truncated for redability) if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') The test "string.find(...) != -1" attempts to test whether "/usr" appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin. (i.e. string.find("/bin/python","/usr") == -1) Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. The user-side workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+"bin") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 From noreply at sourceforge.net Tue Sep 13 02:23:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 17:23:41 -0700 Subject: [ python-Bugs-1289210 ] PyDoc crashes at os.py line 133 Message-ID: Bugs item #1289210, was opened at 2005-09-12 20: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=1289210&group_id=5470 Please note that this 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: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. ------------------------------------------------------------------------------------------------------------ The above works OK but the following - advertised in the PyDoc.py comment - fails. ----------------------------------------------------------------------------------------------------------- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax ------------------------------------------------------------------------------------------------------------ Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) ------------------------------------------------------------------------------------------------ The above "from X import" usage appears legitimate. Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 From noreply at sourceforge.net Tue Sep 13 06:10:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 21:10:16 -0700 Subject: [ python-Bugs-1289210 ] PyDoc crashes at os.py line 133 Message-ID: Bugs item #1289210, was opened at 2005-09-12 19:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this 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: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. ------------------------------------------------------------------------------------------------------------ The above works OK but the following - advertised in the PyDoc.py comment - fails. ----------------------------------------------------------------------------------------------------------- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax ------------------------------------------------------------------------------------------------------------ Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) ------------------------------------------------------------------------------------------------ The above "from X import" usage appears legitimate. Colin W. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 From noreply at sourceforge.net Tue Sep 13 06:11:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Sep 2005 21:11:30 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 16:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) >Assigned to: Tim Peters (tim_one) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Tue Sep 13 13:15:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 04:15:05 -0700 Subject: [ python-Bugs-1289210 ] PyDoc crashes at os.py line 133 Message-ID: Bugs item #1289210, was opened at 2005-09-12 20:23 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this 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: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. ------------------------------------------------------------------------------------------------------------ The above works OK but the following - advertised in the PyDoc.py comment - fails. ----------------------------------------------------------------------------------------------------------- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax ------------------------------------------------------------------------------------------------------------ Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) ------------------------------------------------------------------------------------------------ The above "from X import" usage appears legitimate. Colin W. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-09-13 07:15 Message: Logged In: YES user_id=285587 Response to R Hettinger 2005-09-13 00:10 I do have Python 2.4 and 2.3 installed but the environment variable PYTHON is set to C:\Python24. I have checked to see that no Python process is running before repeating the test this morning. I get the same results. Is there any other check I should make? Colin W. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 From noreply at sourceforge.net Tue Sep 13 14:02:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 05:02:23 -0700 Subject: [ python-Bugs-1289210 ] PyDoc crashes at os.py line 133 Message-ID: Bugs item #1289210, was opened at 2005-09-12 19:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc crashes at os.py line 133 Initial Comment: Details of the attempted runs are given below: C:\Python24\Lib>python pydoc.py sys Help on built-in module sys: NAME sys FILE (built-in) MODULE DOCS http://www.python.org/doc/current/lib/module-sys.html etc. etc. ------------------------------------------------------------------------------------------------------------ The above works OK but the following - advertised in the PyDoc.py comment - fails. ----------------------------------------------------------------------------------------------------------- C:\Python24\Lib>pydoc sys 'import site' failed; use -v for traceback Traceback (most recent call last): File "C:\Python24\Lib\pydoc.py", line 54, in ? import sys, imp, os, re, types, inspect, __builtin__ File "C:\Python24\Lib\os.py", line 133 from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, ^ SyntaxError: invalid syntax ------------------------------------------------------------------------------------------------------------ Lines 132 to 134 of os.py: sys.modules['os.path'] = path from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) ------------------------------------------------------------------------------------------------ The above "from X import" usage appears legitimate. Colin W. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 07:02 Message: Logged In: YES user_id=80475 When you write, "pydoc sys", your relying on a file association for py files to get run by python23. The association is not controlled by the PYTHON environment variable. Anyway, it is evident from the initial report that there is not a bug. When "python pydoc.py sys" runs fine, it means that your sys file is okay. When it fails using "pydoc sys" it means an earlier version of the interpreter is being run on the Py2.4 sys file. To convince yourself, change to c:\python23\lib and run "pydoc sys". ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-09-13 06:15 Message: Logged In: YES user_id=285587 Response to R Hettinger 2005-09-13 00:10 I do have Python 2.4 and 2.3 installed but the environment variable PYTHON is set to C:\Python24. I have checked to see that no Python process is running before repeating the test this morning. I get the same results. Is there any other check I should make? Colin W. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:10 Message: Logged In: YES user_id=80475 This is probably invalid. It looks like you may have multiple python versions running on your system and that the pydoc batch file is invoking an earlier version of the interpreter that doesn't understand multiline imports). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289210&group_id=5470 From noreply at sourceforge.net Tue Sep 13 19:55:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 10:55:04 -0700 Subject: [ python-Bugs-1290333 ] cjkcodec compile error under AIX 5.2 on symbol 100_encode Message-ID: Bugs item #1290333, was opened at 2005-09-13 13:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 Please note that this 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: Deron Meranda (dmeranda) Assigned to: Nobody/Anonymous (nobody) Summary: cjkcodec compile error under AIX 5.2 on symbol 100_encode Initial Comment: Trying to compile Python 2.4.1 under AIX 5.2 with the native cc compiler. When compiling the module cjkcodecs the compiler will fail with these errors on the source file Modules/cjkcodecs/_codecs_cn.c building '_codecs_cn' extension cc -DNDEBUG -O -I. -I/home/psgtools/aix52/build/Python-2.4.1/./Include -I/opt/cmax/psgtools/include -I/home/psgtools/aix52/build/Python-2.4.1/Include -I/home/psgtools/aix52/build/Python-2.4.1 -c /home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c -o build/temp.aix-5.2-2.4/_codecs_cn.o "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-206 (S) Suffix of integer constant 100_encode is not valid. "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-196 (W) Initialization between types "int(*)(union {...}*,const void*,const unsigned long**,unsigned long,unsigned char**,unsigned long,int)" and "int" is not allowed. and so on. This is happening because of the "hz" codec. Due to the way the source file uses the C preprocessor macro, and the fact that the preprocessor symbol "hz" is predefined as 100 on this platform, it is producing invalid lecical symbols such as "100_encode". The simple solution is to insert the following line in the source file immediately before the first reference to the name "hz": #undef hz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 From noreply at sourceforge.net Tue Sep 13 20:59:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 11:59:13 -0700 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 11:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Edward Loper (edloper) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-13 14:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 13:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 09:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-14 22:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Tue Sep 13 21:03:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 12:03:49 -0700 Subject: [ python-Bugs-1290382 ] --no-compile option has no effect Message-ID: Bugs item #1290382, was opened at 2005-09-13 15:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: --no-compile option has no effect Initial Comment: ZODB ships with a .py file containing a syntax error (that's intentional, it's part of a test of the zope.testing component). So, whenever somone does setup.py install they see a complaint about this file, like byte-compiling /home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py to sampletests_i.pyc File "/home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py", line 15 importx unittest ^ SyntaxError: invalid syntax That's fine. The problem is that doing setup.py install --no-compile makes no difference -- it still tries to compile everything to .pyc. True at least in Python 2.3.5 and 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 From noreply at sourceforge.net Tue Sep 13 21:20:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 12:20:11 -0700 Subject: [ python-Bugs-1290382 ] --no-compile option has no effect Message-ID: Bugs item #1290382, was opened at 2005-09-13 15:03 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: --no-compile option has no effect Initial Comment: ZODB ships with a .py file containing a syntax error (that's intentional, it's part of a test of the zope.testing component). So, whenever somone does setup.py install they see a complaint about this file, like byte-compiling /home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py to sampletests_i.pyc File "/home/tim/glom/lib/python2.4/site- packages/zope/testing/testrunner- ex/sample2/sampletests_i.py", line 15 importx unittest ^ SyntaxError: invalid syntax That's fine. The problem is that doing setup.py install --no-compile makes no difference -- it still tries to compile everything to .pyc. True at least in Python 2.3.5 and 2.4.1. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-13 15:20 Message: Logged In: YES user_id=31435 Closing this as invalid -- it appears to be unique to setup.py thingies created by Zope's zpkgtools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290382&group_id=5470 From noreply at sourceforge.net Tue Sep 13 22:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 13:12:17 -0700 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Comment added) made by bjoti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) Assigned to: Edward Loper (edloper) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Bjorn Tillenius (bjoti) Date: 2005-09-13 22:12 Message: Logged In: YES user_id=1032069 Attaching new version of the patch that will apply cleanly against latest CVS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-13 20:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 19:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 15:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-15 04:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Wed Sep 14 00:27:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 15:27:40 -0700 Subject: [ python-Bugs-504219 ] locale.resetlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-15 20:56 Message generated for change (Comment added) made by meonkeys 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: Adam Monsen (meonkeys) Date: 2005-09-13 15:27 Message: Logged In: YES user_id=259388 I'm seeing this error on Fedora Core 4: Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] 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 "/usr/lib/python2.4/locale.py", line 389, in resetlocale _setlocale(category, _build_localename(getdefaultlocale())) locale.Error: unsupported locale setting ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 11: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 10: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 05: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 03: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-15 21: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 Wed Sep 14 00:50:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 15:50:55 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15: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=1290505&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Nobody/Anonymous (nobody) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Sep 14 00:57:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 15:57:43 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by meonkeys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Nobody/Anonymous (nobody) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Sep 14 01:18:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2005 16:18:00 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) >Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Sep 14 10:58:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 01:58:54 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 21:59 Message generated for change (Comment added) made by niemeyer 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: Closed >Resolution: Fixed 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: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 08:58 Message: Logged In: YES user_id=7887 Fixed in: Lib/sre_parse.py: 1.64 -> 1.65 Lib/test/test_re.py: 1.55 -> 1.56 Misc/NEWS: 1.1360 -> 1.1361 Notice that perl will also handle constructs like '{,2}' as literals, while Python will consider them as '{0,2}'. I think it's too late to change that one though, as this behavior may be relied upon in code out there. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 22:16 Message: Logged In: YES user_id=1188172 No, you're the expert, so you'll get the honor of fixing it. :P ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-08-31 22:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 21:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 19: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 18: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 18: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 15: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 08: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 11: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 21: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 21: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 20: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 20: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 16: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 Sep 14 11:17:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 02:17:38 -0700 Subject: [ python-Bugs-1113484 ] document {m} regex matcher wrt empty matches Message-ID: Bugs item #1113484, was opened at 2005-01-31 21:46 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Wummel (calvin) Assigned to: Gustavo Niemeyer (niemeyer) Summary: document {m} regex matcher wrt empty matches Initial Comment: The {m} matcher seems not to be applicable to (some) empty matches. For example this will raise a regex compile error: >>> re.compile("(a*){4}") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/sre.py", line 179, in compile return _compile(pattern, flags) File "/usr/lib/python2.3/sre.py", line 230, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat However this matcher is compiled without error: >>> re.compile("(\ba*){4}") <_sre.SRE_Pattern object at 0xb7f86c58> I don't know why the first example gives an error, but it should perhaps be mentioned in the documentation about the {} regex operator. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 09:17 Message: Logged In: YES user_id=7887 Would you be able to come up with an example that would be useful for that kind of construction? "(a*){4}" will always match "a" as many times as possible, and than match the empty string 3 more times. So it has the effect of "a*", but in addition will kill the grouping effect since the given group will always be empty. With that in mind considering it as a syntax error seems correct. Do you agree? ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-02-03 17:06 Message: Logged In: YES user_id=9205 Oops, it should have been: >>> re.compile(r"(\ba*){4}") And now the error is consistent (now tested in Python 2.4 instead of 2.3): Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/sre.py", line 180, in compile return _compile(pattern, flags) File "/usr/lib/python2.4/sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat So it seems that {m} operator does not like potentially empty matches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470 From noreply at sourceforge.net Wed Sep 14 11:34:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 02:34:25 -0700 Subject: [ python-Bugs-1058786 ] r'\10' as replacement pattern loops in compilation Message-ID: Bugs item #1058786, was opened at 2004-11-02 12:39 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Gustavo Niemeyer (niemeyer) Summary: r'\10' as replacement pattern loops in compilation Initial Comment: The following program loops under at least Solaris 9 on SPARC and Linux (kernel 2.6) in x86. From tracebacks, it seems to be in the internal compilation of the pattern r'\10'. from re import compile line = "" pat = compile(12 * r'(\d+)') ltarget = float(pat.sub(r'\10',line)) print ltarget ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 09:34 Message: Logged In: YES user_id=7887 It's fixed in the 2.4+, and there's a workaround for previous versions, so I'm closing that as wontfix for 2.3. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 11:45 Message: Logged In: YES user_id=1188172 Setting group to Python 2.3. If there won't be a 2.3.6 in the future, it can be closed. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2004-11-02 13:28 Message: Logged In: YES user_id=652073 I have also checked, and it is fixed. From my point of view, it isn't worth backporting, as I can upgrade and don't mind using a beta version. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-02 13:07 Message: Logged In: YES user_id=6656 It does seem to be fixed in 2.4, but not in 2.3(.3, anyway). I know some of the re changes for 2.4 are fairly large, so I don't know whether the fix is a backport candidate for 2.3.5. Gustavo might know. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-02 13:07 Message: Logged In: YES user_id=469548 I get the following on Python 2.4/Linux 2.6.8, so it does seem to be fixed: >>> from re import compile >>> line = "" >>> pat = compile(12 * r'(\d+)') >>> ltarget = float(pat.sub(r'\10',line)) Traceback (most recent call last): File "", line 1, in ? ValueError: empty string for float() ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 13:00 Message: Logged In: YES user_id=38376 If you need a workaround for 2.2, use a sub callback: http://effbot.org/zone/re-sub.htm#callbacks ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 12:58 Message: Logged In: YES user_id=38376 Cannot check this right now, but I'm 99% sure that this has been fixed in 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&group_id=5470 From noreply at sourceforge.net Wed Sep 14 12:58:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 03:58: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: Closed Resolution: Fixed 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-09-14 12:58 Message: Logged In: YES user_id=1188172 Will you backport the fix? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 10:58 Message: Logged In: YES user_id=7887 Fixed in: Lib/sre_parse.py: 1.64 -> 1.65 Lib/test/test_re.py: 1.55 -> 1.56 Misc/NEWS: 1.1360 -> 1.1361 Notice that perl will also handle constructs like '{,2}' as literals, while Python will consider them as '{0,2}'. I think it's too late to change that one though, as this behavior may be relied upon in code out there. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:16 Message: Logged In: YES user_id=1188172 No, you're the expert, so you'll get the honor of fixing it. :P ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-01 00:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- 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 Wed Sep 14 13:40:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 04:40:38 -0700 Subject: [ python-Bugs-1290333 ] cjkcodec compile error under AIX 5.2 on symbol 100_encode Message-ID: Bugs item #1290333, was opened at 2005-09-14 02:55 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 Please note that this 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: Deron Meranda (dmeranda) >Assigned to: Hye-Shik Chang (perky) Summary: cjkcodec compile error under AIX 5.2 on symbol 100_encode Initial Comment: Trying to compile Python 2.4.1 under AIX 5.2 with the native cc compiler. When compiling the module cjkcodecs the compiler will fail with these errors on the source file Modules/cjkcodecs/_codecs_cn.c building '_codecs_cn' extension cc -DNDEBUG -O -I. -I/home/psgtools/aix52/build/Python-2.4.1/./Include -I/opt/cmax/psgtools/include -I/home/psgtools/aix52/build/Python-2.4.1/Include -I/home/psgtools/aix52/build/Python-2.4.1 -c /home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c -o build/temp.aix-5.2-2.4/_codecs_cn.o "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-206 (S) Suffix of integer constant 100_encode is not valid. "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-196 (W) Initialization between types "int(*)(union {...}*,const void*,const unsigned long**,unsigned long,unsigned char**,unsigned long,int)" and "int" is not allowed. and so on. This is happening because of the "hz" codec. Due to the way the source file uses the C preprocessor macro, and the fact that the preprocessor symbol "hz" is predefined as 100 on this platform, it is producing invalid lecical symbols such as "100_encode". The simple solution is to insert the following line in the source file immediately before the first reference to the name "hz": #undef hz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 From noreply at sourceforge.net Wed Sep 14 19:32:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 10:32:35 -0700 Subject: [ python-Bugs-1284341 ] re nested conditional matching (?()) doesn't work Message-ID: Bugs item #1284341, was opened at 2005-09-08 00:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re nested conditional matching (?()) doesn't work Initial Comment: Here is a simple regular expression that should match \o, \{o}, {\o}, and \{o}}: (This example arose as a simplification of a general accent matcher for LaTeX/BibTeX.) r = re.compile(r'(\{)?\"(\{)?(.)(?(2)\})(?(1)\})') However, it fails on two out of four of the desired matches: r.search(r'\o) ## returns None (WRONG) r.search(r\{o}').group() ## returns '\"{o}"' (CORRECT) r.search(r'{\o).group() ## returns \"o} (WRONG) r.search(r{\{o}}').group() ## returns '{\"{o}}' (CORRECT) The third case is particularly bizarre. Incidentally, the behavior is different if '(.)' is replaced by '.' (incorrect in different ways). I have tested this on Python 2.4.1 on Windows and a CVS version on Linux. I do not believe it is a platform issue. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 19:32 Message: Logged In: YES user_id=1188172 The fix is already in Python 2.4 CVS, so I'm closing as Fixed. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2005-09-08 01:09 Message: Logged In: YES user_id=265183 Whoops, I just updated CVS to the latest HEAD and discovered that the problem has already been solved. Nice work! Sorry about the extraneous report, but let me turn this into a request that the fix go into 2.4.2, not just 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470 From noreply at sourceforge.net Wed Sep 14 19:53:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 10:53:05 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 08:49 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule)?; Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 13:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-08-16 09:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 09:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Wed Sep 14 20:09:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 11:09:13 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 12:49 Message generated for change (Comment added) made by bheld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule)?; Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. ---------------------------------------------------------------------- >Comment By: Ben Held (bheld) Date: 2005-09-14 18:09 Message: Logged In: YES user_id=1327580 This behavior is evident with Python 2.3.5 built on Windows with VC++ 6.0. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 17:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-08-16 13:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 13:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Wed Sep 14 20:17:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 11:17:20 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 04:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) Assigned to: Martin v. L?wis (loewis) Summary: test_pwd fails on 64bit system (Opteron) Initial Comment: test test_pwd failed -- Traceback (most recent call last): File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum $ cat /proc/version Linux version 2.4.21-20.ELsmp (bhcompile at dolly.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18 20:34:58 EDT 2004 Processor is AMD Opteron 2.4MHz ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-14 14:17 Message: Logged In: YES user_id=6380 Martin, IMO you can close this now that I've checked in the AIX patch which should address this with the i->I change suggested in a comment below. (patch 1284289) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-07 17:16 Message: Logged In: YES user_id=33168 See this patch which looks like it may fix the same problem (among others). https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 14:17 Message: Logged In: YES user_id=1188172 Is the patch safe to apply? I think so, I haven't seen a negative uid/gid yet. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-09-01 08:57 Message: Logged In: YES user_id=1035073 The suggested patch by heffler worked brilliantly for my 64 bit environment. Thanks. My bug submission was on 2005-08-03 14:40. ---------------------------------------------------------------------- Comment By: Marvin Heffler (heffler) Date: 2005-08-11 14:19 Message: Logged In: YES user_id=298758 I think I figued out the problem with python handling uids and gids greater than 2147483647 when using the grp.getgrgid and pwd.getpwuid functions. Both of the functions call PyArg_ParseTuple with a type of "i", thus indicating the argument is a signed integer. Instead they should be using "I" (upper-case i) for an unsigned integer. The fix is fairly simple. Here are the two patches necessary to the python source: diff -Naur Python-2.4.orig/Modules/grpmodule.c Python- 2.4/Modules/grpmodule.c --- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 16:06:00.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -0400 @@ -87,7 +87,7 @@ { int gid; struct group *p; - if (!PyArg_ParseTuple(args, "i:getgrgid", &gid)) + if (!PyArg_ParseTuple(args, "I:getgrgid", &gid)) return NULL; if ((p = getgrgid(gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python- 2.4/Modules/pwdmodule.c --- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 16:07:23.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -0400 @@ -104,7 +104,7 @@ { int uid; struct passwd *p; - if (!PyArg_ParseTuple(args, "i:getpwuid", &uid)) + if (!PyArg_ParseTuple(args, "I:getpwuid", &uid)) return NULL; if ((p = getpwuid(uid)) == NULL) { PyErr_Format(PyExc_KeyError, Hopefully, someone from the python project can verify my patch and get it incorporated into a future release. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-08-03 14:40 Message: Logged In: YES user_id=1035073 The same error occurs for an Intel P4-521 processor running RedHat Enterprise Linux WS v4 Intel EM64T 64bit. $ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005 test test_grp failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum test test_pwd failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-03-17 04:20 Message: Logged In: YES user_id=358087 I've tried the patch - no luck :-( I'm stealing time on these machines since they belong to another group. However I see that SF's compile farm (http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) have an AMD64 host (amd64-linux1) Maybe you can shorten the loop ... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 17:17 Message: Logged In: YES user_id=89016 On a 32bit system adding the line nobody:x:4294967294:65534:nobody:/:/bin/false to /etc/passwd pwd.getpwall() gives me an entry: ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') and pwd.getpwuid(-2) gives me ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') Maybe for 64bit systems the SETI macro should use PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can you try the following patch? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-17 03:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-16 20:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 04:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Wed Sep 14 21:32:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 12:32:23 -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: Closed >Resolution: Fixed 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-09-14 21:32 Message: Logged In: YES user_id=1188172 Fixed with patch #1212928. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 21:11 Message: Logged In: YES user_id=1188172 I submitted a patch (#1212928) which fixes that. ---------------------------------------------------------------------- Comment By: Craig Ringer (ringerc) Date: 2005-07-11 21:08 Message: Logged In: YES user_id=639504 It matters all right. Just wasted a bunch of time tracking this down into the Python sources and confirming it was a Python bug. It's really nasty for 'es'. This will cause bizarre errors for PyArg_ParseTupleAndKeywords(...) calls using the unsupported format strings after the | optional argument barrier. The errors will always contain the string: impossible The error will, of course, only turn up if the user omits one or more of the arguments with unsupported formats. ---------------------------------------------------------------------- Comment By: Petr Vaněk (subik) Date: 2005-07-11 21:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). ---------------------------------------------------------------------- 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 Sep 14 21:45:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 12:45:16 -0700 Subject: [ python-Bugs-1285809 ] re special sequence '\w' Message-ID: Bugs item #1285809, was opened at 2005-09-09 11:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285809&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: re special sequence '\w' Initial Comment: >>> rexp = re.compile('\w', re.LOCALE) >>> rexp.findall('_') ['_'] >>> '_'.isalnum() False While the Python docs say, that the underscore is supported, I strongly ask why this is so? The problem is that I want to match a sequence of alphanumeric characters but excluding the underscore. If you defined \w to not support "_" anymore, people could easily check for the "_" as well with \w|_ . My locale is "de_DE" but it does affect other locales as well. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 21:45 Message: Logged In: YES user_id=1188172 \w matches the underscore since \w has been introduced in RE syntax, and this was not in Python. This alone is sufficient to justify this behavior. Anyway, Python's behavior cannot change, too. Many REs would become erroneous with such a change. So closing as Won't fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1285809&group_id=5470 From noreply at sourceforge.net Wed Sep 14 21:46:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 12:46:22 -0700 Subject: [ python-Bugs-1281291 ] Erroneous \url command in python.sty Message-ID: Bugs item #1281291, was opened at 2005-09-03 17:18 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470 Please note that this 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: Rory Yorke (ryorke) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Erroneous \url command in python.sty Initial Comment: The \url and \ulink commands in texinputs/python.sty produce erroneous PDF files. This can be fairly easily tested using GhostScript (see the attached log file for an example). The current Python 2.4.1 PDF docs (as downloadable from www.python.org) have this error. Although the error does not prevent correct rendering in viewers such as gv, xpdf or acroread, the link is absent. The attached patch partially addresses this, by changing the arguments to the \pdfstart command used. The changes are taken straight from texmf/tex/latex/hyperref/hpdftex.def; that file has the following version header: %% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz, %% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $ I don't pretend to understand the TeX code, but it does fix some of the problem. Some URLs, like http://sourceforge.net/bugs/?group_id=5470, are not linked to correctly. That particular URL becomes http://sourceforge.net/bugs/?groupunhbox%20voidb at x%20penalty%20 at M%20hskip%20z at skip%20unhbox%20voidb at x%20kern%20.06emvbox%20{hrule%20width.3em}discretionary%20{-}{}{}penalty%20 at M%20hskip%20z at skip%20id=5470 -- I guess that has something to do with the underscore. The diff was generated relative to Python CVS head of 3 Sept 2005; the python.sty file had version 1.113. The python executable used was 2.4.1, not CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:02:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:02:07 -0700 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message 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: Adal Chiriliuc (adalx) >Assigned to: Martin v. L?wis (loewis) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:03:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:03:09 -0700 Subject: [ python-Bugs-1288615 ] Python code.interact() and UTF-8 locale Message-ID: Bugs item #1288615, was opened at 2005-09-12 13:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Python code.interact() and UTF-8 locale Initial Comment: Hi, I found a bug in Python interactive command line (program python alone: looks to be code.interact() function in code.py). With UTF-8 locale, the command << u"?" >> returns << u'\xc3\xa9' >> and not << u'\xE9' >>. Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3 \xA9 in UTF-8. Another example of the bug: #-*- coding: UTF-8 -*- code = "u\%s\" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Result : u'\xc3\xa9' Excepted result : u'\xe9' After long hours of debuging (read Python documentation, debug Python with gdb, read Python C source code, ...) I found the origin of the bug: function parsestr() in Python/compile.c. This function translate a string to a unicode string (or a classic string). The problem is when the encoding declaration doesn't exist: the string isn't converted. Solution to the first code: #-*- coding: ascii -*- code = """#-*- coding: UTF-8 -*- u\%s\""" % "\xc3\xa9" compiled = compile(code,'',"single") exec compiled Proposition: u"..." and unicode("...") should use sys.stdin.encoding by default. They will work as unicode("...", sys.stdin.encoding). Or easier, the compiler should use sys.stdin.encoding and not ascii as default encoding. Sorry if someone already reported this bug. And, is it a bug or a feature ? ;-) Bye, Haypo ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:03 Message: Logged In: YES user_id=1188172 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: STINNER Victor (haypo) Date: 2005-09-12 14:46 Message: Logged In: YES user_id=365388 Ok ok, after long discution with RexFi on IRC, I understood that Python can't *guess* string encoding ... I agree with that, system locale or source encoding are not a good choice. But ... Python console have a bug. It uses raw_input(). So I wrote a patch to just add the right unicode cast. But Python console don't looks to be code.interact(). I attach the patch to this comment. Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1288615&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:18:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:18:44 -0700 Subject: [ python-Bugs-1201461 ] suspected cPickle memory leak Message-ID: Bugs item #1201461, was opened at 2005-05-13 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=1201461&group_id=5470 Please note that this message will contain a full 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 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:18 Message: Logged In: YES user_id=1188172 Closing due to lack of response. cPickle is such a complex module, without a test case the leak cannot be found. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 22:34 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: 2005-05-30 10:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates how the memory is exhausted? Without a test case, it is unlikely that we will be able to find the suspected leak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:24:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:24:30 -0700 Subject: [ python-Bugs-1283491 ] nit for builtin sum doc Message-ID: Bugs item #1283491, was opened at 2005-09-07 02:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 Please note that this 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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:24 Message: Logged In: YES user_id=1188172 If we change the function signature in the docstring, we must include the "defaults to 0" somewhere. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-08 04:37 Message: Logged In: YES user_id=80475 """ >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? """ FYI, the answer is no. The requirement for parenthesis cannot change. To see why, parse this: f(g(t) for t in a, b). ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-09-07 21:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-09-07 21:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum( sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 05:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:42:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:42:20 -0700 Subject: [ python-Bugs-1274828 ] splitunc not documented Message-ID: Bugs item #1274828, was opened at 2005-08-27 23:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&group_id=5470 Please note that this 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: Poor Yorick (pooryorick) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: splitunc not documented Initial Comment: a description of splitunc is missing from http://docs.python.org/lib/module-os.path.html ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:42 Message: Logged In: YES user_id=1188172 Interesting, since splitunc() is mentioned in the chapter heading :) Added a description in Doc/lib/libposixpath.tex r1.43, r1.40.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&group_id=5470 From noreply at sourceforge.net Wed Sep 14 22:52:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 13:52: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: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Huening (huening) >Assigned to: Reinhold Birkenfeld (birkenfeld) 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-09-14 22:52 Message: Logged In: YES user_id=1188172 Checked this in now. posixmodule.c r2.340, r2.329.2.4. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 10:27 Message: Logged In: YES user_id=38388 The path looks OK, but I can't test it on Windows (os.startfile() is only available on Windows). A note on style: you should always try to keep lines shorter than 80 characters, e.g.: --- CVS-Python/Modules/posixmodule.c 2005-08-15 10:15:27.000000000 +0200 +++ Dev-Python/Modules/posixmodule.c 2005-09-01 10:23:06.555633134 +0200 @@ -7248,7 +7248,8 @@ { char *filepath; HINSTANCE rc; - if (!PyArg_ParseTuple(args, "s:startfile", &filepath)) + if (!PyArg_ParseTuple(args, "et:startfile", + Py_FileSystemDefaultEncoding, &filepath)) return NULL; Py_BEGIN_ALLOW_THREADS rc = ShellExecute((HWND)0, NULL, filepath, NULL, NULL, SW_SHOWNORMAL); ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 07:18 Message: Logged In: YES user_id=80475 I'm unicode illiterate. Passing to MAL for review. ---------------------------------------------------------------------- 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 Thu Sep 15 00:28:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 15:28:27 -0700 Subject: [ python-Bugs-1291446 ] SSLObject breaks read semantics Message-ID: Bugs item #1291446, was opened at 2005-09-14 22:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291446&group_id=5470 Please note that this message will contain a full 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: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: SSLObject breaks read semantics Initial Comment: f = socket.ssl(sock) f.read(n) doesn't always return n bytes, even if the connection remains open! in particular, it seems to reproducibly return less than n bytes if the read would span the boundary between units of 16KB of data. We've had to work around this with code like the following: pieces = [] while n > 0: got = self.realfile.read(n) if not got: break pieces.append(got) n -= len(got) return ''.join(pieces) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291446&group_id=5470 From noreply at sourceforge.net Thu Sep 15 04:42:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 19:42:43 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this message will contain a full 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: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Sep 15 07:45:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 22:45:38 -0700 Subject: [ python-Feature Requests-1237680 ] add dedent() string method Message-ID: Feature Requests item #1237680, was opened at 2005-07-13 18:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 Please note that this message 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: add dedent() string method Initial Comment: textwrap.dedent() is very useful for in-code multi-line string literals. However, as it is "hidden" in a module it does not really fit in, people don't use it and instead propose new string literal syntax for "dedented". str.dedent with an efficient C implementation would solve this. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 07:45 Message: Logged In: YES user_id=1188172 Rejected as per discussion on python-dev. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 23:53 Message: Logged In: YES user_id=80475 -1 * Being a top level function in a module doesn't count as hidden. This is no more hidden than collections.deque, glob.glob, or re.sub. * The API requirements are looser in a textwrap context. For a string method, there would need to be a universally useful decision about how to handle mixed spaces and tabs and whether the first line of a triple-quoted string would be handled differently. Am not sure if universal newlines present any additional issues. * The world-view of the string module is character oriented, not line oriented. A dedent method() is not a perfect fit. * While the topic comes up every few years, in general, there is no user demand for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 From noreply at sourceforge.net Thu Sep 15 08:07:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 23:07:04 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 14:59 Message generated for change (Comment added) made by josiahcarlson 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: Closed Resolution: Fixed 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: Josiah Carlson (josiahcarlson) Date: 2005-09-14 23:07 Message: Logged In: YES user_id=341410 Was it a bug, or was it merely confusing semantics? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 03:58 Message: Logged In: YES user_id=1188172 Will you backport the fix? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 01:58 Message: Logged In: YES user_id=7887 Fixed in: Lib/sre_parse.py: 1.64 -> 1.65 Lib/test/test_re.py: 1.55 -> 1.56 Misc/NEWS: 1.1360 -> 1.1361 Notice that perl will also handle constructs like '{,2}' as literals, while Python will consider them as '{0,2}'. I think it's too late to change that one though, as this behavior may be relied upon in code out there. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 15:16 Message: Logged In: YES user_id=1188172 No, you're the expert, so you'll get the honor of fixing it. :P ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-08-31 15:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 14:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 12: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 11: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 11: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 08: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 01: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 04: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 14: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 14: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 13: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 13: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 09: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 Sep 15 08:12:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 23:12:02 -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: Closed Resolution: Fixed 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-09-15 08:12 Message: Logged In: YES user_id=1188172 I would say bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-15 08:07 Message: Logged In: YES user_id=341410 Was it a bug, or was it merely confusing semantics? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 12:58 Message: Logged In: YES user_id=1188172 Will you backport the fix? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-14 10:58 Message: Logged In: YES user_id=7887 Fixed in: Lib/sre_parse.py: 1.64 -> 1.65 Lib/test/test_re.py: 1.55 -> 1.56 Misc/NEWS: 1.1360 -> 1.1361 Notice that perl will also handle constructs like '{,2}' as literals, while Python will consider them as '{0,2}'. I think it's too late to change that one though, as this behavior may be relied upon in code out there. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-01 00:16 Message: Logged In: YES user_id=1188172 No, you're the expert, so you'll get the honor of fixing it. :P ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-09-01 00:11 Message: Logged In: YES user_id=7887 I support Skip's opinion on following whatever perl is currently doing, if that won't lead to unexpected errors on current running code which was considered sane (expecting {} to behave like {1,1} is not sane :-). Your original patch looks under-optimal though (look at the tests around it). I'll fix it, or if you prefer to do it by yourself, I may apply the patch/review it/whatever. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- 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 Thu Sep 15 08:44:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Sep 2005 23:44:23 -0700 Subject: [ python-Bugs-1291662 ] Installation of waste by MacPython installer Message-ID: Bugs item #1291662, was opened at 2005-09-15 08:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&group_id=5470 Please note that this 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: Freek Dijkstra (macfreek) Assigned to: Jack Jansen (jackjansen) Summary: Installation of waste by MacPython installer Initial Comment: Hi, I just installed MacPython 2.3 (on my Mac with Tiger 10.4), and found that the IDE did not launch with this error in the console.log: Traceback (most recent call last): File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDE.py", line 58, in ? import PythonIDEMain as _PythonIDEMain File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDEMain.py", line 7, in ? import W File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/W.py", line 7, in ? from Wtext import * File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/Wtext.py", line 6, in ? import waste ImportError: No module named waste (included line-breaks for readability). The problem was solved relatively easy: I noticed that /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages points to /Library/Python/2.3/site- packages/ but that waste.so was installed (apparently by the MacPython 2.3) installer in /Library/Python/2.3/. mv /Library/Python/2.3/waste.so /Library/Python/2.3/site- packages/ did solve the problem, and PythonIDE did launch. Is this a bug in the installer? Perhaps the aforementioned symbolic link changed from /Library/Python/2.3/ to /Library/Python/2.3/site-packages/ since the release of 10.4. Kind regards, Freek Dijkstra ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&group_id=5470 From noreply at sourceforge.net Thu Sep 15 09:51:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 00:51:26 -0700 Subject: [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 05:17 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Please note that this message will contain a full 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: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:51 Message: Logged In: YES user_id=1188172 Corrected in webbrowser.py r1.37.4.1. For the 2.5 branch, a new patch will be checked in which corrects this too. ---------------------------------------------------------------------- Comment By: Dmitry Vukolov (ekid) Date: 2005-09-04 02:36 Message: Logged In: YES user_id=1000960 The problem still exists in Python 2.4.1 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 21:37 Message: Logged In: YES user_id=752496 richard seems to reproduced it on Py2.3, changing the group to it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2005-01-16 23:01 Message: Logged In: YES user_id=6405 This is still an issue. python -c 'import webbrowser;webbrowser.open("http://www.google.com/")' on a system using KDE will exhibit the break. I posted a patch to fix the behaviour in my last message. I just noticed that I invoked diff the wrong way around (though the explanation still stands) - a correct invocation: --- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208 +1100 +++ /usr/lib/python2.3/webbrowser.py 2005-01-17 08:59:58.269989095 +1100 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:26 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: Richard Jones (richard) Date: 2003-08-20 02:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 02:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 21:43 Message: Logged In: YES user_id=198518 A week after posting <slrnb5iu1s.t8.matt at sake.mondoinfo.com> ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 14:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Thu Sep 15 09:56:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 00:56:40 -0700 Subject: [ python-Bugs-1114929 ] webbrowser doesn't start default Gnome browser by default Message-ID: Bugs item #1114929, was opened at 2005-02-02 19:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114929&group_id=5470 Please note that this message will contain a full 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: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser doesn't start default Gnome browser by default Initial Comment: I've written a patch to try to access the default Gnome web browser under Unix (if Gnome is available). This is likely to be a good choice of web browser under modern systems. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:56 Message: Logged In: YES user_id=1188172 Subsumed by big 2.5 webbrowser patch #754022. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114929&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:11:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:11:00 -0700 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 13:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 Please note that this message will contain a full 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: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:11 Message: Logged In: YES user_id=1188172 Closing as requested. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 22:22 Message: Logged In: YES user_id=261020 This should be closed: this issue was resolved by patch 852995. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 01:17 Message: Logged In: YES user_id=261020 Sorry, last comment not very useful. I think this should be closed. Two real problems: 1. urllib2.urlopen incorrectly raises OSError instead of URLError. This is already detected by my unit tests (852995), and I'll file a separate bug for this later (when/if 852995 is resolved). 2. Would be nice if urllib2's functional tests used PyUnit (so it is clear which tests are passing or failing), and worked on Windows. Again, I'll submit a separate patch. To the bug poster: 0. ftplib is not urllib2, please report bugs separately. 1. You're not invoking ftplib's test program correctly. It seems to work, at least partially: python ftplib.py ftp.python.org /pub/www.python.org/index.html 2. It seems you're using Windows, so you shouldn't expect opening /etc/password to work (though the test shouldn't crash as it does, of course, and it should work on Windows, and it should give an indication of pass/fail). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-03 20:40 Message: Logged In: YES user_id=261020 It is broken. I'd like to know where functional tests officially live before fixing it. I'll ask on python-dev... ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 23:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-18 16:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:20:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:20:16 -0700 Subject: [ python-Bugs-1291662 ] Installation of waste by MacPython installer Message-ID: Bugs item #1291662, was opened at 2005-09-15 08:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Freek Dijkstra (macfreek) Assigned to: Jack Jansen (jackjansen) Summary: Installation of waste by MacPython installer Initial Comment: Hi, I just installed MacPython 2.3 (on my Mac with Tiger 10.4), and found that the IDE did not launch with this error in the console.log: Traceback (most recent call last): File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDE.py", line 58, in ? import PythonIDEMain as _PythonIDEMain File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDEMain.py", line 7, in ? import W File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/W.py", line 7, in ? from Wtext import * File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/Wtext.py", line 6, in ? import waste ImportError: No module named waste (included line-breaks for readability). The problem was solved relatively easy: I noticed that /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages points to /Library/Python/2.3/site- packages/ but that waste.so was installed (apparently by the MacPython 2.3) installer in /Library/Python/2.3/. mv /Library/Python/2.3/waste.so /Library/Python/2.3/site- packages/ did solve the problem, and PythonIDE did launch. Is this a bug in the installer? Perhaps the aforementioned symbolic link changed from /Library/Python/2.3/ to /Library/Python/2.3/site-packages/ since the release of 10.4. Kind regards, Freek Dijkstra ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-09-15 12:20 Message: Logged In: YES user_id=45365 This is a known problem with 2.3. It is fixed with MacPython 2.3.5, which you can find on the "pre-production builds" of the MacPython homepage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:26:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:26:55 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 10:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) Assigned to: Martin v. L?wis (loewis) Summary: test_pwd fails on 64bit system (Opteron) Initial Comment: test test_pwd failed -- Traceback (most recent call last): File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum $ cat /proc/version Linux version 2.4.21-20.ELsmp (bhcompile at dolly.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18 20:34:58 EDT 2004 Processor is AMD Opteron 2.4MHz ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:26 Message: Logged In: YES user_id=1188172 Closing as requested. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-14 20:17 Message: Logged In: YES user_id=6380 Martin, IMO you can close this now that I've checked in the AIX patch which should address this with the i->I change suggested in a comment below. (patch 1284289) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-07 23:16 Message: Logged In: YES user_id=33168 See this patch which looks like it may fix the same problem (among others). https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 20:17 Message: Logged In: YES user_id=1188172 Is the patch safe to apply? I think so, I haven't seen a negative uid/gid yet. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-09-01 14:57 Message: Logged In: YES user_id=1035073 The suggested patch by heffler worked brilliantly for my 64 bit environment. Thanks. My bug submission was on 2005-08-03 14:40. ---------------------------------------------------------------------- Comment By: Marvin Heffler (heffler) Date: 2005-08-11 20:19 Message: Logged In: YES user_id=298758 I think I figued out the problem with python handling uids and gids greater than 2147483647 when using the grp.getgrgid and pwd.getpwuid functions. Both of the functions call PyArg_ParseTuple with a type of "i", thus indicating the argument is a signed integer. Instead they should be using "I" (upper-case i) for an unsigned integer. The fix is fairly simple. Here are the two patches necessary to the python source: diff -Naur Python-2.4.orig/Modules/grpmodule.c Python- 2.4/Modules/grpmodule.c --- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 16:06:00.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -0400 @@ -87,7 +87,7 @@ { int gid; struct group *p; - if (!PyArg_ParseTuple(args, "i:getgrgid", &gid)) + if (!PyArg_ParseTuple(args, "I:getgrgid", &gid)) return NULL; if ((p = getgrgid(gid)) == NULL) { PyErr_Format(PyExc_KeyError, "getgrgid(): gid not found: %d", gid); diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python- 2.4/Modules/pwdmodule.c --- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 16:07:23.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -0400 @@ -104,7 +104,7 @@ { int uid; struct passwd *p; - if (!PyArg_ParseTuple(args, "i:getpwuid", &uid)) + if (!PyArg_ParseTuple(args, "I:getpwuid", &uid)) return NULL; if ((p = getpwuid(uid)) == NULL) { PyErr_Format(PyExc_KeyError, Hopefully, someone from the python project can verify my patch and get it incorporated into a future release. ---------------------------------------------------------------------- Comment By: Clark Mobarry (cmobarry) Date: 2005-08-03 20:40 Message: Logged In: YES user_id=1035073 The same error occurs for an Intel P4-521 processor running RedHat Enterprise Linux WS v4 Intel EM64T 64bit. $ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:29:47 EST 2005 test test_grp failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum test test_pwd failed -- Traceback (most recent call last): File "/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-03-17 10:20 Message: Logged In: YES user_id=358087 I've tried the patch - no luck :-( I'm stealing time on these machines since they belong to another group. However I see that SF's compile farm (http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1) have an AMD64 host (amd64-linux1) Maybe you can shorten the loop ... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-03-14 23:17 Message: Logged In: YES user_id=89016 On a 32bit system adding the line nobody:x:4294967294:65534:nobody:/:/bin/false to /etc/passwd pwd.getpwall() gives me an entry: ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') and pwd.getpwuid(-2) gives me ('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false') Maybe for 64bit systems the SETI macro should use PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can you try the following patch? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-17 09:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-17 02:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 10:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:47:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:47:31 -0700 Subject: [ python-Bugs-868706 ] Calling builtin function 'eval' from C causes seg fault. Message-ID: Bugs item #868706, was opened at 2004-01-01 04:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zac Evans (karadoc) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Calling builtin function 'eval' from C causes seg fault. Initial Comment: Using C to get the eval function from builtins then call it causes a Seg-Fault. I've tried calling it using PyObject_CallObject, "_CallFunction, "_CallFunctionObjArg s. All cause the same problem. Other builtin functions seem to work correctly. and eval seems to work correctly from python (obviously). It's just calling eval from C which causes the crash. Attached is some sample code which demonstrates the problem. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:47 Message: Logged In: YES user_id=1188172 I fixed this; eval() now raises a TypeError when called from C without globals/locals. Committed in Python/bltinmodule.c r2.325, r2.318.2.3. ---------------------------------------------------------------------- Comment By: Zac Evans (karadoc) Date: 2004-01-02 04:04 Message: Logged In: YES user_id=117625 In my opinion, the 'bug' isn't really a big problem. If it is nicer for the internals of Python if the bug isn't fixed, than that would be fine. Although, it would be a good thing to document somewhere. Ideally, the call should raise an expection saying what the problem is. That's always nicer than a seg-fault. Also, on an almost unrelated note, why are PyEval_EvalCode() and a whole lot of other PyEval_* functions missing from the Python/C API index in the docs (http://www.python.org/doc/current/api/genindex.html)? And that's about all I have to say about that. Thank you for you time and quick reponse. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 22:52 Message: Logged In: YES user_id=33168 The attached patch fixes the problem, but I'm not sure this should be applied. Partially because I'm not sure it's the best solution. I'm also not sure if your use should be considered correct. I'm not sure if this is documented. Perhaps that should be changed? I understand your complaint, however, you can fix the problem my passing a dictionary for globals. You can also call PyEval_EvalCode or PyEval_EvalCodeEx. But in both of those cases you will need to supply globals. I believe the reason for the segfault is that globals is NULL since there is no frame. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470 From noreply at sourceforge.net Thu Sep 15 12:56:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 03:56:30 -0700 Subject: [ python-Bugs-1069092 ] segfault on printing nested sequences of None/Ellipsis Message-ID: Bugs item #1069092, was opened at 2004-11-19 00:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069092&group_id=5470 Please note that this message 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: Jonas K?lker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: segfault on printing nested sequences of None/Ellipsis Initial Comment: ## bug1.py loop = None, while True: loop = loop, None bash$ python -i bug1.py (I press C-c) >>> print loop ((((((((((((((((( (((((((((segfault bash$ bash$ python -i bug1.py (I press C-c) >>> str(loop) segfault bash$ bash$ python -i bug1.py (I press C-c) >>> repr(loop) segfault bash$ --- --- the results are the same for bug2.py, bug3.py and bug.py4 which have the same contents, except that loop is a list, None is replaced by Ellipsis or both. The behavior (i.e. segfaulting) is the same. also, when pressing C-c, python's memory usage remains constant. gc.garbage is empty; gc.collect() returns 0 and doesn't free memory. my python and uname: bash$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 bash$ uname --all Linux koelker 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux I have also reproduced it on Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 bash$ uname --all Linux horse09 2.6.8-1.521smp #1 SMP Man Aug 16 09:25:06 EDT 2004 i686 i686 i386 GNU/Linux and on Python 2.4a3 (#1, Oct 3 2004, 12:05:12) [GCC 3.3.2] on linux2 (on the same machine) it didn't reproduce on Python 1.5.2 (#1, Mar 9 2000, 17:40:34) [GCC 2.95.2 19991024 (release)] on hp-uxB bash$ uname -a HP-UX aragorn B.11.11 U 9000/782 2006786478 unlimited-user license but it did on Python 1.5.2 (#1, Jul 5 2001, 03:02:19) [GCC 2.96 20000731] (Red Hat Linux 7.1 2 on linux-i386 bash$ uname Linux legolas 2.4.20-20.7smp #1 SMP Mon Aug 18 14:46:14 EDT 2003 i686 unknown ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:56 Message: Logged In: YES user_id=1188172 I can reproduce this here on Linux with 100000x None. Will try to investigate. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-11-24 08:43 Message: Logged In: YES user_id=593130 On <<>> I got (interactive mode, about 5 sec before ^C) appropriate output: (((((((((((((((((((((((((((((((((((((((((((((((((((((( Traceback (most recent call last): File "", line 1, in ? MemoryError: stack overflow The nested depth was >>> i=0 >>> while loop: loop,i = loop[0], i+1 ... >>> i 50695 Note: a test case would need a finite loop such as: for i in range(100000) instead of while True (until ^C pressed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069092&group_id=5470 From noreply at sourceforge.net Thu Sep 15 18:03:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 09:03:37 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 17:41 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) Assigned to: Tim Peters (tim_one) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-09-15 12:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Thu Sep 15 23:04:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 14:04:28 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 17:41 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) >Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-15 17:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 12:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Fri Sep 16 00:00:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 15:00:30 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 14:41 Message generated for change (Comment added) made by agthorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2005-09-15 15:00 Message: Logged In: YES user_id=6324 Let me elaborate on the use-case where I originally ran into this. I'm conducting a series of observation experiments where I measure the duration of an event. I then want to do various statistical analysis such as computing the mean, median, etc. Originally, I tried using standard functions such as lmean from the stats.py package. However, these sorts of functions divide by a float at the end, causing them to fail on timedelta objects. Thus, I have to either write my own special functions, or convert the timedelta objects to integers first (then convert them back afterwards). Basically, I want timedelta objects to look and act like fixed-point arithmetic objects so that I can reuse other functions on them that were originally developed to operate on floats. More importantly, I'd rather not have to maintain two different versions of the functions to deal with different types. For implementation, why not multiply the float times .day, .seconds, and .microseconds separately, then propagate and fraction parts into the next smallest group (e.g., 0.5 days becomes 24*60*60*0.5 seconds). I agree it'd be possible to lose information with the wrong sequence of operations, but that's always the case when using floating point numbers. In other words, that, too, is what I would expect from the timedelta implementation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-15 14:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 09:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 21:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Fri Sep 16 07:02:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 22:02:45 -0700 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-09 01:26 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 Please note that this message 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: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2005-09-16 14:02 Message: Logged In: YES user_id=671362 Can anyone else review this patch before the new 2.4 gets released? The patch is ready to be commited. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-05-15 21:22 Message: Logged In: YES user_id=671362 The fix seems reasonable to me and it passed the test suites. Please apply it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-15 16:57 Message: Logged In: YES user_id=21627 What do you think about the patch attached? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-20 02:11 Message: Logged In: YES user_id=671362 Martin, what's your take on this? The representation of '-(1+0j)' has changed since Revision 2.71 (complexobject.c) and you applied the patch. # original patch making Python LC_NUMERIC agnostic http://www.python.org/sf/774665 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-02-10 09:02 Message: Logged In: YES user_id=671362 Hi, Bj?rn. Sorry, not to be clear about what my complaint is. I'm not talking about if -(0j) should be 0j or -0j. It's been that way for a long time, so changing it would break old codes. My point is the signature of imaginary part. As you can see, it's represented as '+-'. Before the commit of patch #774665, it was represented as '-1-0j'. But after that, '-1+-0j'. If you test it with Python <= 2.3, you'll get (-1-0j) and I think this is how -(1+0j) should be represented on machines where - (0j) is represented as -0j. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-10 03:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Fri Sep 16 08:43:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Sep 2005 23:43:11 -0700 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-08 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=1118729&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-16 08:43 Message: Logged In: YES user_id=1188172 Reviewed and applied in Objects/complexobject.c r2.74, 2.72.2.2. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-09-16 07:02 Message: Logged In: YES user_id=671362 Can anyone else review this patch before the new 2.4 gets released? The patch is ready to be commited. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-05-15 14:22 Message: Logged In: YES user_id=671362 The fix seems reasonable to me and it passed the test suites. Please apply it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-15 09:57 Message: Logged In: YES user_id=21627 What do you think about the patch attached? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-19 18:11 Message: Logged In: YES user_id=671362 Martin, what's your take on this? The representation of '-(1+0j)' has changed since Revision 2.71 (complexobject.c) and you applied the patch. # original patch making Python LC_NUMERIC agnostic http://www.python.org/sf/774665 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-02-10 01:02 Message: Logged In: YES user_id=671362 Hi, Bj?rn. Sorry, not to be clear about what my complaint is. I'm not talking about if -(0j) should be 0j or -0j. It's been that way for a long time, so changing it would break old codes. My point is the signature of imaginary part. As you can see, it's represented as '+-'. Before the commit of patch #774665, it was represented as '-1-0j'. But after that, '-1+-0j'. If you test it with Python <= 2.3, you'll get (-1-0j) and I think this is how -(1+0j) should be represented on machines where - (0j) is represented as -0j. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-09 19:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Fri Sep 16 09:27:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 00:27:47 -0700 Subject: [ python-Bugs-1292634 ] The _ssl build process for 2.3.5 is broken Message-ID: Bugs item #1292634, was opened at 2005-09-16 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Cheung (robertcheung) Assigned to: Nobody/Anonymous (nobody) Summary: The _ssl build process for 2.3.5 is broken Initial Comment: I have attempted to build the _ssl library for 2.3.5 and it is broken (see attached output 1). Basically it is complaining that the _ssl.pyd file could not be build because several symbols (GetUserObjectInformation, etc) could not be linked. Those symbols are suppose to be located in User32.[lib|dll]. Appending User32.lib to line 15 of _ssl.mak fixed this problem (see attachment 2). Hopefully this will be helpful for other people that also had build problems with the ssl library. Regards Robert Cheung -------- Attached output 1-------------- C:\downloads\python\Python-2.3.5\PCbuild>python build_ssl.py Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at 'C:\downloads\python\openssl-0.9.8' Executing nmake over the ssl makefiles... Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. cl /nologo ../Modules/_ssl.c C:\downloads\python\openssl-0.9.8/out32/libeay32.lib C:\downloads\python\openssl-0.9.8/out32/ssleay32.lib /Ox /MD /LD /Fox86-temp-release/_ssl\_ssl.obj -I ../Include -I ../PC -I C:\downloads\python\openssl-0.9.8/inc32 /link /out:_ssl.pyd gdi32.lib wsock32.lib /libpath:C:\downloads\p ython\openssl-0.9.8/out32 libeay32.lib ssleay32.lib _ssl.c Creating library _ssl.lib and object _ssl.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetUserObjectInformationW at 20 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetProcessWindowStation at 0 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetDesktopWindow at 0 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__MessageBoxIndirectA at 4 referenced in function _OPENSSL_showfatal _ssl.pyd : fatal error LNK1120: 4 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. ------------ Attachment 2 ----------------- _ssl.mak line 15 - LIBS=gdi32.lib wsock32.lib /libpath:$(SSL_LIB_DIR) libeay32.lib ssleay32.lib User32.lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 From noreply at sourceforge.net Fri Sep 16 11:02:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 02:02:24 -0700 Subject: [ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt Message-ID: Bugs item #1242657, was opened at 2005-07-22 01:22 Message generated for change (Comment added) made by stevea_zope You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message 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: Steve Alexander (stevea_zope) Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] ---------------------------------------------------------------------- >Comment By: Steve Alexander (stevea_zope) Date: 2005-09-16 12:02 Message: Logged In: YES user_id=492001 Interestingly, I just saw some code that was causing a problem in the SchoolTool project. It had a __len__ method that used list(self), causing great slowness without this fix, and a RuntimeError "maximum recursion depth exceeded" with this fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 14:10 Message: Logged In: YES user_id=80475 Okay, fixed in several places. This little fragment occurred in a number of places including code listextend(), map(), zip(), filter(), and PySequence_Tuple(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 From noreply at sourceforge.net Fri Sep 16 13:52:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 04:52:07 -0700 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 00:58 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Please note that this message will contain a full 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: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-16 11:52 Message: Logged In: YES user_id=4771 The problem is still there now (5 months later), so should I go ahead and revert the cgi.py changes of r1.83? I does break user code out there. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-04-17 23:39 Message: Logged In: YES user_id=693077 I've been playing with using the email parser to do the whole job of parsing the data, and I think it's too big of a change. It'd be very hard to ensure API compatibility and the same behaviour. I think that in the long run, it's the right thing to do, but I think that the API should change when that change is made. My recommendation for the time being is to revert the original patch that I made. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-08 21:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-06 22:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 23:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 22:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 15:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 10:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 07:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Sep 16 14:04:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 05:04:02 -0700 Subject: [ python-Bugs-1289136 ] distutils extension library path bug on cygwin Message-ID: Bugs item #1289136, was opened at 2005-09-12 14:04 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils extension library path bug on cygwin Initial Comment: A while back I reported a problem on the Cygwin mailing list where all python extension packages would fail "python setup.py install" at the link step due to a mangled lib dir (-L) option. distutils was producing a link line with "-L.", instead of the desired "-L/usr/lib/python2.4/config". I've finally rooted out the cause of this problem. The relevant code is the if-block starting at line 188 of: /usr/lib/python2.4/distutils/command/build_ext.py I've reproduced that block here for clarity of discussion (indentation truncated for redability) if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') The test "string.find(...) != -1" attempts to test whether "/usr" appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin. (i.e. string.find("/bin/python","/usr") == -1) Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. The user-side workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+"bin") ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-09-16 04:04 Message: Logged In: YES user_id=86216 John, Thanks for the excellent analysis! All, Unfortunately, I'm not sure what is the best way to solve this problem. Does anyone have any suggestions? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 From noreply at sourceforge.net Fri Sep 16 15:40:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 06:40:51 -0700 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 01:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Please note that this message will contain a full 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: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-09-16 15:40 Message: Logged In: YES user_id=129426 I vote for revert, so that my code may run again on Python 2.5. Also see Josh's comment , with which I agree. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-16 13:52 Message: Logged In: YES user_id=4771 The problem is still there now (5 months later), so should I go ahead and revert the cgi.py changes of r1.83? I does break user code out there. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-04-18 01:39 Message: Logged In: YES user_id=693077 I've been playing with using the email parser to do the whole job of parsing the data, and I think it's too big of a change. It'd be very hard to ensure API compatibility and the same behaviour. I think that in the long run, it's the right thing to do, but I think that the API should change when that change is made. My recommendation for the time being is to revert the original patch that I made. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-08 22:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-06 23:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-05 00:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 23:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 16:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 11:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 08:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Sep 16 17:58:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 08:58:22 -0700 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-30 16:58 Message generated for change (Comment added) made by joshhoyt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Please note that this message will contain a full 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: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-09-16 08:58 Message: Logged In: YES user_id=693077 Yes, please revert the patch. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-09-16 06:40 Message: Logged In: YES user_id=129426 I vote for revert, so that my code may run again on Python 2.5. Also see Josh's comment , with which I agree. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-16 04:52 Message: Logged In: YES user_id=4771 The problem is still there now (5 months later), so should I go ahead and revert the cgi.py changes of r1.83? I does break user code out there. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-04-17 16:39 Message: Logged In: YES user_id=693077 I've been playing with using the email parser to do the whole job of parsing the data, and I think it's too big of a change. It'd be very hard to ensure API compatibility and the same behaviour. I think that in the long run, it's the right thing to do, but I think that the API should change when that change is made. My recommendation for the time being is to revert the original patch that I made. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-08 13:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-06 14:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 15:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 14:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 07:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 02:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-03 23:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Sat Sep 17 03:48:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Sep 2005 18:48:48 -0700 Subject: [ python-Bugs-1289118 ] timedelta multiply and divide by floating point Message-ID: Bugs item #1289118, was opened at 2005-09-12 16:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 Please note that this message will contain 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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-16 20:48 Message: Logged In: YES user_id=44345 >> Thus, I have to either write my own special functions, or convert >> the timedelta objects to integers first (then convert them back >> afterwards). How about adding tolong() that returns the number of microseconds in the timedelta and fromlong() that accepts a long representing microseconds and returns a timedelta object? That way the timedelta object does a reasonably simple thing and the user is still responsible for overflow the normal arithmetic stuff. You can do any sort of arithmetic operations on the long (including converting to other numeric types) with all the attendant caveats, then convert back to a timedelta object at the end. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2005-09-15 17:00 Message: Logged In: YES user_id=6324 Let me elaborate on the use-case where I originally ran into this. I'm conducting a series of observation experiments where I measure the duration of an event. I then want to do various statistical analysis such as computing the mean, median, etc. Originally, I tried using standard functions such as lmean from the stats.py package. However, these sorts of functions divide by a float at the end, causing them to fail on timedelta objects. Thus, I have to either write my own special functions, or convert the timedelta objects to integers first (then convert them back afterwards). Basically, I want timedelta objects to look and act like fixed-point arithmetic objects so that I can reuse other functions on them that were originally developed to operate on floats. More importantly, I'd rather not have to maintain two different versions of the functions to deal with different types. For implementation, why not multiply the float times .day, .seconds, and .microseconds separately, then propagate and fraction parts into the next smallest group (e.g., 0.5 days becomes 24*60*60*0.5 seconds). I agree it'd be possible to lose information with the wrong sequence of operations, but that's always the case when using floating point numbers. In other words, that, too, is what I would expect from the timedelta implementation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-15 16:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 11:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 23:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 From noreply at sourceforge.net Sat Sep 17 13:41:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 04:41:22 -0700 Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters Message-ID: Bugs item #1293741, was opened at 2005-09-17 11:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 Please note that this 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: GRISEL (ogrisel) Assigned to: Nobody/Anonymous (nobody) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 From noreply at sourceforge.net Sat Sep 17 19:15:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 10:15:06 -0700 Subject: [ python-Bugs-694812 ] setup.py imports pwd before it's built if HOME not set Message-ID: Bugs item #694812, was opened at 2003-02-28 03:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&group_id=5470 Please note that this 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: Stephan A. Terre (sfiedler) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py imports pwd before it's built if HOME not set Initial Comment: The function check_environ in Lib/distutils/util.py imports the 'pwd' module if the HOME environment variable is not set and os.name is 'posix' (as it is on at least Linux, Solaris, and Tru64 Unix). In the context of building Python, this happens before the pwd module has been built. The error is reproduced below. I can work around this easily. However, since the error message was somewhat oblique, it was confusing to diagnose. Perhaps there's some way to improve the diagnostic if the underlying problem cannot be fixed. case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 795, in ? main() File "./setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/core.py", line 110, in setup dist.parse_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 310, in parse_config_files filenames = self.find_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 272, in find_config_files check_environ() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/util.py", line 150, in check_environ import pwd ImportError: No module named pwd ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-17 19:15 Message: Logged In: YES user_id=1188172 Still present in current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&group_id=5470 From noreply at sourceforge.net Sat Sep 17 19:27:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 10:27:22 -0700 Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters Message-ID: Bugs item #1293741, was opened at 2005-09-17 13:41 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 Please note that this 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: GRISEL (ogrisel) >Assigned to: Tim Peters (tim_one) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 From noreply at sourceforge.net Sat Sep 17 19:42:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 10:42:49 -0700 Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters Message-ID: Bugs item #1293741, was opened at 2005-09-17 07:41 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 Please note that this 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: GRISEL (ogrisel) Assigned to: Tim Peters (tim_one) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-09-17 13:42 Message: Logged In: YES user_id=31435 Please try the patch at http://www.python.org/sf/1080727 and report back on whether it solves your problem (attaching comments to the patch report would be most useful). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 From noreply at sourceforge.net Sat Sep 17 21:56:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 12:56:33 -0700 Subject: [ python-Bugs-1294032 ] Distutils writes keywords comma-separated Message-ID: Bugs item #1294032, was opened at 2005-09-17 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=1294032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils writes keywords comma-separated Initial Comment: The distutils package writes out the Keywords metadata field in PKG-INFO comma-separated, while the Cheeseshop/PyPI follows the PEP 341 example and seems to expect space separated keywords. Either this needs clarifying in the PEP or docutils or PyPI should be altered to better integrate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294032&group_id=5470 From noreply at sourceforge.net Sun Sep 18 03:07:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Sep 2005 18:07:12 -0700 Subject: [ python-Bugs-1294232 ] Error in metaclass search order Message-ID: Bugs item #1294232, was opened at 2005-09-18 01: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=1294232&group_id=5470 Please note that this 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: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 From noreply at sourceforge.net Sun Sep 18 10:59:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 01:59:38 -0700 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message 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: Adal Chiriliuc (adalx) >Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:59 Message: Logged In: YES user_id=21627 I'm not sure what it should do: the other option would be to create an int if it fits, else a long. For 2.4.x atleast, this would give better backwards compatibility given the status quo. I certainly agree that the documentation should be updated. Patches are welcome. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Sun Sep 18 11:46:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 02:46:06 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 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=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Nobody/Anonymous (nobody) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Sun Sep 18 12:07:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 03:07:32 -0700 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message 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: Adal Chiriliuc (adalx) >Assigned to: Martin v. L?wis (loewis) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-18 12:07 Message: Logged In: YES user_id=1188172 Attaching patch (including doc changes). For I and k, it creates an int if it fits, else a long. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:59 Message: Logged In: YES user_id=21627 I'm not sure what it should do: the other option would be to create an int if it fits, else a long. For 2.4.x atleast, this would give better backwards compatibility given the status quo. I certainly agree that the documentation should be updated. Patches are welcome. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Sun Sep 18 12:25:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 03:25:19 -0700 Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters Message-ID: Bugs item #1293741, was opened at 2005-09-17 11:41 Message generated for change (Comment added) made by ogrisel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 Please note that this 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: GRISEL (ogrisel) Assigned to: Tim Peters (tim_one) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: GRISEL (ogrisel) Date: 2005-09-18 10:25 Message: Logged In: YES user_id=795041 Unfortunateny that patch does not fix my problem. The patch at bug #1080727 fixes the problem for doctests written in external reST files (testfile and DocFileTest functions). My problem is related to internal docstring encoding (testmod for instance). However, Bjorn Tillenius says: """ If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. """ So according to him, docstrings' doctests with non-ascii characters should work by default. So maybe my system setup is somewhat broken. Could somebody please confirm/infirm this by running the attached sample script on his system? My system config: LANG=fr_FR at euro (on linux) python 2.4.1 with: sys.getdefaultencoding() == 'ascii' and locale.getpreferredencoding() == 'ISO-8859-15' $ file test_iso-8859-15.py test_iso-8859-15.py: ISO-8859 English text ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-17 17:42 Message: Logged In: YES user_id=31435 Please try the patch at http://www.python.org/sf/1080727 and report back on whether it solves your problem (attaching comments to the patch report would be most useful). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 From noreply at sourceforge.net Sun Sep 18 21:13:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 12:13:07 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 04:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 14:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Sun Sep 18 23:08:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 14:08:25 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 05:46 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 17:08 Message: Logged In: YES user_id=12800 Hmm, in Python 2.4 CVS, this always returns 0: import gc import email.Parser s = open('/tmp/msg.txt').read() try: while True: parser = email.Parser.Parser() msg = parser.parsestr(s) del parser except KeyboardInterrupt: print len(gc.garbage) Same thing In Python 2.5 CVS. So where's the leak? Note that it's undefined what the FeedParser does after you call its close. It doesn't seem like a problem to set self._parser = None in the close, if that fixes a problem, but it's a little odd that the above program doesn't reproduce the reported bug. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 15:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Sun Sep 18 23:15:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 14:15:20 -0700 Subject: [ python-Bugs-1236906 ] email.Generator traceback in forwarded msg Message-ID: Bugs item #1236906, was opened at 2005-07-12 14:59 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 Please note that this message will contain a full 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: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generator traceback in forwarded msg Initial Comment: The SpamBayes sb_unheader app uses the email package to dump out a copy of a message with user-specified headers removed. The email.Generator.Generator class is barfing on the attached message. I haven't had a chance to look into it yet, but I suspect it's a problem in the email package, not the sb_unheader program. Here's the traceback I see. This is with a Python built from CVS within the last couple days. Traceback (most recent call last): File "/Users/skip/local/bin/sb_unheader.py", line 144, in ? main(sys.argv[1:]) File "/Users/skip/local/bin/sb_unheader.py", line 139, in main process_mailbox(f, dosa, pats) File "/Users/skip/local/bin/sb_unheader.py", line 86, in process_mailbox gen.flatten(msg, unixfrom=1) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 82, in flatten self._write(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 113, in _write self._dispatch(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 139, in _dispatch meth(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 273, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/Users/skip/local/lib/python2.5/email/Message.py", line 183, in get_payload raise TypeError('Expected list, got %s' % type(self._payload)) TypeError: Expected list, got montanaro:tmp% type tradelink tradelink is aliased to `ssh -C -X loginhost.trdlnk.com' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 17:15 Message: Logged In: YES user_id=12800 This program works fine for me in Python 2.4 and 2.5: import email data = open('/tmp/newham').read() msg = email.message_from_string(data) print msg Note that getting the str of the message will flatten it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 From noreply at sourceforge.net Sun Sep 18 23:20:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 14:20:10 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 04:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 16:20 Message: Logged In: YES user_id=44345 Try running top as the loop executes. Let it run for a couple minutes... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 16:08 Message: Logged In: YES user_id=12800 Hmm, in Python 2.4 CVS, this always returns 0: import gc import email.Parser s = open('/tmp/msg.txt').read() try: while True: parser = email.Parser.Parser() msg = parser.parsestr(s) del parser except KeyboardInterrupt: print len(gc.garbage) Same thing In Python 2.5 CVS. So where's the leak? Note that it's undefined what the FeedParser does after you call its close. It doesn't seem like a problem to set self._parser = None in the close, if that fixes a problem, but it's a little odd that the above program doesn't reproduce the reported bug. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 14:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Sun Sep 18 23:31:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 14:31:44 -0700 Subject: [ python-Bugs-1236906 ] email.Generator traceback in forwarded msg Message-ID: Bugs item #1236906, was opened at 2005-07-12 13:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 Please note that this message will contain a full 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: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generator traceback in forwarded msg Initial Comment: The SpamBayes sb_unheader app uses the email package to dump out a copy of a message with user-specified headers removed. The email.Generator.Generator class is barfing on the attached message. I haven't had a chance to look into it yet, but I suspect it's a problem in the email package, not the sb_unheader program. Here's the traceback I see. This is with a Python built from CVS within the last couple days. Traceback (most recent call last): File "/Users/skip/local/bin/sb_unheader.py", line 144, in ? main(sys.argv[1:]) File "/Users/skip/local/bin/sb_unheader.py", line 139, in main process_mailbox(f, dosa, pats) File "/Users/skip/local/bin/sb_unheader.py", line 86, in process_mailbox gen.flatten(msg, unixfrom=1) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 82, in flatten self._write(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 113, in _write self._dispatch(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 139, in _dispatch meth(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 273, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/Users/skip/local/lib/python2.5/email/Message.py", line 183, in get_payload raise TypeError('Expected list, got %s' % type(self._payload)) TypeError: Expected list, got montanaro:tmp% type tradelink tradelink is aliased to `ssh -C -X loginhost.trdlnk.com' ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 16:31 Message: Logged In: YES user_id=44345 Works for me now as well. Apparently the problem's been fixed... Close? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 16:15 Message: Logged In: YES user_id=12800 This program works fine for me in Python 2.4 and 2.5: import email data = open('/tmp/newham').read() msg = email.message_from_string(data) print msg Note that getting the str of the message will flatten it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 From noreply at sourceforge.net Mon Sep 19 01:04:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 16:04:51 -0700 Subject: [ python-Bugs-1294232 ] Error in metaclass search order Message-ID: Bugs item #1294232, was opened at 2005-09-18 01:07 Message generated for change (Comment added) made by rodsenra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 Please note that this 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: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 23:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 From noreply at sourceforge.net Mon Sep 19 01:24:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 16:24:26 -0700 Subject: [ python-Bugs-1236906 ] email.Generator traceback in forwarded msg Message-ID: Bugs item #1236906, was opened at 2005-07-12 14:59 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 Please note that this message will contain a full 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: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generator traceback in forwarded msg Initial Comment: The SpamBayes sb_unheader app uses the email package to dump out a copy of a message with user-specified headers removed. The email.Generator.Generator class is barfing on the attached message. I haven't had a chance to look into it yet, but I suspect it's a problem in the email package, not the sb_unheader program. Here's the traceback I see. This is with a Python built from CVS within the last couple days. Traceback (most recent call last): File "/Users/skip/local/bin/sb_unheader.py", line 144, in ? main(sys.argv[1:]) File "/Users/skip/local/bin/sb_unheader.py", line 139, in main process_mailbox(f, dosa, pats) File "/Users/skip/local/bin/sb_unheader.py", line 86, in process_mailbox gen.flatten(msg, unixfrom=1) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 82, in flatten self._write(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 113, in _write self._dispatch(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 139, in _dispatch meth(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 273, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/Users/skip/local/lib/python2.5/email/Message.py", line 183, in get_payload raise TypeError('Expected list, got %s' % type(self._payload)) TypeError: Expected list, got montanaro:tmp% type tradelink tradelink is aliased to `ssh -C -X loginhost.trdlnk.com' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 19:24 Message: Logged In: YES user_id=12800 I think so! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 17:31 Message: Logged In: YES user_id=44345 Works for me now as well. Apparently the problem's been fixed... Close? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 17:15 Message: Logged In: YES user_id=12800 This program works fine for me in Python 2.4 and 2.5: import email data = open('/tmp/newham').read() msg = email.message_from_string(data) print msg Note that getting the str of the message will flatten it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 From noreply at sourceforge.net Mon Sep 19 02:42:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 17:42:20 -0700 Subject: [ python-Bugs-1294232 ] Error in metaclass search order Message-ID: Bugs item #1294232, was opened at 2005-09-18 01:07 Message generated for change (Comment added) made by pwerneck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 Please note that this 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: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. ---------------------------------------------------------------------- >Comment By: Pedro Werneck (pwerneck) Date: 2005-09-19 00:42 Message: Logged In: YES user_id=696687 Yes. I think this confusion was caused because of the lack of documentation on this topic, especially on the case described here, which seems to break some rules. Since the "Unifying types and classes" essay seems to be the most used Python document about this topic and, I suggest the first rule on determining a metaclass be changed from: "If dict['__metaclass__'] exists, it is used." To something like: "If dict['__metaclass__'] exists and is equal to, or a subclass of, each of the metaclasses of the bases, it is used; if it exists and is a base class of any metaclass of the bases, the most specialized metaclass in the hierarchy is used; if it exists and doesn't satisfies any of these constraints, TypeError is raised." ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 23:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 From noreply at sourceforge.net Mon Sep 19 03:00:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 18:00:53 -0700 Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really working Message-ID: Bugs item #1284928, was opened at 2005-09-08 13:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 Please note that this message will contain 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: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 From noreply at sourceforge.net Mon Sep 19 03:01:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 18:01:40 -0700 Subject: [ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers Message-ID: Bugs item #1282539, was opened at 2005-09-05 21:12 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 Please note that this message will contain a full 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: Fons Dijkstra (fdij) Assigned to: Vinay Sajip (vsajip) Summary: logging.shutdown() not correct for chained handlers Initial Comment: Consider the following code: import logging import logging.handlers if __name__ == "__main__": fh = logging.handlers.RotatingFileHandler("log.txt") mh = logging.handlers.MemoryHandler(1024, logging.ERROR, fh) logging.getLogger().addHandler(mh) logging.getLogger().warning("next statement crashes") logging.shutdown() which results in a crash due to operating on a closed file. The reason is that the shutdown flushes and closes all handlers in undefined order. In above case, first the 'fh' handlers is flushes and closed then the 'mh' handler. The solution is to first flush all handlers times the number of handlers before closing them. Thus (omitting error handling): def shutdown(): for i in range(len(_handlers)): for h in _handlers.keys(): h.flush() for h in _handlers.keys(): h.close() ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:01 Message: Logged In: YES user_id=308438 Now checked into CVS. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-09-07 11:12 Message: Logged In: YES user_id=308438 There is indeed a problem - thanks for the report. Rather than your proposed solution, I would rather add another internal list, _handlerList, which holds the handlers in *reverse* order of creation. When shutting down, (a copy of) this list is used for the iteration rather than _handlers.keys(). I may remove _handlers in the future - I can't remember why I made it a dict rather than a list. Will check into CVS soon, then mark this as Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470 From noreply at sourceforge.net Mon Sep 19 04:32:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 19:32:40 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 05:46 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 22:32 Message: Logged In: YES user_id=12800 Done. I never see memory usage get about 0.8% (py2.4) or 0.7% (py2.5) after running for several minutes. It certainly doesn't appear to be leaking memory of any detectable amount. If it matters, I tested on Linux (Gentoo) 2.6.12 kernel. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 17:20 Message: Logged In: YES user_id=44345 Try running top as the loop executes. Let it run for a couple minutes... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 17:08 Message: Logged In: YES user_id=12800 Hmm, in Python 2.4 CVS, this always returns 0: import gc import email.Parser s = open('/tmp/msg.txt').read() try: while True: parser = email.Parser.Parser() msg = parser.parsestr(s) del parser except KeyboardInterrupt: print len(gc.garbage) Same thing In Python 2.5 CVS. So where's the leak? Note that it's undefined what the FeedParser does after you call its close. It doesn't seem like a problem to set self._parser = None in the close, if that fixes a problem, but it's a little odd that the above program doesn't reproduce the reported bug. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 15:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Mon Sep 19 04:57:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 19:57:54 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 04:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 21:57 Message: Logged In: YES user_id=44345 Here's what I see on my Mac laptop (10.3.9) with Python 2.4.1: montanaro:skip% ps auxww | egrep python2.4 skip 10914 97.1 0.6 37980 6692 p8 R+ 9:54PM 0:15.50 python2.4 skip 10926 0.0 0.0 18644 268 std U+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 94.7 0.6 37980 6724 p8 R+ 9:54PM 0:20.75 python2.4 skip 10928 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 91.7 0.6 37980 6748 p8 R+ 9:54PM 0:24.36 python2.4 skip 10930 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 90.4 0.6 37980 6780 p8 R+ 9:54PM 0:29.36 python2.4 skip 10932 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 75.6 0.6 37980 6808 p8 R+ 9:54PM 0:33.21 python2.4 skip 10934 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 91.9 0.7 37980 6848 p8 R+ 9:54PM 0:36.86 python2.4 skip 10939 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 90.0 0.7 37980 6928 p8 R+ 9:54PM 1:34.41 python2.4 skip 10998 0.0 0.0 18644 92 std R+ 9:57PM 0:00.01 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 95.3 0.7 37980 6952 p8 R+ 9:54PM 1:46.65 python2.4 skip 11000 0.0 0.0 18644 92 std R+ 9:57PM 0:00.00 egrep python2.4 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 21:32 Message: Logged In: YES user_id=12800 Done. I never see memory usage get about 0.8% (py2.4) or 0.7% (py2.5) after running for several minutes. It certainly doesn't appear to be leaking memory of any detectable amount. If it matters, I tested on Linux (Gentoo) 2.6.12 kernel. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 16:20 Message: Logged In: YES user_id=44345 Try running top as the loop executes. Let it run for a couple minutes... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 16:08 Message: Logged In: YES user_id=12800 Hmm, in Python 2.4 CVS, this always returns 0: import gc import email.Parser s = open('/tmp/msg.txt').read() try: while True: parser = email.Parser.Parser() msg = parser.parsestr(s) del parser except KeyboardInterrupt: print len(gc.garbage) Same thing In Python 2.5 CVS. So where's the leak? Note that it's undefined what the FeedParser does after you call its close. It doesn't seem like a problem to set self._parser = None in the close, if that fixes a problem, but it's a little odd that the above program doesn't reproduce the reported bug. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 14:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Mon Sep 19 05:05:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 20:05:29 -0700 Subject: [ python-Bugs-1294959 ] Problems with /usr/lib64 builds. Message-ID: Bugs item #1294959, was opened at 2005-09-19 03: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=1294959&group_id=5470 Please note that this 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: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with /usr/lib64 builds. Initial Comment: This is something that's becoming more and more of a problem as more people get systems that run both 32-bit and 64-bit code. There are patches (926209 858809) in the tracker to resolve this issue, I don't know exactly what state they are in. They seem fairly old, one is closed and one is still open. The Fedora RPMs include the following patches for lib64 (attached). Any thoughts on what we need to do to allow building lib64 as a part of the standard release? Or do we just want to wait for these terrible transition days to end and rely on 32+64 packagers to deal with it? Here's a short run-down of the situation: Some systems can run both 32 and 64 bit software. On these systems you *CAN* install a native 64-bit tool-chain, but some people set up both 32 and 64 bit software on these systems for compatibility. You can do 32+64 in a couple of ways, one is to set up a "chroot" environment for the secondary (typically 32-bit) set of libraries and programs. The other is to run the system with 64-bit libraries in /usr/lib64 and 32-bit in /usr/lib (because most software that needs compatibility would be running against /usr/lib, not /usr/lib32). It's a kludge to be sure, but if you need any legacy software that you do not have source for, this is a way of getting 64-bits while still retaining the ability to run 32-bit This is not a problem for systems which only run 64-bit code, nor is it a problem for these 32+64 systems which are running only 64-bit distributions on them. Thoughts? Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470 From noreply at sourceforge.net Mon Sep 19 05:42:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 20:42:28 -0700 Subject: [ python-Bugs-1294453 ] email.Parser.FeedParser leak Message-ID: Bugs item #1294453, was opened at 2005-09-18 04:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 Please note that this message will contain a full 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: George Giannakopoulos (pckid) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 22:42 Message: Logged In: YES user_id=44345 *sigh* I believe I was looking at the wrong column (RSS instead of VSZ). After running awhile I broke back to the prompt. gc.garbage is indeed empty (as before), and running the leaks(1) command shows only the following: Process 11260: 3427 nodes malloced for 3353 KB Process 11260: 2 leaks for 64 total leaked bytes. Leak: 0x00404270 size=32 string 'COLUMNS=80' Leak: 0x004041e0 size=32 string 'LINES=40' ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 21:57 Message: Logged In: YES user_id=44345 Here's what I see on my Mac laptop (10.3.9) with Python 2.4.1: montanaro:skip% ps auxww | egrep python2.4 skip 10914 97.1 0.6 37980 6692 p8 R+ 9:54PM 0:15.50 python2.4 skip 10926 0.0 0.0 18644 268 std U+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 94.7 0.6 37980 6724 p8 R+ 9:54PM 0:20.75 python2.4 skip 10928 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 91.7 0.6 37980 6748 p8 R+ 9:54PM 0:24.36 python2.4 skip 10930 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 90.4 0.6 37980 6780 p8 R+ 9:54PM 0:29.36 python2.4 skip 10932 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 75.6 0.6 37980 6808 p8 R+ 9:54PM 0:33.21 python2.4 skip 10934 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 91.9 0.7 37980 6848 p8 R+ 9:54PM 0:36.86 python2.4 skip 10939 0.0 0.0 18644 92 std R+ 9:55PM 0:00.00 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 90.0 0.7 37980 6928 p8 R+ 9:54PM 1:34.41 python2.4 skip 10998 0.0 0.0 18644 92 std R+ 9:57PM 0:00.01 egrep python2.4 montanaro:skip% ps auxww | egrep python2.4 skip 10914 95.3 0.7 37980 6952 p8 R+ 9:54PM 1:46.65 python2.4 skip 11000 0.0 0.0 18644 92 std R+ 9:57PM 0:00.00 egrep python2.4 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 21:32 Message: Logged In: YES user_id=12800 Done. I never see memory usage get about 0.8% (py2.4) or 0.7% (py2.5) after running for several minutes. It certainly doesn't appear to be leaking memory of any detectable amount. If it matters, I tested on Linux (Gentoo) 2.6.12 kernel. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 16:20 Message: Logged In: YES user_id=44345 Try running top as the loop executes. Let it run for a couple minutes... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-09-18 16:08 Message: Logged In: YES user_id=12800 Hmm, in Python 2.4 CVS, this always returns 0: import gc import email.Parser s = open('/tmp/msg.txt').read() try: while True: parser = email.Parser.Parser() msg = parser.parsestr(s) del parser except KeyboardInterrupt: print len(gc.garbage) Same thing In Python 2.5 CVS. So where's the leak? Note that it's undefined what the FeedParser does after you call its close. It doesn't seem like a problem to set self._parser = None in the close, if that fixes a problem, but it's a little odd that the above program doesn't reproduce the reported bug. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-09-18 14:13 Message: Logged In: YES user_id=44345 Using Python built from CVS and from the 2.4 maintenance branch I executed: s = open("... some file containing a message ...").read() while True: parser = email.Parser.Parser() msg = parser.parsestr(s) and let it accumulate a couple minutes of CPU time. It leaks in the 2.4 version, but not the head (2.5) version. The two versions of the email package appear identical (diff -ru). I made a slightly different change. Instead of using self._parse at all, I just replaced it with self._parsegen().next. Memory consumption continues to grow for me. Oddly enough, if I break out of the above loop, do a gc.collect() and then check gc.garbage, the CVS HEAD version shows a list of one element containing a generator. In the 2.4 release branch version gc.garbage is empty. Assigning to Barry as the email wiz... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 From noreply at sourceforge.net Mon Sep 19 08:34:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Sep 2005 23:34:53 -0700 Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really working Message-ID: Bugs item #1284928, was opened at 2005-09-08 16:51 Message generated for change (Comment added) made by rotem_ya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 Please note that this message will contain 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: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. ---------------------------------------------------------------------- >Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 09:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 04:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 From noreply at sourceforge.net Mon Sep 19 11:12:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 02:12:29 -0700 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 00:58 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-19 09:12 Message: Logged In: YES user_id=4771 Reverted (Lib/cgi.py r1.85). ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-09-16 15:58 Message: Logged In: YES user_id=693077 Yes, please revert the patch. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-09-16 13:40 Message: Logged In: YES user_id=129426 I vote for revert, so that my code may run again on Python 2.5. Also see Josh's comment , with which I agree. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-16 11:52 Message: Logged In: YES user_id=4771 The problem is still there now (5 months later), so should I go ahead and revert the cgi.py changes of r1.83? I does break user code out there. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-04-17 23:39 Message: Logged In: YES user_id=693077 I've been playing with using the email parser to do the whole job of parsing the data, and I think it's too big of a change. It'd be very hard to ensure API compatibility and the same behaviour. I think that in the long run, it's the right thing to do, but I think that the API should change when that change is made. My recommendation for the time being is to revert the original patch that I made. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-08 21:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-06 22:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 23:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 22:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 15:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 10:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 07:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Mon Sep 19 11:28:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 02:28:15 -0700 Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25 Message-ID: Bugs item #1295179, was opened at 2005-09-19 17:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 Please note that this 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: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 From noreply at sourceforge.net Mon Sep 19 11:29:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 02:29:33 -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 18:24 Message generated for change (Comment added) made by atila-cheops 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-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-23 16: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 10: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 Mon Sep 19 14:31:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 05:31:57 -0700 Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really working Message-ID: Bugs item #1284928, was opened at 2005-09-08 13:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 Please note that this message will contain 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: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 12:31 Message: Logged In: YES user_id=308438 OK - I'm part way through implementing a change whereby the function name is available through the base logging functionality - the findCaller() implementation in CVS currently gets the function name, but I have not yet implemented the part which puts it into the LogRecord. So this particular patch of yours will soon not be necessary. Also note that you can also redefine the record-making function - but I am currently thinking of how to make this part of the system better, as it is a little untidy at the moment. The objective is to make it easy to add whatever you want to the LogRecord __dict__ which can later be used in the formatted output. ---------------------------------------------------------------------- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 06:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 From noreply at sourceforge.net Mon Sep 19 15:15:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 06:15:46 -0700 Subject: [ python-Bugs-1284928 ] logging module's setLoggerClass not really working Message-ID: Bugs item #1284928, was opened at 2005-09-08 16:51 Message generated for change (Comment added) made by rotem_ya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 Please note that this message will contain 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: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. ---------------------------------------------------------------------- >Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 16:15 Message: Logged In: YES user_id=1340892 That sounds fine. The only thing I think is important is that it'll be possible to add fields to the LogRecord in the period of time between its creation and its "emitting". That will let users add any behavior desired to the logging mechanism. In addition, since setLoggerClass is obviously not intended for users, it should be prefixed with an underscore or made "pseudo private"... its otherwise confusing. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 15:31 Message: Logged In: YES user_id=308438 OK - I'm part way through implementing a change whereby the function name is available through the base logging functionality - the findCaller() implementation in CVS currently gets the function name, but I have not yet implemented the part which puts it into the LogRecord. So this particular patch of yours will soon not be necessary. Also note that you can also redefine the record-making function - but I am currently thinking of how to make this part of the system better, as it is a little untidy at the moment. The objective is to make it easy to add whatever you want to the LogRecord __dict__ which can later be used in the formatted output. ---------------------------------------------------------------------- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 09:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 04:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 From noreply at sourceforge.net Mon Sep 19 15:42:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 06:42:18 -0700 Subject: [ python-Bugs-1295432 ] cookielib undefined local variable error Message-ID: Bugs item #1295432, was opened at 2005-09-19 09: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=1295432&group_id=5470 Please note that this message will contain a full 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: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib undefined local variable error Initial Comment: The domain_return_ok() method in DefaultCookiePolicy class got Undefined local variable exception with cookies returned by some websites. I couldn't see the cookie which caused the problem. But it seems this is because the local variables dotted_req_host and dotted_erhn are first assigned in a if statement and might not be always defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&group_id=5470 From noreply at sourceforge.net Mon Sep 19 20:50:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 11:50:12 -0700 Subject: [ python-Bugs-1295432 ] cookielib undefined local variable error Message-ID: Bugs item #1295432, was opened at 2005-09-19 15:42 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib undefined local variable error Initial Comment: The domain_return_ok() method in DefaultCookiePolicy class got Undefined local variable exception with cookies returned by some websites. I couldn't see the cookie which caused the problem. But it seems this is because the local variables dotted_req_host and dotted_erhn are first assigned in a if statement and might not be always defined. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-19 20:50 Message: Logged In: YES user_id=1188172 This was already fixed with patch #1116583 on 2005/02/05. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295432&group_id=5470 From noreply at sourceforge.net Mon Sep 19 20:50:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 11:50:41 -0700 Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25 Message-ID: Bugs item #1295179, was opened at 2005-09-19 11:28 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 Please note that this 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: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 From noreply at sourceforge.net Mon Sep 19 23:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 14:44:02 -0700 Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat Message-ID: Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 Please note that this 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: Trent Mick (tmick) Assigned to: Nobody/Anonymous (nobody) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 From noreply at sourceforge.net Tue Sep 20 01:43:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 16:43:11 -0700 Subject: [ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs Message-ID: Bugs item #1093389, was opened at 2004-12-30 11:36 Message generated for change (Comment added) made by hildjj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 Please note that this 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: Joe Hildebrand (hildjj) Assigned to: Mark Hammond (mhammond) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. ---------------------------------------------------------------------- >Comment By: Joe Hildebrand (hildjj) Date: 2005-09-19 17:43 Message: Logged In: YES user_id=101697 For example, you could use this (awful hack): def PROP_TAG(ulPropType,ulPropID): a = (ulPropID<<16)|(ulPropType) if ulPropID & 0x8000: a = int(-((a ^ 0xffffffff) + 1)) return a mostly posted here so i can google for it next time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 From noreply at sourceforge.net Tue Sep 20 03:00:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 18:00:04 -0700 Subject: [ python-Bugs-1295909 ] inspect.getsource() misses single line blocks. Message-ID: Bugs item #1295909, was opened at 2005-09-19 21:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 Please note that this message will contain a full 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: Ron Adam (ronadam) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource() misses single line blocks. Initial Comment: While playing around with the inspect module I found that the Blockfinder doesn't recognize single line function definitions. Adding the following two lines to it fixes it, but I'm not sure if it causes problems anywhere else. C:\Python24\Lib>diff.py inspect.py inspect_.py *** inspect.py Tue Mar 15 13:22:02 2005 --- inspect_.py Mon Sep 19 14:26:26 2005 *************** *** 531,536 **** --- 531,538 ---- raise EndOfBlock, self.last elif type == tokenize.NAME and scol == 0: raise EndOfBlock, self.last + elif self.indent == 0: + raise EndOfBlock, self.last def getblock(lines): """Extract the block of code at the top of the given list of lines.""" Version info: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 def test(t): print '**',t,'**' print "Line:" def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass """This line should not be visible.""" print inspect.getsource(f) import inspect test("before") import inspect_ as inspect test("after") #-- output -- ** before ** Line: def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass Block: def f(): pass pass ** after ** Line: def f(): pass Block: def f(): pass pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 From noreply at sourceforge.net Tue Sep 20 05:18:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 20:18:54 -0700 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 11:58 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-09-20 13:18 Message: Logged In: YES user_id=29957 Er - while reverting it makes the code work again, I'm _really_ unhappy with this as a long-term solution. We really need to be getting rid of the old, unmaintained, and generally awful code of things like mimetools. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-19 19:12 Message: Logged In: YES user_id=4771 Reverted (Lib/cgi.py r1.85). ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-09-17 01:58 Message: Logged In: YES user_id=693077 Yes, please revert the patch. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-09-16 23:40 Message: Logged In: YES user_id=129426 I vote for revert, so that my code may run again on Python 2.5. Also see Josh's comment , with which I agree. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-16 21:52 Message: Logged In: YES user_id=4771 The problem is still there now (5 months later), so should I go ahead and revert the cgi.py changes of r1.83? I does break user code out there. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-04-18 09:39 Message: Logged In: YES user_id=693077 I've been playing with using the email parser to do the whole job of parsing the data, and I think it's too big of a change. It'd be very hard to ensure API compatibility and the same behaviour. I think that in the long run, it's the right thing to do, but I think that the API should change when that change is made. My recommendation for the time being is to revert the original patch that I made. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-09 08:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-07 09:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-05 10:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-05 09:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-05 02:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 21:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 18:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Tue Sep 20 07:14:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 22:14:26 -0700 Subject: [ python-Bugs-1296004 ] MemoryError in httplib Message-ID: Bugs item #1296004, was opened at 2005-09-20 05:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 Please note that this message will contain a full 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: Yue Zhang (yuezhang) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError in httplib Initial Comment: The problem from http://www.thescripts.com/forum/thread25490.html can be repeated here with python2.4.1 on WinXP. Test sample: sending about 5MB http data. It appears to be caused by line 545, httplib.py. chunk = self.fp.read(amt) It seems that reading too much from that sock causes leak. Thus trying to edit the line making it chunk = self.fp.read(min(amt,50000)) the problem will be solved. //Not sure whether it was sock error for using pure sock for http won't cause this problem. If you need an example of this bug, please contact me. Also, the method in httplib is using string concatenation, which might turn slow when the strings are large. An alternative is using a temp list to cache the string sections, and join the list at last. This will be faster, with the draw back of some more memory usage. Best regards, Zhang Yue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 From noreply at sourceforge.net Tue Sep 20 08:02:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 23:02:14 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 05:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule)?; Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-19 23:02 Message: Logged In: YES user_id=33168 I just tested with Python 2.4.2 on Linux with valgrind. It doesn't report any leaks. So this could be specific to Python 2.3.5, Windows, VC++ 6.0 or some other variation. Can you provide more info? For example, what module are you passing on the command line? Can you provide that code? What objects specifically do you think are leaking? Where were they allocated? ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-09-14 11:09 Message: Logged In: YES user_id=1327580 This behavior is evident with Python 2.3.5 built on Windows with VC++ 6.0. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 10:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-08-16 06:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 06:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Tue Sep 20 08:21:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 23:21:22 -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 06:05 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2005-09-19 23:21 Message: Logged In: YES user_id=33168 I think there was a fix checked in recently to address some (hopefully all) of these issues. Does the current CVS build on your HPUX box? ---------------------------------------------------------------------- Comment By: Vincent Jamart (ranma) Date: 2005-06-28 23:50 Message: Logged In: YES user_id=150220 This is how we managed to solve the problem here, but it's not a clean solution: #install script for HP-UX 11.xx CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include" export CPPFLAGS CC="/opt/aCC/bin/aCC -Ae +DD64" export CC CFLAGS="-Ae +DD64" export CFLAGS CXX="/opt/aCC/bin/aCC -Ae" export CXX CXXFLAGS="-Ae +DD64" export CXXFLAGS LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib" export LDFLAGS cd dist/src # # Do not use the --without-gcc flag because the CC env.var. will be # reset to 'cc' (which do not want) # Additionally we're not using --with-cxx because we want the system to use # the CC as it is defined above. The reason is that apparantly CFLAGS is not # taken into account thus all options should go into the definition of CC # ./configure --prefix=/usr/local/python --without-threads # # Finally after the configure we need to edit the resulting Makefile # by hand because 'ld' will be used to link the extension modules. However # 'ld' does not know the '+DD64' flag and we should link with aCC instead. # However there is no way to ask 'configure' to link with aCC instead of ld. ---------------------------------------------------------------------- Comment By: Vincent Jamart (ranma) Date: 2005-06-28 08:05 Message: Logged In: YES user_id=150220 This is how we managed to solve the problem here, but it's not a clean solution: #install script for HP-UX 11.xx CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include" export CPPFLAGS CC="/opt/aCC/bin/aCC -Ae +DD64" export CC CFLAGS="-Ae +DD64" export CFLAGS CXX="/opt/aCC/bin/aCC -Ae" export CXX CXXFLAGS="-Ae +DD64" export CXXFLAGS LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib" export LDFLAGS cd dist/src # # Do not use the --without-gcc flag because the CC env.var. will be # reset to 'cc' (which do not want) # Additionally we're not using --with-cxx because we want the system to use # the CC as it is defined above. The reason is that apparantly CFLAGS is not # taken into account thus all options should go into the definition of CC # ./configure --prefix=/usr/local/python --without-threads # # Finally after the configure we need to edit the resulting Makefile # by hand because 'ld' will be used to link the extension modules. However # 'ld' does not know the '+DD64' flag and we should link with aCC instead. # However there is no way to ask 'configure' to link with aCC instead of ld. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-06-19 02: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 03: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 Tue Sep 20 08:32:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Sep 2005 23:32: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 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-09-20 16:32 Message: Logged In: YES user_id=29957 As far as I know, the patches contributed by Elemental Security make current CVS HEAD work fine on ia64 HP/UX. Please do test them, though - I think Guido put some notes in the toplevel README about how to get the build to work. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 16:21 Message: Logged In: YES user_id=33168 I think there was a fix checked in recently to address some (hopefully all) of these issues. Does the current CVS build on your HPUX box? ---------------------------------------------------------------------- Comment By: Vincent Jamart (ranma) Date: 2005-06-29 16:50 Message: Logged In: YES user_id=150220 This is how we managed to solve the problem here, but it's not a clean solution: #install script for HP-UX 11.xx CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include" export CPPFLAGS CC="/opt/aCC/bin/aCC -Ae +DD64" export CC CFLAGS="-Ae +DD64" export CFLAGS CXX="/opt/aCC/bin/aCC -Ae" export CXX CXXFLAGS="-Ae +DD64" export CXXFLAGS LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib" export LDFLAGS cd dist/src # # Do not use the --without-gcc flag because the CC env.var. will be # reset to 'cc' (which do not want) # Additionally we're not using --with-cxx because we want the system to use # the CC as it is defined above. The reason is that apparantly CFLAGS is not # taken into account thus all options should go into the definition of CC # ./configure --prefix=/usr/local/python --without-threads # # Finally after the configure we need to edit the resulting Makefile # by hand because 'ld' will be used to link the extension modules. However # 'ld' does not know the '+DD64' flag and we should link with aCC instead. # However there is no way to ask 'configure' to link with aCC instead of ld. ---------------------------------------------------------------------- Comment By: Vincent Jamart (ranma) Date: 2005-06-29 01:05 Message: Logged In: YES user_id=150220 This is how we managed to solve the problem here, but it's not a clean solution: #install script for HP-UX 11.xx CPPFLAGS="+DD64 -I/usr/local/bzip2-1.0.3/include" export CPPFLAGS CC="/opt/aCC/bin/aCC -Ae +DD64" export CC CFLAGS="-Ae +DD64" export CFLAGS CXX="/opt/aCC/bin/aCC -Ae" export CXX CXXFLAGS="-Ae +DD64" export CXXFLAGS LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib" export LDFLAGS cd dist/src # # Do not use the --without-gcc flag because the CC env.var. will be # reset to 'cc' (which do not want) # Additionally we're not using --with-cxx because we want the system to use # the CC as it is defined above. The reason is that apparantly CFLAGS is not # taken into account thus all options should go into the definition of CC # ./configure --prefix=/usr/local/python --without-threads # # Finally after the configure we need to edit the resulting Makefile # by hand because 'ld' will be used to link the extension modules. However # 'ld' does not know the '+DD64' flag and we should link with aCC instead. # However there is no way to ask 'configure' to link with aCC instead of ld. ---------------------------------------------------------------------- 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 Tue Sep 20 13:56:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 04:56:02 -0700 Subject: [ python-Bugs-1296321 ] Python/C API Reference Manual, 7.2.1.1 Boolean Objects Message-ID: Bugs item #1296321, was opened at 2005-09-20 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=1296321&group_id=5470 Please note that this 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: Li Daobing (nichloas) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C API Reference Manual, 7.2.1.1 Boolean Objects Initial Comment: 1. PyBool_Check is double documented. [1] http://www.python.org/doc/2.3.5/api/boolObjects.html 2. PyBool_FromLong's return type should be PyObject*, this bug also in python2.4[2], the funtcion declaration in header file[3][4] is PyAPI_FUNC(PyObject *) PyBool_FromLong(long); [1] http://www.python.org/doc/2.3.5/api/boolObjects.html [2] http://www.python.org/doc/2.4.1/api/boolObjects.html [3] /usr/include/python2.3/boolobject.h [4] /usr/include/python2.4/boolobject.h Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296321&group_id=5470 From noreply at sourceforge.net Tue Sep 20 14:53:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 05:53:53 -0700 Subject: [ python-Bugs-1295909 ] inspect.getsource() misses single line blocks. Message-ID: Bugs item #1295909, was opened at 2005-09-20 03:00 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 Please note that this message will contain a full 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: Ron Adam (ronadam) >Assigned to: Hye-Shik Chang (perky) Summary: inspect.getsource() misses single line blocks. Initial Comment: While playing around with the inspect module I found that the Blockfinder doesn't recognize single line function definitions. Adding the following two lines to it fixes it, but I'm not sure if it causes problems anywhere else. C:\Python24\Lib>diff.py inspect.py inspect_.py *** inspect.py Tue Mar 15 13:22:02 2005 --- inspect_.py Mon Sep 19 14:26:26 2005 *************** *** 531,536 **** --- 531,538 ---- raise EndOfBlock, self.last elif type == tokenize.NAME and scol == 0: raise EndOfBlock, self.last + elif self.indent == 0: + raise EndOfBlock, self.last def getblock(lines): """Extract the block of code at the top of the given list of lines.""" Version info: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 def test(t): print '**',t,'**' print "Line:" def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass """This line should not be visible.""" print inspect.getsource(f) import inspect test("before") import inspect_ as inspect test("after") #-- output -- ** before ** Line: def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass Block: def f(): pass pass ** after ** Line: def f(): pass Block: def f(): pass pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 From noreply at sourceforge.net Tue Sep 20 14:54:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 05:54:12 -0700 Subject: [ python-Bugs-1296321 ] Python/C API Reference Manual, 7.2.1.1 Boolean Objects Message-ID: Bugs item #1296321, was opened at 2005-09-20 13:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296321&group_id=5470 Please note that this 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: Out of Date Priority: 5 Submitted By: Li Daobing (nichloas) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C API Reference Manual, 7.2.1.1 Boolean Objects Initial Comment: 1. PyBool_Check is double documented. [1] http://www.python.org/doc/2.3.5/api/boolObjects.html 2. PyBool_FromLong's return type should be PyObject*, this bug also in python2.4[2], the funtcion declaration in header file[3][4] is PyAPI_FUNC(PyObject *) PyBool_FromLong(long); [1] http://www.python.org/doc/2.3.5/api/boolObjects.html [2] http://www.python.org/doc/2.4.1/api/boolObjects.html [3] /usr/include/python2.3/boolobject.h [4] /usr/include/python2.4/boolobject.h Thanks ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-20 14:54 Message: Logged In: YES user_id=1188172 Both are already fixed in 2.4 CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296321&group_id=5470 From noreply at sourceforge.net Tue Sep 20 14:56:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 05:56:33 -0700 Subject: [ python-Bugs-1295909 ] inspect.getsource() misses single line blocks. Message-ID: Bugs item #1295909, was opened at 2005-09-20 03:00 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 Please note that this message will contain a full 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: Ron Adam (ronadam) >Assigned to: Ka-Ping Yee (ping) Summary: inspect.getsource() misses single line blocks. Initial Comment: While playing around with the inspect module I found that the Blockfinder doesn't recognize single line function definitions. Adding the following two lines to it fixes it, but I'm not sure if it causes problems anywhere else. C:\Python24\Lib>diff.py inspect.py inspect_.py *** inspect.py Tue Mar 15 13:22:02 2005 --- inspect_.py Mon Sep 19 14:26:26 2005 *************** *** 531,536 **** --- 531,538 ---- raise EndOfBlock, self.last elif type == tokenize.NAME and scol == 0: raise EndOfBlock, self.last + elif self.indent == 0: + raise EndOfBlock, self.last def getblock(lines): """Extract the block of code at the top of the given list of lines.""" Version info: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 def test(t): print '**',t,'**' print "Line:" def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass """This line should not be visible.""" print inspect.getsource(f) import inspect test("before") import inspect_ as inspect test("after") #-- output -- ** before ** Line: def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass Block: def f(): pass pass ** after ** Line: def f(): pass Block: def f(): pass pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 From noreply at sourceforge.net Tue Sep 20 16:10:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 07:10:03 -0700 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 18: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=1296433&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Rozhnov (rozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 From noreply at sourceforge.net Tue Sep 20 16:11:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 07:11:24 -0700 Subject: [ python-Bugs-1296434 ] Call by object reference sometimes call by value Message-ID: Bugs item #1296434, was opened at 2005-09-20 08: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=1296434&group_id=5470 Please note that this 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: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: Call by object reference sometimes call by value Initial Comment: The tutorial for 2.4.1, section 4.6 Defining Functions states that formal parameters are introduced into the local symbol table, making all calls call by object reference. The footnote points out that this means that changes to mutable objects will be seen by the caller. This is also illustrated in the example involving calling the list method append. It would be helpful if the example could point out that passing a value such as 1 passes an immutable object (the constant integer value 1), and so it is impossible to write code such as: a = 1 def f(val): val = val + 1 and expect that after the call a == 2, even though val == 2. My experience is that this is a confusing issue for new users, who may not understand that val = val + 1 tosses the object reference value passed, replacing it with a new local object. New users tend to see val as a mutable object, since we just changed the value, didn't we? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296434&group_id=5470 From noreply at sourceforge.net Tue Sep 20 18:56:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 09:56:30 -0700 Subject: [ python-Bugs-1296581 ] datetime.replace could take a dict Message-ID: Bugs item #1296581, was opened at 2005-09-20 16: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=1296581&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.replace could take a dict Initial Comment: Python 2.4.1. datetime.replace uses its kwargs to specify the fields, which I found a bit surprising. It could also take an equivalent dict. (Failing that, it could have a fuller docstring.) What I was actually trying to do was round to the nearest half hour. floor and ceil methods taking a timedelta would be nice too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296581&group_id=5470 From noreply at sourceforge.net Tue Sep 20 18:57:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 09:57:24 -0700 Subject: [ python-Bugs-1296581 ] datetime.replace could take a dict Message-ID: Bugs item #1296581, was opened at 2005-09-20 16:56 Message generated for change (Settings changed) made by tlynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296581&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.replace could take a dict Initial Comment: Python 2.4.1. datetime.replace uses its kwargs to specify the fields, which I found a bit surprising. It could also take an equivalent dict. (Failing that, it could have a fuller docstring.) What I was actually trying to do was round to the nearest half hour. floor and ceil methods taking a timedelta would be nice too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296581&group_id=5470 From noreply at sourceforge.net Wed Sep 21 02:12:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Sep 2005 17:12:50 -0700 Subject: [ python-Bugs-1297059 ] Incorrect return type for search() method Message-ID: Bugs item #1297059, was opened at 2005-09-21 00:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&group_id=5470 Please note that this 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: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect return type for search() method Initial Comment: The documentation for search() method of the IMAP4 object says that it returns a string, but it actually returns a tuple. >>> print imaplib.IMAP4.search.__doc__ Search mailbox for matching messages. (typ, [data]) = .search(charset, criterion, ...) 'data' is space separated list of matching message numbers. Error can be seen in docs on page: http://docs.python.org/lib/imap4-objects.html Yours, Noah ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&group_id=5470 From noreply at sourceforge.net Wed Sep 21 19:55:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 10:55:31 -0700 Subject: [ python-Bugs-1297986 ] hashable and mutable functions Message-ID: Bugs item #1297986, was opened at 2005-09-21 17:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&group_id=5470 Please note that this message will contain 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&group_id=5470 From noreply at sourceforge.net Wed Sep 21 22:18:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 13:18:30 -0700 Subject: [ python-Bugs-1298120 ] shlex does not support unicode Message-ID: Bugs item #1298120, was opened at 2005-09-21 13: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=1298120&group_id=5470 Please note that this 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: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: shlex does not support unicode Initial Comment: Should make prominent notice that shlex does not support unicode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&group_id=5470 From noreply at sourceforge.net Wed Sep 21 22:51:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 13:51:10 -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-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- 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 Wed Sep 21 22:55:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 13:55:20 -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-09-21 13:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- 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 Thu Sep 22 08:27:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 23:27:32 -0700 Subject: [ python-Bugs-1297986 ] hashable and mutable functions Message-ID: Bugs item #1297986, was opened at 2005-09-21 19:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&group_id=5470 Please note that this message will contain 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297986&group_id=5470 From noreply at sourceforge.net Thu Sep 22 08:27:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 23:27:48 -0700 Subject: [ python-Feature Requests-1297986 ] hashable and mutable functions Message-ID: Feature Requests item #1297986, was opened at 2005-09-21 19:55 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 Please note that this message will contain 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 From noreply at sourceforge.net Thu Sep 22 08:41:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 23:41:16 -0700 Subject: [ python-Bugs-694812 ] setup.py imports pwd before it's built if HOME not set Message-ID: Bugs item #694812, was opened at 2003-02-28 03:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py imports pwd before it's built if HOME not set Initial Comment: The function check_environ in Lib/distutils/util.py imports the 'pwd' module if the HOME environment variable is not set and os.name is 'posix' (as it is on at least Linux, Solaris, and Tru64 Unix). In the context of building Python, this happens before the pwd module has been built. The error is reproduced below. I can work around this easily. However, since the error message was somewhat oblique, it was confusing to diagnose. Perhaps there's some way to improve the diagnostic if the underlying problem cannot be fixed. case $MAKEFLAGS in *-s*) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py -q build;; *) CC='cc' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O -Olimit 1500' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 795, in ? main() File "./setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/core.py", line 110, in setup dist.parse_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 310, in parse_config_files filenames = self.find_config_files() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/dist.py", line 272, in find_config_files check_environ() File "/usr/var/tmp/sat/xmpy/system/support/build/Python-2.2.2/Lib/distutils/util.py", line 150, in check_environ import pwd ImportError: No module named pwd ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:41 Message: Logged In: YES user_id=1188172 Duplicate of #959576. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-17 19:15 Message: Logged In: YES user_id=1188172 Still present in current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694812&group_id=5470 From noreply at sourceforge.net Thu Sep 22 08:46:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 23:46:07 -0700 Subject: [ python-Bugs-924333 ] Build issues (lib path) on linux2-x86_64 Message-ID: Bugs item #924333, was opened at 2004-03-27 05:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Petrilli (petrilli) Assigned to: Nobody/Anonymous (nobody) Summary: Build issues (lib path) on linux2-x86_64 Initial Comment: The current CVS HEAD won't build "out of the box" on a Fedora x86_64 box, nor on any other Linux AMD64 platform. This is due to the fact that the libraries for many things are not in /usr/lib, but /usr/lib64, and the current 'autoconf' script, as well as the current setup.py do not look there. When added, they detect, build. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:46 Message: Logged In: YES user_id=1188172 The patch has been applied in 2004-11-13. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2004-11-04 23:09 Message: Logged In: YES user_id=671513 Just a note that this issue is still present in 2.4b2, and that the patch still applies. ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2004-10-20 06:54 Message: Logged In: YES user_id=671513 My patch is #1050475 ---------------------------------------------------------------------- Comment By: Bob Halley (rthalley) Date: 2004-10-20 03:01 Message: Logged In: YES user_id=671513 Python 2.4b1 still doesn't build "out of the box" on a Fedora Core 2 x86_64 box. The patch that was submitted got munged when applied; '/usr/lib/lib64' was added instead of the correct value of '/usr/lib64'. I will submit a new patch once I track down 3 'unexpected skips' in the regression tests. /Bob P.S. I'm very happy with 2.4 so far; good work all! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2004-04-08 19:05 Message: Logged In: YES user_id=205865 have you tried to port the patches from python 2.3.3 to HEAD? From your bug I understand they seem to work - do you have them? ---------------------------------------------------------------------- Comment By: Christopher Petrilli (petrilli) Date: 2004-03-30 21:46 Message: Logged In: YES user_id=38410 See patch #926209 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-30 00:19 Message: Logged In: YES user_id=21627 Can you submit a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470 From noreply at sourceforge.net Thu Sep 22 08:47:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Sep 2005 23:47:49 -0700 Subject: [ python-Bugs-872392 ] Finding X11 fails on SuSE Opteron Message-ID: Bugs item #872392, was opened at 2004-01-07 14:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872392&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Joseph Winston (josephwinston) Assigned to: Nobody/Anonymous (nobody) Summary: Finding X11 fails on SuSE Opteron Initial Comment: The 64 bit versions of libraries are in a different location. A possible patch would be: opteron:~/src/Languages/Python/Python-2.3.3 cvs diff setup.py Index: setup.py =================================== ================================ RCS file: /ts2/jwinston/CACHE/CVSROOT/jwinston/src/Langu ages/Python/Python-2.3.3/setup.py,v retrieving revision 1.1 diff -r1.1 setup.py 986a987,989 > elif os.path.exists('/usr/X11R6/lib64'): > include_dirs.append('/usr/X11R6/include') > added_lib_dirs.append('/usr/X11R6/lib64') ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 08:47 Message: Logged In: YES user_id=1188172 Your proposed path has been applied in 2004-11-13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872392&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:03:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:03:09 -0700 Subject: [ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 Message-ID: Bugs item #1276509, was opened at 2005-08-30 12:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this 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: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:04:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:04:16 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:19:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:19:19 -0700 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Thu Sep 22 09:21:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 00:21:12 -0700 Subject: [ python-Bugs-939699 ] Building python 2.3.3 RPM on Mandrake 9.2. fails Message-ID: Bugs item #939699, was opened at 2004-04-22 01:35 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=939699&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: fabien wahl (fwahl) Assigned to: Nobody/Anonymous (nobody) Summary: Building python 2.3.3 RPM on Mandrake 9.2. fails Initial Comment: The command (run as root) $ rpm --rebuild python2.3-2.3.3-2pydotorg.src.rpm yields the following (Two files not found) RPM build errors: user jafo does not exist - using root group jafo does not exist - using root user jafo does not exist - using root group jafo does not exist - using root user jafo does not exist - using root group jafo does not exist - using root File not found: /var/tmp/python2.3-2.3.3-root/usr/man/man1/python2.3.1.gz File not found: /var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/Tools/freeze/.cvsignore Does that mean that your src.rpm file is not complete? In the ../man/man1 directory, i have the file python2.3.1.bz2. This does not match line 227 and 310 of the .spec file ??? changing gz in bz2 solves this problem (at least it seems) In the .spec file, in the Tools section starting, line 233, the variable %{_prefix} is used, but it seems it should be %{__prefix} ?? Correcting __prefix yields another error what is the variable %{_bindir} pointing on? seems to be /usr/bin, but no instanciation found in the spec file. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:21 Message: Logged In: YES user_id=1188172 Both the 2.3.5 and 2.4.1 source RPMs build fine here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=939699&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:16:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:16:12 -0700 Subject: [ python-Feature Requests-1297986 ] hashable and mutable functions Message-ID: Feature Requests item #1297986, was opened at 2005-09-21 18:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 Please note that this message will contain 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-22 09:16 Message: Logged In: YES user_id=6656 def ishashable(ob): try: hash(ob) return True except TypeError: return False is the only reasonable way to implement this function (incidentally, do you know how hasattr works?). I don't see the need for a builtin, but am not feeling bolshy enough to just close the tracker item. Maybe someone else does. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:36:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:36:17 -0700 Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py Message-ID: Bugs item #999767, was opened at 2004-07-29 00:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 Please note that this 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: Stephan A. Terre (sfiedler) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Setup.local ignored by setup.py Initial Comment: This applies to Python 2.2.x, 2.3.x, and 2.4a1. Platforms seem to be all Unix flavors. I have zlib, readline, and Tk in an unusual location. There are also often older versions in the usual locations (/usr/local/lib, etc.). I put -L and -I flags pointing to the desired location of these libraries in entries for the appropriate extension modules in Setup.local, per the README. I specify all three extension modules as *shared* . When I build, the extension modules I specify in Setup.local get built twice: once directly from the Makefile, with the flags I request in Setup.local, then again from setup.py's build_ext phase, with the default flags. The second build is what's installed, so I end up using the wrong version of libz, libreadline, and libtk . The problem appears to be around line 152 of setup.py (CVS revision 1.190). There is code to ignore modules defined in Modules/Setup, but not modules defined in Modules/Setup.local . I'm not familiar with the text_file.TextFile class, so there may be a better way to do this, but one the fix is to loop over ['Modules/Setup', 'Modules/Setup.local'] rather than only reading Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:39:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:39:38 -0700 Subject: [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-04 21:49 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode >Group: Python 2.4 Status: Open >Resolution: None Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-07 19:56 Message: Logged In: YES user_id=21627 This tells me that we need a function to return the current locale's code page; this should return "cp936" in your case. The fact that Python does not have a codec for cp936 is an independent issue. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 23:21 Message: Logged In: YES user_id=561705 I have looked at the source code for the MS C library (it comes with VC++6) and I believe that that something equivalent to the following is used: char codepage[16]; GetLocaleInfo( GetThreadLocale(), LOCALE_IDEFAULTANSICODEPAGE, codepage, 16); This returns "1252" for "C" locale, and for the chinese locale that I was expirmenting with it returns "936". Python does not have an encoding "cp936", but from C the conversion with an explicit codepage produces the same results as mbstwcs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 22:33 Message: Logged In: YES user_id=21627 Is there any way to find out the encoding that mbstowcs uses? ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 22:00 Message: Logged In: YES user_id=561705 The windows C lib docs say that calling mbstowcs on the output of strftime (or calling wcsftime instead of strftime) will return the correct wide-character (utf-16?) string. This produces something that looks like it could be correct. Decoding with the 'mbcs' encoding in Python is not equivalent to calling mbstowcs because mbstowcs is locale-dependent. Perhaps it would be a good idea to have time.strftime return a unicode string. As this wouldn't be backward compatible, it could be done via a new function time.ustrftime, or via an optional unicode=True argument to the existing function. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 09:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-05 23:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:40:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:40:35 -0700 Subject: [ python-Bugs-901727 ] extra_path kwarg to setup() undocumented Message-ID: Bugs item #901727, was opened at 2004-02-21 16:04 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Thomas Heller (theller) Summary: extra_path kwarg to setup() undocumented Initial Comment: I can't find documentation for extra_path anywhere.. but this is the documentation I found by searching google ( http:// mail.python.org/pipermail/distutils-sig/2000-March/000803.html ), from an old USAGE.txt that sits in the CVS attic now: extra_path: information about extra intervening directories to put between 'install_lib' and 'install_sitelib', along with a .pth file to ensure that those directories wind up in sys.path. Can be a 1- or 2-tuple, or a comma-delimited string with 1 or 2 parts. The 1-element case is simpler: the .pth file and directory have the same name (except for ".pth"). Eg. if extra_path is "foo" or ("foo",), then Distutils sets 'install_site_lib' to 'install_lib' + "site-packages/foo", and puts foo.path in the "site-packages" directory; it contains just "foo". The 2-element case allows the .pth file and intervening directories to be named differently; eg. if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"), then Distutils will set 'install_site_lib' to 'install_lib' + "site-packages/foo/bar/baz", and put "foo.pth" containing "foo/bar/baz" in the "site-packages" directory. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-05-17 18:16 Message: Logged In: YES user_id=580910 extra_path also doesn't have a command-line equivalent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:41:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:41:17 -0700 Subject: [ python-Bugs-984219 ] hotspot.stats.load is very slow Message-ID: Bugs item #984219, was opened at 2004-07-02 19:53 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470 Please note that this message will contain a full 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: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: hotspot.stats.load is very slow Initial Comment: hotspot.Profile generates a very large (10-70Mbytes) file for complex applications. hotspot.stats.load loads the profile file very slow. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2004-07-02 20:10 Message: Logged In: YES user_id=142612 OS: WinXP Prof ENG SP1 CPU: Intel P4 Northwood 1.6G MEM: 512Mbyte, 800MHz RDRAM ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2004-07-02 20:09 Message: Logged In: YES user_id=142612 Python version: 2.3.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:42:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:42:27 -0700 Subject: [ python-Feature Requests-1296581 ] datetime.replace could take a dict Message-ID: Feature Requests item #1296581, was opened at 2005-09-20 18:56 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&group_id=5470 Please note that this message will contain 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: 1 Submitted By: Tom Lynn (tlynn) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: datetime.replace could take a dict Initial Comment: Python 2.4.1. datetime.replace uses its kwargs to specify the fields, which I found a bit surprising. It could also take an equivalent dict. (Failing that, it could have a fuller docstring.) What I was actually trying to do was round to the nearest half hour. floor and ceil methods taking a timedelta would be nice too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1296581&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:43:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:43:41 -0700 Subject: [ python-Feature Requests-880951 ] "ez" format code for ParseTuple() Message-ID: Feature Requests item #880951, was opened at 2004-01-21 00:03 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=880951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Unicode >Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jon Willeke (willeke) Assigned to: M.-A. Lemburg (lemburg) Summary: "ez" format code for ParseTuple() Initial Comment: I'm using Python 2.3.3 on SuSE Linux 8.2. It would be nice to have an "ez" format code that is to "es" as "z" is to "s". Whereas the "s" and "z" codes depend on the default encoding, "es" lets you specify the encoding, which is useful for interfacing with GTK+ and GNOME libraries, which have largely standardized on UTF-8. I think it is possible to simulate the desired behavior with "O&", but it would be simpler with "ez". ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-02 18:01 Message: Logged In: YES user_id=38388 No answers... lowering the priority. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 18:41 Message: Logged In: YES user_id=38388 Can you elaborate on the use case ? I'm asking because I don't find the 'z' code particulary useful myself because there are more elegant ways to deal with optional arguments. ---------------------------------------------------------------------- Comment By: Jon Willeke (willeke) Date: 2004-01-22 00:29 Message: Logged In: YES user_id=185468 I'm attaching a patch that adds support for the "ez" and "ez#" format codes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=880951&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:46:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:46:13 -0700 Subject: [ python-Feature Requests-467924 ] Improve the ZipFile Interface Message-ID: Feature Requests item #467924, was opened at 2001-10-04 17:54 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 Please note that this message will contain 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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-05-09 20:23 Message: Logged In: YES user_id=335935 The zipfile interface should match the tarfile interface. At the mininum is should work for this example: import zipfile zip = zipfile.open("sample.zip", "r") for zipinfo in zip: print tarinfo.name, "is", tarinfo.size, "bytes in size and is", zip.extract(zipinfo) zip.close() This closely matchs the 'tarfile' module. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2003-07-31 16:22 Message: Logged In: YES user_id=196786 It would also be very useful to be able to have ZipFile read/write the uncompressed file data from/to a file-like object, instead of just strings and files (respectively). I would like to use this module to work with zip files containing large files, but this is unworkable because the current implementation would use excessive amounts of memory. Currently, read() reads all of the compressed data into memory, then uncompresses it into memory. For files which may be hundreds of megabytes compressed, this is undesirable. Likewise for write(), I would like to be able to stream data into a zip file, passing in a ZipInfo to specify the metadata as is done with writestr(). The implementation of this functionality is quite straightforward, but I am not sure whether (or how) the interface should change. Some other parts of the library allow for a file object to be passed to the same interface which accepts a filename. The object is examined to see if it has the necessary read/write methods and if not, it is assumed to be a filename. Would this be the correct way to do it? I, too, am a bit irked by the lack of symmetry exhibited by read vs. write/writestr, and think that the interface suggested above would be a significant improvement. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 21:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:47:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:47:04 -0700 Subject: [ python-Feature Requests-750423 ] event handling support Message-ID: Feature Requests item #750423, was opened at 2003-06-07 04:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=750423&group_id=5470 Please note that this message will contain 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: Lila Chase (lchase) Assigned to: Nobody/Anonymous (nobody) Summary: event handling support Initial Comment: We are interested in a general solution to the problem of getting various Python packages that must deal with events to cooperate. Python currently provides a hook to readline (PyOS_InputHook) that packages use for event handling. However, we have found so far that the following Python packages conflict over use of readline: - Tkinter and PyGist - PyMPI and PyGist As Dave Munro explains below, the best solution to this problem is to add more general event handling capability to Python. We ask Python developers to seriously consider this important change. Thank you. Lila Chase lchase at llnl.gov An explanation of the event handling problem is provided in the following note from Dave Munro: Date: Wed, 14 May 2003 12:11:16 -0700 From: "David H. Munro" <munro> Reply-To: munro1 at llnl.gov Gist does not really care about readline, of course. There are only two requirements: (1) Gist must receive an idle event. That is, whenever all other events have been processed (or during idle processing), gist needs to be called in order to process its own deferred tasks. This is where the apparent readline dependence appears: When it has nothing left to do, python calls readline to wait for the next input line. This is the only hook I know of in python for getting an idle event delivered. Unfortunately, it is way overloaded (for example, tkinter steals the same hook as well). The problem is that the python event loop is "inside out" -- it needs to be fixed such that readline is called only as the result of input on stdin, putting stdin on the same footing as any other input source. (2) The file descriptor for gist's X socket(s) must be included in the list of descriptors that will trigger python to "wake up" when it is blocked waiting for new input. Technically, this means that python must call either poll() or select() when it goes idle, and that gist's X socket must be among the descriptors included in the list provided for those routines. Furthermore, when input actually arrives on that socket, python must call gist's event handler. Python currently has no direct support for asynchronous input, which is why gist steals the readline hook. That approach will break anyone else who needs such a callback, since the current gist input hook only wakes up for its own X socket(s) and stdin. Gist does have a full event model, so other packages could register with gist if they wanted to get event callbacks of their own, but of course any package which did that would itself become dependent on gist. The only correct place to do this job is therefore in python itself; it currently just does not support such a notion. Part of the technical problem with such support is that things are quitedifferent under both Windows and MacOS <=9. It is quite challenging to find an abstraction which covers all those cases. For example, (2) is not necessary (for gist) at all under Windows, since the OS ensures that events on gist window s generate gist event callbacks. I hope this helps to clarify the problems gist has in coexisting with python. Neither of these problems is particularly difficult, although the politics of getting such changes into the python distribution is probably very tricky. The good news is that these are the only really serious problems; everything else is purely a pygist problem. I don't know enough about python to judge the path of least resistance to get them implemented, or to accomodate the other packages that have gone after python's existing input hooks, but I'm sure there must be a fairly unobtrusive way to go about it. Dave P.S.-There is a subtlety in the semantics of idle events, which makes it impossible for gist to rely on the Tcl/Tk model for handling them. If anyone undertakes the addition of idle event machinery to python, they should take care to avoid the same pitfall: In Tcl/Tk, you can request an idle event, and after this request you will indeed get a callback just before Tcl/Tk goes idle. However, with Tcl/Tk semantics, you only get one such callback, and you need to renew your request to get another idle callback. This makes the entire mechanism worthless for gist, as it is currently implemented, because gist does not have hooks at the (many) points it might generate idle tasks; it expects to be able to permanently register an idle event handler, and to have the caller actually go idle when that returns. Possibly gist could be rewritten for the Tcl/Tk semantics, but for a new implementation, it would be better to support the more inclusive semantics. (The decision about whether an idle callback is necessary happens at a much higher level in the gist design than its event loop; I am not eager to mix the abstraction levels for the sake of supporting Tcl/Tk's idle event model.) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-06-08 17:44 Message: Logged In: YES user_id=2772 Please see http://python.org/peps/ for information on submitting a python enhancement proposal. This is probably a large and complex enough issue that it will have to go through the PEP process before it would be considered. Another non-PEP or pre-PEP approach would be to develop this event-handling support separately from the three packages mentioned (Tkinter, PyMPI, and PyGist). Presumably this new package would hook PyOS_InputHook and/or provide a "mainloop"-type function, providing the abstractions needed by Tkinter, PyMPI, and PyGist. (Of course, you mention the "X socket" for one of the packages---for the solution to be acceptable in Python, I predict that it would need to at least work on Win32 as well, where event handling is a whole different kettle of monkeys, or whatever mixed and disturbing metaphor you care to use) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=750423&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:49:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:49:06 -0700 Subject: [ python-Feature Requests-1015254 ] Create cgi.FieldStorage._get_new_instance method as factory Message-ID: Feature Requests item #1015254, was opened at 2004-08-24 15:41 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1015254&group_id=5470 Please note that this message will contain 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: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: Create cgi.FieldStorage._get_new_instance method as factory Initial Comment: and use this factory method instead of calling self.__class__ or FieldStorage.FieldStorageClass in FieldStorage.read_multi directly. This would allow people deriving from FieldStorage to customize the list of parameters given to the constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1015254&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:50:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:50:01 -0700 Subject: [ python-Feature Requests-1106316 ] slightly easier way to debug from the exception handler Message-ID: Feature Requests item #1106316, was opened at 2005-01-20 23:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1106316&group_id=5470 Please note that this message will contain 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: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... ---------------------------------------------------------------------- Comment By: Leonardo Rochael Almeida (rochael) Date: 2005-01-21 14:20 Message: Logged In: YES user_id=200267 I don't have any particular reason to prefer post_mortem() to pm(). The knowledgeable Python maintainers surely are better equiped than I am to know if pm() looking beyond sys.last_traceback is a worse break of assumptions than post_mortem() having it's only parameter being optional or the other way around :-) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 23:51 Message: Logged In: YES user_id=139309 Why put this in pdb.post_mortem() if we can just put it in pdb.pm()? pdb.pm() seems to already be for this purpose (except it currently only works from the interactive interpreter as you mention). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1106316&group_id=5470 From noreply at sourceforge.net Thu Sep 22 10:51:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 01:51:20 -0700 Subject: [ python-Bugs-1013800 ] No documentation for PyFunction_* (C-Api) Message-ID: Bugs item #1013800, was opened at 2004-08-22 16:10 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470 Please note that this 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: Henning G?nther (der_eq) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: No documentation for PyFunction_* (C-Api) Initial Comment: I'm missing documentation for the PyFunction_* api-calls. They don't appear in the documentation but in http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/funcobject.c?rev=2.66&view=log ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470 From noreply at sourceforge.net Thu Sep 22 11:20:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 02:20:10 -0700 Subject: [ python-Feature Requests-1297986 ] hashable and mutable functions Message-ID: Feature Requests item #1297986, was opened at 2005-09-21 12:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 Please note that this message will contain 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: ChristianJ (cybb20) Assigned to: Nobody/Anonymous (nobody) Summary: hashable and mutable functions Initial Comment: It is not easy to check if an object is hashable, ie hasattr(list(), '__hash__') -> True try: hash(list()) except TypeError: pass seems to be a possible way to see if an object is hashable, however it is not satisfiable that this information needs to be retrieved by using exception handling. My proposal: There should be a hashable(obj) function returning a bool object and additionally it would be nice to have something like ismutable(obj) function, possibly as built-in functions. Reason: callable() is a built-in function and returns information about an object whether it's callable or not, that is a basic info about this object. If an object is hashable or mutable is a state of an object that is also very important to know. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-22 04:20 Message: Logged In: YES user_id=80475 Adding a third -1 from me and closing the RFE. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-22 03:16 Message: Logged In: YES user_id=6656 def ishashable(ob): try: hash(ob) return True except TypeError: return False is the only reasonable way to implement this function (incidentally, do you know how hasattr works?). I don't see the need for a builtin, but am not feeling bolshy enough to just close the tracker item. Maybe someone else does. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 01:27 Message: Logged In: YES user_id=1188172 > try: hash(list()) > except TypeError: pass > > seems to be a possible way to see if an object is > hashable, however it is not satisfiable that this > information needs to be retrieved by using exception > handling. Why? > My proposal: > There should be a hashable(obj) function returning a > bool object and additionally it would be nice to have > something like ismutable(obj) function, possibly as > built-in functions. How should "ismutable" be implemented? > Reason: > callable() is a built-in function and returns > information about an object whether it's callable or > not, that is a basic info about this object. > If an object is hashable or mutable is a state of an > object that is also very important to know. It's easier to ask for forgiveness than permission. Even callable() has been called a mistake. Just call it and see where you come. So, -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1297986&group_id=5470 From noreply at sourceforge.net Thu Sep 22 14:59:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 05:59:23 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 15: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=1298709&group_id=5470 Please note that this 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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Thu Sep 22 15:22:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 06:22:53 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 15:59 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this 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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 16:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Thu Sep 22 17:56:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 08:56:58 -0700 Subject: [ python-Feature Requests-467924 ] Improve the ZipFile Interface Message-ID: Feature Requests item #467924, was opened at 2001-10-04 10:54 Message generated for change (Comment added) made by crhode You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 Please note that this message will contain 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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- Comment By: Chuck Rhode (crhode) Date: 2005-09-22 10:56 Message: Logged In: YES user_id=988879 I've been trying to read map files put out by the Census Bureau. These ZIP archives are downloaded from government contractors' sites by county. Within each county archive are several ZIP files for each map layer (roads, streams, waterbodies, etc). Each contains the elements of an ESRI shapefile database (.shp, .shx., and .dbf files). This doesn't make a lot of sense to me, either, because there's no compression advantage to making an archive of an archive. The technique is used purely for organizational purposes because ZIP does not compress subdirectories. Note: I've never seen a TAR of TAR files because TAR *does* compress subdirectories. What I've been struggling with is a way to leave these archives in their compressed form and still do *python* I/O on them. There is a tree organization to them, after all, just as with traditional os.path directories. I've designed some objects that let me retrieve the most recent file, ZIP member, or TAR member by name from a given path to a repository of such archives. What I get is a StreamIO object that I can subsequently put back where it came from. What would be nice is if there already were objects available to manipulate normal os.path directories comingled with ZIP and TAR archives. What would be nicer is if I/O could be opened at the character/line level transparently without regard to whether the source/destination was a file or an archive member within such a structure. In the days of hardware compression and on-the-fly encryption/decryption of I/O, is this too much to ask? -ccr- ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-05-09 13:23 Message: Logged In: YES user_id=335935 The zipfile interface should match the tarfile interface. At the mininum is should work for this example: import zipfile zip = zipfile.open("sample.zip", "r") for zipinfo in zip: print tarinfo.name, "is", tarinfo.size, "bytes in size and is", zip.extract(zipinfo) zip.close() This closely matchs the 'tarfile' module. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2003-07-31 09:22 Message: Logged In: YES user_id=196786 It would also be very useful to be able to have ZipFile read/write the uncompressed file data from/to a file-like object, instead of just strings and files (respectively). I would like to use this module to work with zip files containing large files, but this is unworkable because the current implementation would use excessive amounts of memory. Currently, read() reads all of the compressed data into memory, then uncompresses it into memory. For files which may be hundreds of megabytes compressed, this is undesirable. Likewise for write(), I would like to be able to stream data into a zip file, passing in a ZipInfo to specify the metadata as is done with writestr(). The implementation of this functionality is quite straightforward, but I am not sure whether (or how) the interface should change. Some other parts of the library allow for a file object to be passed to the same interface which accepts a filename. The object is examined to see if it has the necessary read/write methods and if not, it is assumed to be a filename. Would this be the correct way to do it? I, too, am a bit irked by the lack of symmetry exhibited by read vs. write/writestr, and think that the interface suggested above would be a significant improvement. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 14:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 From noreply at sourceforge.net Thu Sep 22 19:27:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 10:27:07 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 17: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=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Thu Sep 22 21:32:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 12:32:31 -0700 Subject: [ python-Bugs-1299051 ] "Howto RE" link is dead Message-ID: Bugs item #1299051, was opened at 2005-09-22 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=1299051&group_id=5470 Please note that this 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: Macs R We (macsrwe) Assigned to: Nobody/Anonymous (nobody) Summary: "Howto RE" link is dead Initial Comment: On page http://www.python.org/doc/2.3.5/lib/re-syntax.html The link to "Regular expressions HOWTO" documentation ends up at http://www.amk.ca/python/howto/, which is a dead host. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&group_id=5470 From noreply at sourceforge.net Thu Sep 22 23:54:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 14:54:26 -0700 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 07:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Mike Rozhnov (rozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 14:54 Message: Logged In: YES user_id=33168 I can reproduce on Linux with current CVS and expat 1.95.5-2. Note the size of the data only needs to be greater than 1024. xml = "%s" % ('a' * 1025) I am not certain this problem is specific to Python. It might be down in expat only. Need to investigate further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 From noreply at sourceforge.net Fri Sep 23 00:19:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 15:19:46 -0700 Subject: [ python-Bugs-1299187 ] build fails on Solaris 10 for Objects/complexobject.c Message-ID: Bugs item #1299187, was opened at 2005-09-22 22:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 Please note that this 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: Kenneth Simpson (dharmakat) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Solaris 10 for Objects/complexobject.c Initial Comment: Solaris 10 gcc 3.4.4 gas 2.16.1 python 2.4.2c1 /usr/devtools/bin/gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 From noreply at sourceforge.net Fri Sep 23 03:45:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 18:45:23 -0700 Subject: [ python-Bugs-1299520 ] Tkinter Scale returns only integer from/to values Message-ID: Bugs item #1299520, was opened at 2005-09-22 18:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 Please note that this 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: Tom Goddard (tom_goddard) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter Scale returns only integer from/to values Initial Comment: Tk "scale" widgets allow floating point range values. But Tkinter.Scale returns integer values for 'from' and 'to' attributes even when they were set to non-integer values. >>> s = Tkinter.Scale() >>> s['from'] = 1.23 >>> s['from'] 1.0 The problem is in the Tkinter.Scale.get method. It converts the floating point value to an integer. >From Tkinter.py: getint = int class Scale(Widget): def get(self): """Get the current value as integer or float.""" value = self.tk.call(self._w, 'get') try: return getint(value) except ValueError: return getdouble(value) def set(self, value): """Set the value to VALUE.""" self.tk.call(self._w, 'set', value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 From noreply at sourceforge.net Fri Sep 23 04:20:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 19:20:23 -0700 Subject: [ python-Bugs-1299520 ] Tkinter Scale returns only integer from/to values Message-ID: Bugs item #1299520, was opened at 2005-09-22 18:45 Message generated for change (Settings changed) made by tom_goddard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Submitted By: Tom Goddard (tom_goddard) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter Scale returns only integer from/to values Initial Comment: Tk "scale" widgets allow floating point range values. But Tkinter.Scale returns integer values for 'from' and 'to' attributes even when they were set to non-integer values. >>> s = Tkinter.Scale() >>> s['from'] = 1.23 >>> s['from'] 1.0 The problem is in the Tkinter.Scale.get method. It converts the floating point value to an integer. >From Tkinter.py: getint = int class Scale(Widget): def get(self): """Get the current value as integer or float.""" value = self.tk.call(self._w, 'get') try: return getint(value) except ValueError: return getdouble(value) def set(self, value): """Set the value to VALUE.""" self.tk.call(self._w, 'set', value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299520&group_id=5470 From noreply at sourceforge.net Fri Sep 23 06:28:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 21:28:35 -0700 Subject: [ python-Bugs-1297059 ] Incorrect return type for search() method Message-ID: Bugs item #1297059, was opened at 2005-09-20 17:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&group_id=5470 Please note that this 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: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect return type for search() method Initial Comment: The documentation for search() method of the IMAP4 object says that it returns a string, but it actually returns a tuple. >>> print imaplib.IMAP4.search.__doc__ Search mailbox for matching messages. (typ, [data]) = .search(charset, criterion, ...) 'data' is space separated list of matching message numbers. Error can be seen in docs on page: http://docs.python.org/lib/imap4-objects.html Yours, Noah ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:28 Message: Logged In: YES user_id=33168 Thanks. I removed the sentance about returned data since there is a description of all return values at the top of the doc. I also corrected the examples. Checked in as: * Doc/lib/libimaplib.tex 1.34 and 1.30.4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1297059&group_id=5470 From noreply at sourceforge.net Fri Sep 23 06:31:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 21:31:20 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 05:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this 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: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 06:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Fri Sep 23 06:46:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 21:46:27 -0700 Subject: [ python-Bugs-1299187 ] build fails on Solaris 10 for Objects/complexobject.c Message-ID: Bugs item #1299187, was opened at 2005-09-22 15:19 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kenneth Simpson (dharmakat) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Solaris 10 for Objects/complexobject.c Initial Comment: Solaris 10 gcc 3.4.4 gas 2.16.1 python 2.4.2c1 /usr/devtools/bin/gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:46 Message: Logged In: YES user_id=33168 Dupe of 1276509 and possibly others. If you could work on a patch that would be great. I don't have access to Solaris 10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299187&group_id=5470 From noreply at sourceforge.net Fri Sep 23 06:46:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 21:46:32 -0700 Subject: [ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Message-ID: Bugs item #1276509, was opened at 2005-08-30 03:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this 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: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) >Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 00:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 From noreply at sourceforge.net Fri Sep 23 06:56:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Sep 2005 21:56:19 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 05:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this 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: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:56 Message: Logged In: YES user_id=33168 Patch is also #1275079. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 21:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 06:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Fri Sep 23 09:33:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 00:33:26 -0700 Subject: [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 16:25 Message generated for change (Comment added) made by mdavidoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile 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_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 00:33 Message: Logged In: YES user_id=1200009 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 780576. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-19 10:05 Message: Logged In: YES user_id=671362 On a linux box for my work, I had similar fail(test_ioctl and test_ioctl_mutate). My System: * Python : 2.3.3, 2.4 * kernel : 2.4.22 * GCC : 2.95.3 * glibc : 2.2 I don't know why but somehow test_ioctl.py seems to be invoked in the background on 'make test' process, which resuls in 2 fails. Maybe the easiest way to make test_ioctl fail is : $ ./python ./Lib/test/regrtest.py test_ioctl & ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 08:06 Message: Logged In: YES user_id=6656 Heh, yes it certainly would be easier if I (or anyone else) could reproduce this. However, this is the first I've heard of it, and I'd have thought/hoped that there are other people running the release candidates on Debian testing... glibc is very much a guess scapegoat, don't jeopardize your system just for me. I suggested the '-r' thing because it's the sort of thing that can be done in the background. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 08:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 07:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 05:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 16:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 16:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 16:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 16:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile 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_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply at sourceforge.net Fri Sep 23 09:35:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 00:35:58 -0700 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 16:04 Message generated for change (Comment added) made by mdavidoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 00:35 Message: Logged In: YES user_id=1200009 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 777867. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-31 15:30 Message: Logged In: YES user_id=1103758 Sorry, that was not helpful: I meant test TIOCGPGRP on a pseudo-tty that the testing process creates. Another alternative would be to test some STREAMS ioctl against a stream/pipe that the process creates. But yes, this quickly gets complicated. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 11:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-14 06:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 15:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 03:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 08:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 04:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 09:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 03:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Fri Sep 23 10:37:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 01:37:35 -0700 Subject: [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-26 01:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile 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_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-23 10:37 Message: Logged In: YES user_id=1188172 I verified this. Closing accordingly ---------------------------------------------------------------------- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 09:33 Message: Logged In: YES user_id=1200009 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 780576. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-03-19 19:05 Message: Logged In: YES user_id=671362 On a linux box for my work, I had similar fail(test_ioctl and test_ioctl_mutate). My System: * Python : 2.3.3, 2.4 * kernel : 2.4.22 * GCC : 2.95.3 * glibc : 2.2 I don't know why but somehow test_ioctl.py seems to be invoked in the background on 'make test' process, which resuls in 2 fails. Maybe the easiest way to make test_ioctl fail is : $ ./python ./Lib/test/regrtest.py test_ioctl & ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 17:06 Message: Logged In: YES user_id=6656 Heh, yes it certainly would be easier if I (or anyone else) could reproduce this. However, this is the first I've heard of it, and I'd have thought/hoped that there are other people running the release candidates on Debian testing... glibc is very much a guess scapegoat, don't jeopardize your system just for me. I suggested the '-r' thing because it's the sort of thing that can be done in the background. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 17:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 16:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 14:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 01:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 01:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 01:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 01:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile 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_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply at sourceforge.net Fri Sep 23 11:01:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 02:01:34 -0700 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 01:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-23 11:01 Message: Logged In: YES user_id=1188172 Verified. Closing accordingly. ---------------------------------------------------------------------- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 09:35 Message: Logged In: YES user_id=1200009 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 777867. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-09-01 00:30 Message: Logged In: YES user_id=1103758 Sorry, that was not helpful: I meant test TIOCGPGRP on a pseudo-tty that the testing process creates. Another alternative would be to test some STREAMS ioctl against a stream/pipe that the process creates. But yes, this quickly gets complicated. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 20:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-14 15:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-14 00:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 12:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 09:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 09:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 18:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 18:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 17:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 13:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 20:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 18:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 12:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Fri Sep 23 11:31:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 02:31:34 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Settings changed) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) >Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Fri Sep 23 13:18:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 04:18:27 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 04:59 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this 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: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-09-23 03:18 Message: Logged In: YES user_id=86216 This is a known Cygwin issues which will be fixed in 1.5.19: http://cygwin.com/ml/cygwin/2005-07/msg01257.html I recommend that Cygwin users temporarily patch their netinet/in.h instead of changing the Python source code. And yes, I still maintain Cygwin Python. :,) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:56 Message: Logged In: YES user_id=33168 Patch is also #1275079. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 05:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Fri Sep 23 19:43:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 10:43:41 -0700 Subject: [ python-Bugs-1138653 ] subprocesss module retains older license header Message-ID: Bugs item #1138653, was opened at 2005-02-17 23:46 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 Please note that this message will contain a full 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: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: subprocesss module retains older license header Initial Comment: The header of the file seems to imply that the module is licensed separately from the standard Python license: # subprocess - Subprocesses with accessible I/O streams # # For more information about this module, see PEP 324. # # Copyright (c) 2003-2004 by Peter Astrand # # By obtaining, using, and/or copying this software and/or its # associated documentation, you agree that you have read, understood, # and will comply with the following terms and conditions: # # Permission to use, copy, modify, and distribute this software and # its associated documentation for any purpose and without fee is # hereby granted, provided that the above copyright notice appears in # all copies, and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of the # author not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. # # THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS # OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, # NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION # WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-09-23 19:43 Message: Logged In: YES user_id=344921 Fixed in revision 1.8.2.5 (2.4 branch) and 1.21 (HEAD). ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-03-19 08:14 Message: Logged In: YES user_id=344921 >Have you signed a contributor agreement yet, Peter? Yes. >You can replace the above license if you have signed the >contributor agreement with: > >Copyright 2005 by Peter ?strand. >Licensed to PSF under a Contributor Agreement I guess this will work good when subprocess.py is distributed with the Python distribution, but subprocess.py is also distributed separately, as an addon to Python 2.2/2.3. In this case, it feels better to include the license itself. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-03-04 03:45 Message: Logged In: YES user_id=357491 Have you signed a contributor agreement yet, Peter? If you have your code has already been relicensed to the PSF under the PSF license. If you haven't you will be asked to eventually and that will retroactively relicense your code over to the PSF, essentially negating all of this pre- existing license. You can replace the above license if you have signed the contributor agreement with: Copyright 2005 by Peter ?strand. Licensed to PSF under a Contributor Agreement Assuming I am right. =) You can double-check by emailing psf at python.org or ask at PyCon if you are attending. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-03-03 22:22 Message: Logged In: YES user_id=344921 How should the license header look like, then? Basically, I've used xmlrpclib.py as an example. Many other modules have no license header at all, but this might be a problem when subprocess.py is distributed separately from Python. Or? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 From noreply at sourceforge.net Fri Sep 23 23:02:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 14:02:00 -0700 Subject: [ python-Bugs-1294232 ] Error in metaclass search order Message-ID: Bugs item #1294232, was opened at 2005-09-17 21:07 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 Please note that this 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: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. ---------------------------------------------------------------------- Comment By: Pedro Werneck (pwerneck) Date: 2005-09-18 20:42 Message: Logged In: YES user_id=696687 Yes. I think this confusion was caused because of the lack of documentation on this topic, especially on the case described here, which seems to break some rules. Since the "Unifying types and classes" essay seems to be the most used Python document about this topic and, I suggest the first rule on determining a metaclass be changed from: "If dict['__metaclass__'] exists, it is used." To something like: "If dict['__metaclass__'] exists and is equal to, or a subclass of, each of the metaclasses of the bases, it is used; if it exists and is a base class of any metaclass of the bases, the most specialized metaclass in the hierarchy is used; if it exists and doesn't satisfies any of these constraints, TypeError is raised." ---------------------------------------------------------------------- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 19:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 From noreply at sourceforge.net Sat Sep 24 00:01:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 15:01:09 -0700 Subject: [ python-Bugs-1296434 ] Call by object reference sometimes call by value Message-ID: Bugs item #1296434, was opened at 2005-09-20 10:11 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296434&group_id=5470 Please note that this 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: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: Call by object reference sometimes call by value Initial Comment: The tutorial for 2.4.1, section 4.6 Defining Functions states that formal parameters are introduced into the local symbol table, making all calls call by object reference. The footnote points out that this means that changes to mutable objects will be seen by the caller. This is also illustrated in the example involving calling the list method append. It would be helpful if the example could point out that passing a value such as 1 passes an immutable object (the constant integer value 1), and so it is impossible to write code such as: a = 1 def f(val): val = val + 1 and expect that after the call a == 2, even though val == 2. My experience is that this is a confusing issue for new users, who may not understand that val = val + 1 tosses the object reference value passed, replacing it with a new local object. New users tend to see val as a mutable object, since we just changed the value, didn't we? :) ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-23 18:01 Message: Logged In: YES user_id=593130 I agree that there are problems of beginners misunderstanding Python's object model. However, the proposed fix is not exactly correct. Python *always* calls functions by binding local parameter names to argument objects or lists or dicts thereof. Whenever a name is rebound to a new object, it is *always* unbound from the previous object, as it must be. Mutability is irrelevant. So is localness induced by a function call. Changing locality and mutability, your example is equivalent to a = 1 val = a val = val + 1 a = [1] val = a val = val + [2] # or def f(val): val = val + [2] f(a) *all* of which leave 'a' unchanged, but all of which a beginner might think change 'a'. Perhaps you can suggest a different rewording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296434&group_id=5470 From noreply at sourceforge.net Sat Sep 24 01:05:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 16:05:17 -0700 Subject: [ python-Bugs-1302267 ] A command history for the idle interactive shell Message-ID: Bugs item #1302267, was opened at 2005-09-24 01: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=1302267&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: A command history for the idle interactive shell Initial Comment: 1. Start IDLE. 2. In the IDLE shell that pops up, write a line of Python code and press enter. 3. Pretend you made a spelling mistake in step two. So you press up and try to fix it but you can't because the cursor is moved and the IDLE shell doesn't work at all like the normal CPython shell. In fact, there is no easy way at all to get back to the last line of input for correcting spelling mistakes. I think there should be one. Maybe ALT+Up could do what Up does in the CPython shell? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302267&group_id=5470 From noreply at sourceforge.net Sat Sep 24 07:53:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Sep 2005 22:53:28 -0700 Subject: [ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket Message-ID: Bugs item #1302793, was opened at 2005-09-24 17:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this 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: IamPaul (heartlesshind) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 From noreply at sourceforge.net Sat Sep 24 21:06:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 12:06:35 -0700 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 11:57 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Please note that this message will contain a full 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: Robert Kiendl (kxroberto) >Assigned to: Brett Cannon (bcannon) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2005-09-24 21:06 Message: Logged In: YES user_id=972995 I retried that again with py2.4.1. The problem/bug is still there. In attachment I supplied a full FTPS client test_ftpslib.py with simple test function - ready to run into the problem: At the end of ftp.retrlines 'return self.voidresp()' freezes : waiting eternally for response bytes at the command port. the same at the end of .storelines after the data is transfered on the data port. My preliminary guess is still, that python's ssl has a severe (EOF?) problem closing a socket/connection correctly. obviously this problem doesn't show up with https because everything is done on one connection - no dependency on a correct socket/connect close signal. (from other https communication with some proxies in between my users get ssl-eof-error errors also. I still can't solve that bug too. this shows python's ssl has a severe EOF bug with complex https also - or cannot handle certain situations correct.) I learned the FTPS/TLS client from M2crypto's ftpslib. the only difference in (transposed) logic, that I can see is, that M2crpyto uses an additional line "conn.set_session(self.sock.get_session())" during setup of the data port ssl connection. I don't know what it is, pythons ssl doesn't have sucht "session"-functions, but I think it has no severe meaning.? Robert ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 06:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-17 01:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-11 00:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Sat Sep 24 21:30:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 12:30:29 -0700 Subject: [ python-Feature Requests-1303434 ] Please include pdb with windows distribution Message-ID: Feature Requests item #1303434, was opened at 2005-09-24 19:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this 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: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 From noreply at sourceforge.net Sat Sep 24 21:45:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 12:45:46 -0700 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 11:57 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Please note that this message will contain a full 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: Robert Kiendl (kxroberto) Assigned to: Brett Cannon (bcannon) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2005-09-24 21:45 Message: Logged In: YES user_id=972995 Now I managed to solve the problem for me with attached patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the (faked) ssl'ed socket solves it. I still guess the ssl'ed socket (ssl dll) should do that auto on sock.close() Thus I leave it as a bug HERE. Right? [ I also have the hope, that this also solves the ssl-eof-errors with https (of some of my users; will see this in future) *** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005 --- httplib.py Sat Sep 24 21:37:48 2005 *************** class SharedSocket: *** 899,904 **** --- 899,905 ---- self._refcnt -= 1 assert self._refcnt >= 0 if self._refcnt == 0: + self.sock.shutdown(2) self.sock.close() def __del__(self): ---------------------------------------------------------------------- Comment By: Robert Kiendl (kxroberto) Date: 2005-09-24 21:06 Message: Logged In: YES user_id=972995 I retried that again with py2.4.1. The problem/bug is still there. In attachment I supplied a full FTPS client test_ftpslib.py with simple test function - ready to run into the problem: At the end of ftp.retrlines 'return self.voidresp()' freezes : waiting eternally for response bytes at the command port. the same at the end of .storelines after the data is transfered on the data port. My preliminary guess is still, that python's ssl has a severe (EOF?) problem closing a socket/connection correctly. obviously this problem doesn't show up with https because everything is done on one connection - no dependency on a correct socket/connect close signal. (from other https communication with some proxies in between my users get ssl-eof-error errors also. I still can't solve that bug too. this shows python's ssl has a severe EOF bug with complex https also - or cannot handle certain situations correct.) I learned the FTPS/TLS client from M2crypto's ftpslib. the only difference in (transposed) logic, that I can see is, that M2crpyto uses an additional line "conn.set_session(self.sock.get_session())" during setup of the data port ssl connection. I don't know what it is, pythons ssl doesn't have sucht "session"-functions, but I think it has no severe meaning.? Robert ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 06:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-17 01:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-11 00:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Sun Sep 25 01:40:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 16:40:40 -0700 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 23: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=1303614&group_id=5470 Please note that this message 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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Sun Sep 25 03:46:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 18:46:11 -0700 Subject: [ python-Bugs-1303673 ] traceback on trying to load a file Message-ID: Bugs item #1303673, was opened at 2005-09-24 21: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=1303673&group_id=5470 Please note that this message will contain a full 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: nanotube (nanotube) Assigned to: Nobody/Anonymous (nobody) Summary: traceback on trying to load a file Initial Comment: When trying to load a file generated by hotshotmain.py (attached), generates the following traceback: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> hotshot.stats.load("pyk.prof") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\hotshot\stats.py", line 12, in load return StatsLoader(filename).load() File "C:\Python24\lib\hotshot\stats.py", line 51, in load assert not self._stack AssertionError This happened with both python 2.4.1 and with python 2.4.2 rc 1 on windows (just downloaded). Seems similar to bug [ 900092 ] hotshot.stats.load (link: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 ) but according to that, bug has been closed, and patch has been applied to python 2.4.2. not sure if that applies also to 2.4.2 rc1 Attaching the output file that caused it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470 From noreply at sourceforge.net Sun Sep 25 04:10:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 19:10:38 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 09:31 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this 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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2005-09-24 19:10 Message: Logged In: YES user_id=8861 OK, I've found out what goes wrong. (Debugging a 20,000+-line 'configure' script that omits all useful information from its output and throws away all its intermediate files *even if it detects errors* is not fun.) With the set of configuration options that the script decides is appropriate (too long to include here), compilation of a dummy .c file that #includes fails thusly: In file included from /usr/include/curses.h:14, from t.h:54, from t.c:1: /usr/include/ncurses.h:251: error: conflicting types for `wchar_t' /usr/include/stdlib.h:51: error: previous declaration of `wchar_t' This apparently happens because of line 1483 of the configure script, which reads: OpenBSD/2.* | OpenBSD/3.[0123456]) I can't fathom why OpenBSD 3.7 and later are excluded here, especially since (1) there are other places in the script that include all OpenBSD/3.* versions, and (2) the situation described by the comment just above this line is still true in OpenBSD 3.7. In any case, changing this line to read OpenBSD/2.* | OpenBSD/3.*) causes configure (and a subsequent make) to complete with no errors. So apparently other things are broken in the OpenBSD headerfiles if _XOPEN_SOURCE is defined, not just select(2). I hope someone authorized to do so will make this fix for Python 2.4.. TIA. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 01:10 Message: Logged In: YES user_id=55188 For curses.h problem, it doesn't harm the build much in fact. It's already reported to FreeBSD bugdb http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think it's identical problem on OpenBSD. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 11:40 Message: Logged In: YES user_id=21627 Can somebody attach a config.log, or reproduce the fragment that deals with the curses.h presence? Does your system require any headers to be included for curses.h to be usable? I.e. if you do #include int main(){} will that program compile, or do you need additional ('prerequisite') headers? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-08 23:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 05:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:23:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:23:48 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this 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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:23 Message: Logged In: YES user_id=21627 The issue reported here results from a bug in OpenBSD: ncurses.h and stdlib.h have conflicting definitions of wchar_t. This means the system is simply broken, and should be fixed (or abandoned) eventually. Python has a work-around for the bug, for those versions in which the bug has been confirmed. So far, the bug had not been confirmed for 3.7. Now it is, so we should add 3.7 to the list of systems that still show the bug. Changing it to 3.* would be incorrect - we cannot know whether the bug will be present in 3.8, as that system has not been released yet. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2005-09-25 04:10 Message: Logged In: YES user_id=8861 OK, I've found out what goes wrong. (Debugging a 20,000+-line 'configure' script that omits all useful information from its output and throws away all its intermediate files *even if it detects errors* is not fun.) With the set of configuration options that the script decides is appropriate (too long to include here), compilation of a dummy .c file that #includes fails thusly: In file included from /usr/include/curses.h:14, from t.h:54, from t.c:1: /usr/include/ncurses.h:251: error: conflicting types for `wchar_t' /usr/include/stdlib.h:51: error: previous declaration of `wchar_t' This apparently happens because of line 1483 of the configure script, which reads: OpenBSD/2.* | OpenBSD/3.[0123456]) I can't fathom why OpenBSD 3.7 and later are excluded here, especially since (1) there are other places in the script that include all OpenBSD/3.* versions, and (2) the situation described by the comment just above this line is still true in OpenBSD 3.7. In any case, changing this line to read OpenBSD/2.* | OpenBSD/3.*) causes configure (and a subsequent make) to complete with no errors. So apparently other things are broken in the OpenBSD headerfiles if _XOPEN_SOURCE is defined, not just select(2). I hope someone authorized to do so will make this fix for Python 2.4.. TIA. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 10:10 Message: Logged In: YES user_id=55188 For curses.h problem, it doesn't harm the build much in fact. It's already reported to FreeBSD bugdb http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think it's identical problem on OpenBSD. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 20:40 Message: Logged In: YES user_id=21627 Can somebody attach a config.log, or reproduce the fragment that deals with the curses.h presence? Does your system require any headers to be included for curses.h to be usable? I.e. if you do #include int main(){} will that program compile, or do you need additional ('prerequisite') headers? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 08:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:32:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:32:30 -0700 Subject: [ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket Message-ID: Bugs item #1302793, was opened at 2005-09-24 07:53 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 9 Submitted By: IamPaul (heartlesshind) >Assigned to: Martin v. L?wis (loewis) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:35:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:35:44 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Sun Sep 25 06:38:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 21:38:12 -0700 Subject: [ python-Bugs-1292634 ] The _ssl build process for 2.3.5 is broken Message-ID: Bugs item #1292634, was opened at 2005-09-16 09:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Cheung (robertcheung) Assigned to: Nobody/Anonymous (nobody) Summary: The _ssl build process for 2.3.5 is broken Initial Comment: I have attempted to build the _ssl library for 2.3.5 and it is broken (see attached output 1). Basically it is complaining that the _ssl.pyd file could not be build because several symbols (GetUserObjectInformation, etc) could not be linked. Those symbols are suppose to be located in User32.[lib|dll]. Appending User32.lib to line 15 of _ssl.mak fixed this problem (see attachment 2). Hopefully this will be helpful for other people that also had build problems with the ssl library. Regards Robert Cheung -------- Attached output 1-------------- C:\downloads\python\Python-2.3.5\PCbuild>python build_ssl.py Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at 'C:\downloads\python\openssl-0.9.8' Executing nmake over the ssl makefiles... Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. cl /nologo ../Modules/_ssl.c C:\downloads\python\openssl-0.9.8/out32/libeay32.lib C:\downloads\python\openssl-0.9.8/out32/ssleay32.lib /Ox /MD /LD /Fox86-temp-release/_ssl\_ssl.obj -I ../Include -I ../PC -I C:\downloads\python\openssl-0.9.8/inc32 /link /out:_ssl.pyd gdi32.lib wsock32.lib /libpath:C:\downloads\p ython\openssl-0.9.8/out32 libeay32.lib ssleay32.lib _ssl.c Creating library _ssl.lib and object _ssl.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetUserObjectInformationW at 20 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetProcessWindowStation at 0 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__GetDesktopWindow at 0 referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp__MessageBoxIndirectA at 4 referenced in function _OPENSSL_showfatal _ssl.pyd : fatal error LNK1120: 4 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. ------------ Attachment 2 ----------------- _ssl.mak line 15 - LIBS=gdi32.lib wsock32.lib /libpath:$(SSL_LIB_DIR) libeay32.lib ssleay32.lib User32.lib ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:38 Message: Logged In: YES user_id=21627 You are using an unsupported version of OpenSSL. Please try the version mentioned in PCbuild/readme.txt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 From noreply at sourceforge.net Sun Sep 25 08:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Sep 2005 23:41:02 -0700 Subject: [ python-Bugs-1303673 ] traceback on trying to load a hotshot stats file Message-ID: Bugs item #1303673, was opened at 2005-09-25 03:46 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470 Please note that this message will contain a full 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: nanotube (nanotube) Assigned to: Nobody/Anonymous (nobody) >Summary: traceback on trying to load a hotshot stats file Initial Comment: When trying to load a file generated by hotshotmain.py (attached), generates the following traceback: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> hotshot.stats.load("pyk.prof") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\hotshot\stats.py", line 12, in load return StatsLoader(filename).load() File "C:\Python24\lib\hotshot\stats.py", line 51, in load assert not self._stack AssertionError This happened with both python 2.4.1 and with python 2.4.2 rc 1 on windows (just downloaded). Seems similar to bug [ 900092 ] hotshot.stats.load (link: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 ) but according to that, bug has been closed, and patch has been applied to python 2.4.2. not sure if that applies also to 2.4.2 rc1 Attaching the output file that caused it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470 From noreply at sourceforge.net Sun Sep 25 10:55:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 01:55:15 -0700 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message 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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Sun Sep 25 12:57:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 03:57:55 -0700 Subject: [ python-Bugs-1295909 ] inspect.getsource() misses single line blocks. Message-ID: Bugs item #1295909, was opened at 2005-09-20 01:00 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 Please note that this message will contain a full 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: Ron Adam (ronadam) >Assigned to: Armin Rigo (arigo) >Summary: inspect.getsource() misses single line blocks. Initial Comment: While playing around with the inspect module I found that the Blockfinder doesn't recognize single line function definitions. Adding the following two lines to it fixes it, but I'm not sure if it causes problems anywhere else. C:\Python24\Lib>diff.py inspect.py inspect_.py *** inspect.py Tue Mar 15 13:22:02 2005 --- inspect_.py Mon Sep 19 14:26:26 2005 *************** *** 531,536 **** --- 531,538 ---- raise EndOfBlock, self.last elif type == tokenize.NAME and scol == 0: raise EndOfBlock, self.last + elif self.indent == 0: + raise EndOfBlock, self.last def getblock(lines): """Extract the block of code at the top of the given list of lines.""" Version info: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 def test(t): print '**',t,'**' print "Line:" def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass """This line should not be visible.""" print inspect.getsource(f) import inspect test("before") import inspect_ as inspect test("after") #-- output -- ** before ** Line: def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass Block: def f(): pass pass ** after ** Line: def f(): pass Block: def f(): pass pass ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-25 10:57 Message: Logged In: YES user_id=4771 While working on PyPy we stubled over a couple of bugs in getsource() as well, and thought about some fix. I will add your example and a few more to test_inspect.py and fix/clean up a bit getblock() in inspect.py. I will also try to stress-test getsource() on some example programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 From noreply at sourceforge.net Sun Sep 25 13:27:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 04:27:32 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Comment added) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 11:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 04:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Sun Sep 25 13:51:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 04:51:51 -0700 Subject: [ python-Bugs-1295909 ] inspect.getsource() misses single line blocks. Message-ID: Bugs item #1295909, was opened at 2005-09-20 01:00 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 Please note that this message will contain a full 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: Ron Adam (ronadam) Assigned to: Armin Rigo (arigo) Summary: inspect.getsource() misses single line blocks. Initial Comment: While playing around with the inspect module I found that the Blockfinder doesn't recognize single line function definitions. Adding the following two lines to it fixes it, but I'm not sure if it causes problems anywhere else. C:\Python24\Lib>diff.py inspect.py inspect_.py *** inspect.py Tue Mar 15 13:22:02 2005 --- inspect_.py Mon Sep 19 14:26:26 2005 *************** *** 531,536 **** --- 531,538 ---- raise EndOfBlock, self.last elif type == tokenize.NAME and scol == 0: raise EndOfBlock, self.last + elif self.indent == 0: + raise EndOfBlock, self.last def getblock(lines): """Extract the block of code at the top of the given list of lines.""" Version info: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 def test(t): print '**',t,'**' print "Line:" def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass """This line should not be visible.""" print inspect.getsource(f) import inspect test("before") import inspect_ as inspect test("after") #-- output -- ** before ** Line: def f(): pass """ This line shouldn't be visible """ print inspect.getsource(f) print "Block:" def f(): pass pass Block: def f(): pass pass ** after ** Line: def f(): pass Block: def f(): pass pass ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-09-25 11:51 Message: Logged In: YES user_id=4771 Checked in: Lib/inspect.py 1.63 Lib/test/inspect_fodder2.py 1.5 Lib/test/test_inspect.py 1.21 Not backported to 2.4 for now (the branch is frozen for 2.4.2 release and it's unclear if this is critical enough). Thanks! The patch I applied is essentially what you proposed, with the exception of special tokens (NL and COMMENT) that should not end a block even at indentation level zero. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 10:57 Message: Logged In: YES user_id=4771 While working on PyPy we stubled over a couple of bugs in getsource() as well, and thought about some fix. I will add your example and a few more to test_inspect.py and fix/clean up a bit getblock() in inspect.py. I will also try to stress-test getsource() on some example programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470 From noreply at sourceforge.net Sun Sep 25 15:06:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 06:06:19 -0700 Subject: [ python-Bugs-1303928 ] Extended slice bug (or feature?) Message-ID: Bugs item #1303928, was opened at 2005-09-25 13: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=1303928&group_id=5470 Please note that this message 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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5] # b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1] # d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 From noreply at sourceforge.net Sun Sep 25 15:16:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 06:16:20 -0700 Subject: [ python-Bugs-1303928 ] Extended slice bug (or feature?) Message-ID: Bugs item #1303928, was opened at 2005-09-25 15:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 Please note that this message 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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5] # b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1] # d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 From noreply at sourceforge.net Sun Sep 25 15:17:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 06:17:52 -0700 Subject: [ python-Bugs-1303928 ] Extended slice bug (or feature?) Message-ID: Bugs item #1303928, was opened at 2005-09-25 14:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 Please note that this message 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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5] # b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1] # d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-25 14:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 14:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 From noreply at sourceforge.net Sun Sep 25 15:25:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 06:25:24 -0700 Subject: [ python-Bugs-1303928 ] Extended slice bug (or feature?) Message-ID: Bugs item #1303928, was opened at 2005-09-25 15:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 Please note that this message 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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5] # b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1] # d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:25 Message: Logged In: YES user_id=1188172 Closing again ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-25 15:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 From noreply at sourceforge.net Sun Sep 25 17:50:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 08:50:00 -0700 Subject: [ python-Bugs-1303928 ] Extended slice bug (or feature?) Message-ID: Bugs item #1303928, was opened at 2005-09-25 13:06 Message generated for change (Comment added) made by beazley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 Please note that this message 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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5] # b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1] # d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave ---------------------------------------------------------------------- >Comment By: David M. Beazley (beazley) Date: 2005-09-25 15:50 Message: Logged In: YES user_id=7557 Thanks for the clarification----just making sure I get this absolutely right before committing anything to paper here. -- Dave. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 13:25 Message: Logged In: YES user_id=1188172 Closing again ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-25 13:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 13:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 From noreply at sourceforge.net Sun Sep 25 21:49:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 12:49:33 -0700 Subject: [ python-Bugs-1304179 ] 2.3.5 configure / make infinite loop Message-ID: Bugs item #1304179, was opened at 2005-09-25 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=1304179&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schwartz (nynymike) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 configure / make infinite loop Initial Comment: I am trying to install python 2.3.5 from source on FC4 to /usr/local. # ./configure --prefix=/usr/local works ok. But when I do # make I get caught in an infinite loop where it just runs the configure script over and over. Thanks! - Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&group_id=5470 From noreply at sourceforge.net Sun Sep 25 22:20:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 13:20:20 -0700 Subject: [ python-Feature Requests-467924 ] Improve the ZipFile Interface Message-ID: Feature Requests item #467924, was opened at 2001-10-04 15:54 Message generated for change (Comment added) made by scott_daniels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 Please note that this message will contain 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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2005-09-25 20:20 Message: Logged In: YES user_id=493818 I am currently working on an expanded zipfile module that: (a) Has a more easily extensible class (b) Allows BZIP2 compression (my orginal need) (c) Allows file-like (read) access to the elements of ZipFile (d) Provides for a single "writer" which can be used to generate file contents "incrementally" while possibly reading from other "files" in the zipfile (e) Allows the opening of embedded zips "in-place" What I don't have at the moment is a good set of tests or good documents of how to use it. Anyone interested in collaborating, let me know. --Scott David Daniels ---------------------------------------------------------------------- Comment By: Chuck Rhode (crhode) Date: 2005-09-22 15:56 Message: Logged In: YES user_id=988879 I've been trying to read map files put out by the Census Bureau. These ZIP archives are downloaded from government contractors' sites by county. Within each county archive are several ZIP files for each map layer (roads, streams, waterbodies, etc). Each contains the elements of an ESRI shapefile database (.shp, .shx., and .dbf files). This doesn't make a lot of sense to me, either, because there's no compression advantage to making an archive of an archive. The technique is used purely for organizational purposes because ZIP does not compress subdirectories. Note: I've never seen a TAR of TAR files because TAR *does* compress subdirectories. What I've been struggling with is a way to leave these archives in their compressed form and still do *python* I/O on them. There is a tree organization to them, after all, just as with traditional os.path directories. I've designed some objects that let me retrieve the most recent file, ZIP member, or TAR member by name from a given path to a repository of such archives. What I get is a StreamIO object that I can subsequently put back where it came from. What would be nice is if there already were objects available to manipulate normal os.path directories comingled with ZIP and TAR archives. What would be nicer is if I/O could be opened at the character/line level transparently without regard to whether the source/destination was a file or an archive member within such a structure. In the days of hardware compression and on-the-fly encryption/decryption of I/O, is this too much to ask? -ccr- ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-05-09 18:23 Message: Logged In: YES user_id=335935 The zipfile interface should match the tarfile interface. At the mininum is should work for this example: import zipfile zip = zipfile.open("sample.zip", "r") for zipinfo in zip: print tarinfo.name, "is", tarinfo.size, "bytes in size and is", zip.extract(zipinfo) zip.close() This closely matchs the 'tarfile' module. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2003-07-31 14:22 Message: Logged In: YES user_id=196786 It would also be very useful to be able to have ZipFile read/write the uncompressed file data from/to a file-like object, instead of just strings and files (respectively). I would like to use this module to work with zip files containing large files, but this is unworkable because the current implementation would use excessive amounts of memory. Currently, read() reads all of the compressed data into memory, then uncompresses it into memory. For files which may be hundreds of megabytes compressed, this is undesirable. Likewise for write(), I would like to be able to stream data into a zip file, passing in a ZipInfo to specify the metadata as is done with writestr(). The implementation of this functionality is quite straightforward, but I am not sure whether (or how) the interface should change. Some other parts of the library allow for a file object to be passed to the same interface which accepts a filename. The object is examined to see if it has the necessary read/write methods and if not, it is assumed to be a filename. Would this be the correct way to do it? I, too, am a bit irked by the lack of symmetry exhibited by read vs. write/writestr, and think that the interface suggested above would be a significant improvement. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 20:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 From noreply at sourceforge.net Sun Sep 25 22:29:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 13:29:40 -0700 Subject: [ python-Bugs-1304179 ] 2.3.5 configure / make infinite loop Message-ID: Bugs item #1304179, was opened at 2005-09-25 21:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schwartz (nynymike) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 configure / make infinite loop Initial Comment: I am trying to install python 2.3.5 from source on FC4 to /usr/local. # ./configure --prefix=/usr/local works ok. But when I do # make I get caught in an infinite loop where it just runs the configure script over and over. Thanks! - Mike ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 22:29 Message: Logged In: YES user_id=1188172 Not that I want to say that you don't have a problem, but if you are installing from source anyway, couldn't you try 2.4.1 (or the upcoming 2.4.2)? Moreover it's not likely that there will be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&group_id=5470 From noreply at sourceforge.net Mon Sep 26 01:29:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Sep 2005 16:29:00 -0700 Subject: [ python-Feature Requests-467924 ] Improve the ZipFile Interface Message-ID: Feature Requests item #467924, was opened at 2001-10-04 10:54 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 Please note that this message will contain 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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-09-25 18:29 Message: Logged In: YES user_id=1115903 Scott, I had put together some enhancements to ZipFile read/write, including test cases, but haven't had time to advocate getting it into 2.5. You can find it here: https://sourceforge.net/tracker/?func=detail&aid=1121142&group_id=5470&atid=305470 If it seems like it would be helpful, I can go round up the most recent version (that I've been using in a production environment) and send it to you. ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2005-09-25 15:20 Message: Logged In: YES user_id=493818 I am currently working on an expanded zipfile module that: (a) Has a more easily extensible class (b) Allows BZIP2 compression (my orginal need) (c) Allows file-like (read) access to the elements of ZipFile (d) Provides for a single "writer" which can be used to generate file contents "incrementally" while possibly reading from other "files" in the zipfile (e) Allows the opening of embedded zips "in-place" What I don't have at the moment is a good set of tests or good documents of how to use it. Anyone interested in collaborating, let me know. --Scott David Daniels ---------------------------------------------------------------------- Comment By: Chuck Rhode (crhode) Date: 2005-09-22 10:56 Message: Logged In: YES user_id=988879 I've been trying to read map files put out by the Census Bureau. These ZIP archives are downloaded from government contractors' sites by county. Within each county archive are several ZIP files for each map layer (roads, streams, waterbodies, etc). Each contains the elements of an ESRI shapefile database (.shp, .shx., and .dbf files). This doesn't make a lot of sense to me, either, because there's no compression advantage to making an archive of an archive. The technique is used purely for organizational purposes because ZIP does not compress subdirectories. Note: I've never seen a TAR of TAR files because TAR *does* compress subdirectories. What I've been struggling with is a way to leave these archives in their compressed form and still do *python* I/O on them. There is a tree organization to them, after all, just as with traditional os.path directories. I've designed some objects that let me retrieve the most recent file, ZIP member, or TAR member by name from a given path to a repository of such archives. What I get is a StreamIO object that I can subsequently put back where it came from. What would be nice is if there already were objects available to manipulate normal os.path directories comingled with ZIP and TAR archives. What would be nicer is if I/O could be opened at the character/line level transparently without regard to whether the source/destination was a file or an archive member within such a structure. In the days of hardware compression and on-the-fly encryption/decryption of I/O, is this too much to ask? -ccr- ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-05-09 13:23 Message: Logged In: YES user_id=335935 The zipfile interface should match the tarfile interface. At the mininum is should work for this example: import zipfile zip = zipfile.open("sample.zip", "r") for zipinfo in zip: print tarinfo.name, "is", tarinfo.size, "bytes in size and is", zip.extract(zipinfo) zip.close() This closely matchs the 'tarfile' module. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2003-07-31 09:22 Message: Logged In: YES user_id=196786 It would also be very useful to be able to have ZipFile read/write the uncompressed file data from/to a file-like object, instead of just strings and files (respectively). I would like to use this module to work with zip files containing large files, but this is unworkable because the current implementation would use excessive amounts of memory. Currently, read() reads all of the compressed data into memory, then uncompresses it into memory. For files which may be hundreds of megabytes compressed, this is undesirable. Likewise for write(), I would like to be able to stream data into a zip file, passing in a ZipInfo to specify the metadata as is done with writestr(). The implementation of this functionality is quite straightforward, but I am not sure whether (or how) the interface should change. Some other parts of the library allow for a file object to be passed to the same interface which accepts a filename. The object is examined to see if it has the necessary read/write methods and if not, it is assumed to be a filename. Would this be the correct way to do it? I, too, am a bit irked by the lack of symmetry exhibited by read vs. write/writestr, and think that the interface suggested above would be a significant improvement. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 15:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&group_id=5470 From noreply at sourceforge.net Mon Sep 26 16:51:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 07:51:15 -0700 Subject: [ python-Bugs-1126208 ] subprocess.py Errors with IDLE Message-ID: Bugs item #1126208, was opened at 2005-02-17 13:33 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470 Please note that this message will contain 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: Kurt B. Kaiser (kbk) Assigned to: Peter ?strand (astrand) Summary: subprocess.py Errors with IDLE Initial Comment: ===================== From: David S. alumni.tufts.edu> Subject: subprocess problem on Windows in IDLE and PythonWin Newsgroups: gmane.comp.python.general Date: Wed, 16 Feb 2005 02:05:24 +0000 Python 2.4 on Windows XP In the python command-line the following works fine: >>> from subprocess import * >>> p = Popen('dir', stdout=PIPE) >From within IDLE or PythonWin I get the following exception: Traceback (most recent call last): File "", line 1, in -toplevel- p = Popen('dir', stdout=PIPE) File "c:\python24\lib\subprocess.py", line 545, in __init__ (p2cread, p2cwrite, File "c:\python24\lib\subprocess.py", line 605, in _get_handles p2cread = self._make_inheritable(p2cread) File "c:\python24\lib\subprocess.py", line 646, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required Note it works fine on Linux also. I tested it with >>> p = Popen('ls', stdout=PIPE) ... and had no trouble. =========== I (KBK) can duplicate this on W2K using 2.4. If I run IDLE with the -n switch (no subprocess) the error doesn't occur. Unfortunately, I can't debug it because I don't have the necessary tools on Windows. It appears that the problem is in _subprocess.c:sp_DuplicateHandle(), likely that PyArg_ParseTuple() is OK but the failure occurs in the call to DuplicateHandle(). All the args to sp_DuplicateHandle() seem to be the right type. DUPLICATE_SAME_ACCESS is an integer, value 2 To find out what's going on, it would seem necessary to attach a windows debugger to IDLE's subprocess (not the IDLE GUI). Let me know if I can help. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-09-26 08:51 Message: Logged In: YES user_id=945502 I believe this is related to 1124861 (if it's not a duplicate of it) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470 From noreply at sourceforge.net Mon Sep 26 16:53:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 07:53:49 -0700 Subject: [ python-Bugs-1124861 ] GetStdHandle in interactive GUI Message-ID: Bugs item #1124861, was opened at 2005-02-17 09:23 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470 Please note that this 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: davids (davidschein) Assigned to: Nobody/Anonymous (nobody) Summary: GetStdHandle in interactive GUI Initial Comment: Using the suprocess module from with IDLE or PyWindows, it appears that calls GetStdHandle (STD__HANDLE) returns None, which causes an error. (All appears fine on Linux, the standard Python command-line, and ipython.) For example: >>> import subprocess >>> p = subprocess.Popen("dir", stdout=subprocess.PIPE) Traceback (most recent call last): File "", line 1, in -toplevel- p = subprocess.Popen("dir", stdout=subprocess.PIPE) File "C:\Python24\lib\subprocess.py", line 545, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 605, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 646, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required The error originates in the mswindows implementation of _get_handles. You need to set one of stdin, stdout, or strerr because the first line in the method is: if stdin == None and stdout == None and stderr == None: ...return (None, None, None, None, None, None) I added "if not handle: return GetCurrentProcess()" to _make_inheritable() as below and it worked. Of course, I really do not know what is going on, so I am letting go now... def _make_inheritable(self, handle): ..."""Return a duplicate of handle, which is inheritable""" ...if not handle: return GetCurrentProcess() ...return DuplicateHandle(GetCurrentProcess(), handle, ....................................GetCurrentProcess(), 0, 1, ....................................DUPLICATE_SAME_ACCESS) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-09-26 08:53 Message: Logged In: YES user_id=945502 This issue was discussed on comp.lang.python[1] and Roger Upole suggested: """ Basically, gui apps like VS don't have a console, so GetStdHandle returns 0. _subprocess.GetStdHandle returns None if the handle is 0, which gives the original error. Pywin32 just returns the 0, so the process gets one step further but still hits the above error. Subprocess.py should probably check the result of GetStdHandle for None (or 0) and throw a readable error that says something like "No standard handle available, you must specify one" """ [1]http://mail.python.org/pipermail/python-list/2005-September/300744.html ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-08-13 14:37 Message: Logged In: YES user_id=945502 I ran into a similar problem in Ellogon (www.ellogon.org) which interfaces with Python through tclpython (http://jfontain.free.fr/tclpython.htm). My current workaround is to always set all of stdin, stdout, and stderr to subprocess.PIPE. I never use the stderr pipe, but at least this keeps the broken GetStdHandle calls from happening. Looking at the code, I kinda think the fix should be:: if handle is None: return handle return DuplicateHandle(GetCurrentProcess(), ... where if handle is None, it stays None. But I'm also probably in over my head here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470 From noreply at sourceforge.net Mon Sep 26 18:43:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 09:43:23 -0700 Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple locales Message-ID: Bugs item #1158490, was opened at 2005-03-07 20:11 Message generated for change (Comment added) made by bernhard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470 Please note that this message will contain a full 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: mixedpuppy (mixedpuppy) Assigned to: M.-A. Lemburg (lemburg) Summary: locale fails if LANGUAGE has multiple locales Initial Comment: The locale module does not correctly handle the LANGUAGE environment variable if it contains multiple settings. Example: LANGUAGE="en_DK:en_GB:en_US:en" Note, en_DK does not exist in locale_alias In normalize, the colons are replaced with dots, which is incorrect. getdefaultlocal should seperate these first, then try each one until it finds one that works, or fails on all. GLIBC documentation: http://www.delorie.com/gnu/docs/glibc/libc_138.html "While for the LC_xxx variables the value should consist of exactly one specification of a locale the LANGUAGE variable's value can consist of a colon separated list of locale names." Testing this is simple, just set your LANGUAGE environment var to the above example, and use locale.getdefaultlocal() > export LANGUAGE="en_DK:en_GB:en_US:en" > python ActivePython 2.4 Build 244 (ActiveState Corp.) based on Python 2.4 (#1, Feb 9 2005, 19:33:15) [GCC 3.3.1 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 344, in getdefaultlocale return _parse_localename(localename) File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: en_DK:en_GB:en_US:en >>> ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-09-26 18:43 Message: Logged In: YES user_id=2369 Another consequence of this bug is that even if getdefaultlocale does not fail with an exception, it may return an invalid value for the encoding. E.g. one thuban user had LANGUAGE=pt_BR:pt_PT:pt getdefaultlocale did not raise an exception, but return "pt_pt" as the encoding because the normalized form of the above value was pt_BR.pt_pt and the locale module assumes that the part after the "." is the encoding. ---------------------------------------------------------------------- Comment By: mixedpuppy (mixedpuppy) Date: 2005-03-10 22:50 Message: Logged In: YES user_id=1234417 IMHO the proper behaviour is to split on the colon, then try each one from start to finish until there is a success, or all fail. For example, if you just try en_DK, you will get a failure since that is not in locale.locale_alias, but en_GB or en_US would succeed. ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-10 19:48 Message: Logged In: YES user_id=1235914 The docs for getdefaultlocale state that it follows the GNU gettext search path. OTOH gettext can return result from any of catalogs en_DK:en_GB:en_US:en, it depends on the content of the message. So maybe getdefaultlocale should just pick up the first value from LANGUAGE ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-03-10 16:43 Message: Logged In: YES user_id=38388 The URL you gave does state that LANGUAGE can take mulitple entries separated by colons. However, I fail to see how to choose the locale from the list of possibilities. Any ideas ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470 From noreply at sourceforge.net Mon Sep 26 20:23:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Sep 2005 11:23:15 -0700 Subject: [ python-Bugs-1158490 ] locale fails if LANGUAGE has multiple locales Message-ID: Bugs item #1158490, was opened at 2005-03-07 20:11 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470 Please note that this message will contain a full 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: 3 Submitted By: mixedpuppy (mixedpuppy) Assigned to: M.-A. Lemburg (lemburg) Summary: locale fails if LANGUAGE has multiple locales Initial Comment: The locale module does not correctly handle the LANGUAGE environment variable if it contains multiple settings. Example: LANGUAGE="en_DK:en_GB:en_US:en" Note, en_DK does not exist in locale_alias In normalize, the colons are replaced with dots, which is incorrect. getdefaultlocal should seperate these first, then try each one until it finds one that works, or fails on all. GLIBC documentation: http://www.delorie.com/gnu/docs/glibc/libc_138.html "While for the LC_xxx variables the value should consist of exactly one specification of a locale the LANGUAGE variable's value can consist of a colon separated list of locale names." Testing this is simple, just set your LANGUAGE environment var to the above example, and use locale.getdefaultlocal() > export LANGUAGE="en_DK:en_GB:en_US:en" > python ActivePython 2.4 Build 244 (ActiveState Corp.) based on Python 2.4 (#1, Feb 9 2005, 19:33:15) [GCC 3.3.1 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 344, in getdefaultlocale return _parse_localename(localename) File "/opt/ActivePython-2.4/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: en_DK:en_GB:en_US:en >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-26 20:23 Message: Logged In: YES user_id=38388 The current CVS version returns this value: >>> import locale >>> locale.getdefaultlocale() (None, None) Given all the problems with the LANGUAGE environment variable (which is a gettext() only thing) I'm inclined to remove support for it altogether. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-09-26 18:43 Message: Logged In: YES user_id=2369 Another consequence of this bug is that even if getdefaultlocale does not fail with an exception, it may return an invalid value for the encoding. E.g. one thuban user had LANGUAGE=pt_BR:pt_PT:pt getdefaultlocale did not raise an exception, but return "pt_pt" as the encoding because the normalized form of the above value was pt_BR.pt_pt and the locale module assumes that the part after the "." is the encoding. ---------------------------------------------------------------------- Comment By: mixedpuppy (mixedpuppy) Date: 2005-03-10 22:50 Message: Logged In: YES user_id=1234417 IMHO the proper behaviour is to split on the colon, then try each one from start to finish until there is a success, or all fail. For example, if you just try en_DK, you will get a failure since that is not in locale.locale_alias, but en_GB or en_US would succeed. ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-10 19:48 Message: Logged In: YES user_id=1235914 The docs for getdefaultlocale state that it follows the GNU gettext search path. OTOH gettext can return result from any of catalogs en_DK:en_GB:en_US:en, it depends on the content of the message. So maybe getdefaultlocale should just pick up the first value from LANGUAGE ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-03-10 16:43 Message: Logged In: YES user_id=38388 The URL you gave does state that LANGUAGE can take mulitple entries separated by colons. However, I fail to see how to choose the locale from the list of possibilities. Any ideas ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158490&group_id=5470 From noreply at sourceforge.net Tue Sep 27 12:43:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 03:43:18 -0700 Subject: [ python-Bugs-1305706 ] windows unicode write is messing up the EOL. Message-ID: Bugs item #1305706, was opened at 2005-09-27 13: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=1305706&group_id=5470 Please note that this 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: Istvan Visegradi (visike) Assigned to: Nobody/Anonymous (nobody) Summary: windows unicode write is messing up the EOL. Initial Comment: User has an Unicode UTF-16 input file and trys to read it line-by-line and write it back to a new file. With the read line the program does nothing. code example: ... ln=fi.readline() fo.write(ln) ... In linux this code works perfectly with the input UTF-16 type file. In windows Python put an extra \x0D into the EOL. EOL should look like: 0D 00 0A 00 In windows it will be: 0D 00 0D 0A 00 Please inform when correction is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 From noreply at sourceforge.net Tue Sep 27 16:05:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 07:05:29 -0700 Subject: [ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket Message-ID: Bugs item #1302793, was opened at 2005-09-24 07:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this 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: IamPaul (heartlesshind) Assigned to: Martin v. L?wis (loewis) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 16:05 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. What specific file did you download and install? What is the contents of the DLLs directory? Do you have, by any chance, PYTHONPATH or PYTHONHOME set? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 From noreply at sourceforge.net Tue Sep 27 16:09:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 07:09:10 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) >Assigned to: Martin v. L?wis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 16:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 13:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Tue Sep 27 18:56:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 09:56:47 -0700 Subject: [ python-Bugs-1306043 ] Syntax error in Python Library Reference, 6.1.4. Files ... Message-ID: Bugs item #1306043, was opened at 2005-09-27 18: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=1306043&group_id=5470 Please note that this 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: Alexander Schliep (schliep) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error in Python Library Reference, 6.1.4. Files ... Initial Comment: See http://docs.python.org/lib/os-file-dir.html Python Library Reference, first example in Section 6.1.4 Files and Directories has an obvious syntax error. import os from os.path import join, getsize for root, dirs, files in os.walk('python/Lib/email'): print root, "consumes", print sum(getsize(join(root, name)) for name in files), #error print "bytes in", len(files), "non-directory files" if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories Should be print sum([getsize(join(root, name)) for name in files]), ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&group_id=5470 From noreply at sourceforge.net Tue Sep 27 19:46:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 10:46:26 -0700 Subject: [ python-Bugs-1306043 ] Syntax error in Python Library Reference, 6.1.4. Files ... Message-ID: Bugs item #1306043, was opened at 2005-09-27 18:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexander Schliep (schliep) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error in Python Library Reference, 6.1.4. Files ... Initial Comment: See http://docs.python.org/lib/os-file-dir.html Python Library Reference, first example in Section 6.1.4 Files and Directories has an obvious syntax error. import os from os.path import join, getsize for root, dirs, files in os.walk('python/Lib/email'): print root, "consumes", print sum(getsize(join(root, name)) for name in files), #error print "bytes in", len(files), "non-directory files" if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories Should be print sum([getsize(join(root, name)) for name in files]), ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-27 19:46 Message: Logged In: YES user_id=1188172 No, sorry. The docs you are referring to are the docs for Python 2.4, and Python 2.4 introduces so-called "generator expressions", and this is one. See http://docs.python.org/whatsnew/node4.html for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&group_id=5470 From noreply at sourceforge.net Tue Sep 27 21:51:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 12:51:35 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Martin v. L?wis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 21:51 Message: Logged In: YES user_id=21627 In additon, can you please provide the settings under HKEY_CURRENT_USER\Software\Policies\Microsoft Windows\Installer and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft Windows\Installer on your machine? If possible, can you try setting EnableUserControl to (DWORD)1 under the HKLM key? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 16:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 13:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Tue Sep 27 21:57:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 12:57:10 -0700 Subject: [ python-Bugs-1305706 ] windows unicode write is messing up the EOL. Message-ID: Bugs item #1305706, was opened at 2005-09-27 12:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 Please note that this 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: Istvan Visegradi (visike) Assigned to: Nobody/Anonymous (nobody) Summary: windows unicode write is messing up the EOL. Initial Comment: User has an Unicode UTF-16 input file and trys to read it line-by-line and write it back to a new file. With the read line the program does nothing. code example: ... ln=fi.readline() fo.write(ln) ... In linux this code works perfectly with the input UTF-16 type file. In windows Python put an extra \x0D into the EOL. EOL should look like: 0D 00 0A 00 In windows it will be: 0D 00 0D 0A 00 Please inform when correction is available. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 21:57 Message: Logged In: YES user_id=21627 Can you provide a small test program that demonstrates the problem? I cannot reproduce it: >>> f=codecs.open("f.txt","w",encoding="utf-16") >>> f.write(u"Hallo\n") >>> f.write(u"Welt\r\n") >>> f.close() >>> open("f.txt").read() '\xff\xfeH\x00a\x00l\x00l\x00o\x00\n\x00W\x00e\x00l\x00t\x00\r\x00\n\x00' This looks right to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 From noreply at sourceforge.net Tue Sep 27 22:03:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 13:03:18 -0700 Subject: [ python-Feature Requests-1303434 ] Please include pdb with windows distribution Message-ID: Feature Requests item #1303434, was opened at 2005-09-24 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this 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: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 22:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 From noreply at sourceforge.net Tue Sep 27 22:20:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 13:20:03 -0700 Subject: [ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Message-ID: Bugs item #1306211, was opened at 2005-09-27 20:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 From noreply at sourceforge.net Tue Sep 27 22:30:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 13:30:05 -0700 Subject: [ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Message-ID: Bugs item #1306211, was opened at 2005-09-27 20:20 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-27 20:30 Message: Logged In: YES user_id=48806 The Solaris 9 version of this compile failure is shorter: make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 From noreply at sourceforge.net Tue Sep 27 22:41:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 13:41:41 -0700 Subject: [ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Message-ID: Bugs item #1306211, was opened at 2005-09-27 20:20 Message generated for change (Settings changed) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Submitted By: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-27 20:30 Message: Logged In: YES user_id=48806 The Solaris 9 version of this compile failure is shorter: make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 From noreply at sourceforge.net Tue Sep 27 23:04:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 14:04:33 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 21: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=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Tue Sep 27 23:11:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 14:11:01 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21: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=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Wed Sep 28 05:37:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 20:37:03 -0700 Subject: [ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wroing Message-ID: Bugs item #1306449, was opened at 2005-09-28 13: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=1306449&group_id=5470 Please note that this 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: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsStringAndSize() return value documented wroing Initial Comment: The C/C++ API document (latest version from docs.python.org) has: int PyString_AsStringAndSize( PyObject *obj, char **buffer, int *length) [snip] If string is not a string object at all, PyString_AsString() returns NULL and raises TypeError. But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4 source): { PyErr_Format(PyExc_TypeError, "expected string or Unicode object, " "%.200s found", obj->ob_type->tp_name); return -1; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470 From noreply at sourceforge.net Wed Sep 28 06:20:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 21:20:12 -0700 Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug Message-ID: Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by wigy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this 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: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. ---------------------------------------------------------------------- Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 From noreply at sourceforge.net Wed Sep 28 06:29:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 21:29:28 -0700 Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug Message-ID: Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by wigy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this 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: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. ---------------------------------------------------------------------- Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? ---------------------------------------------------------------------- Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 From noreply at sourceforge.net Wed Sep 28 06:49:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 21:49:37 -0700 Subject: [ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType Message-ID: Bugs item #1306484, was opened at 2005-09-28 06: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=1306484&group_id=5470 Please note that this 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: V?gv?lgyi Attila (wigy) Assigned to: Nobody/Anonymous (nobody) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 From noreply at sourceforge.net Wed Sep 28 07:48:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 22:48:52 -0700 Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug Message-ID: Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this 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: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-28 07:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? ---------------------------------------------------------------------- Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? ---------------------------------------------------------------------- Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 From noreply at sourceforge.net Wed Sep 28 08:05:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 23:05:34 -0700 Subject: [ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wrong Message-ID: Bugs item #1306449, was opened at 2005-09-28 13:37 Message generated for change (Comment added) made by gnbond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470 Please note that this 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: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) >Summary: PyString_AsStringAndSize() return value documented wrong Initial Comment: The C/C++ API document (latest version from docs.python.org) has: int PyString_AsStringAndSize( PyObject *obj, char **buffer, int *length) [snip] If string is not a string object at all, PyString_AsString() returns NULL and raises TypeError. But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4 source): { PyErr_Format(PyExc_TypeError, "expected string or Unicode object, " "%.200s found", obj->ob_type->tp_name); return -1; } ---------------------------------------------------------------------- >Comment By: Gregory Bond (gnbond) Date: 2005-09-28 16:05 Message: Logged In: YES user_id=293157 Fix the summary! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470 From noreply at sourceforge.net Wed Sep 28 08:54:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Sep 2005 23:54:08 -0700 Subject: [ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Message-ID: Bugs item #1276509, was opened at 2005-08-30 12:48 Message generated for change (Comment added) made by chrschaffer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this 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: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris ---------------------------------------------------------------------- >Comment By: csmuc (chrschaffer) Date: 2005-09-28 08:54 Message: Logged In: YES user_id=1337267 Hi all, I found a newsgroup posting which adviced to change a line in Include/pyport.h http://mail.python.org/pipermail/patches/2005-February/016881.html ---------------8<----------------------------------------------------- The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define Py_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h --------------->8----------------------------------------------------- I did as adviced and the compile worked. I am not sure, if this is a valid solution, but at least it?s a workaround. Thanks to Reinhold Birkenfeld for your hint! Regards, Chris ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 From noreply at sourceforge.net Wed Sep 28 12:59:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 03:59:42 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 12: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=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 13:50:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 04:50:36 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 11:59 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-28 12:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:24:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:24:49 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 12:59 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:41:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:41:56 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 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=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:41 Message: Logged In: YES user_id=1188172 The bytecode generation happens before any code is executed, so the generated bytecode for x |= y is always the same (except, perhaps, when constants are involved). ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:52:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:52:52 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 12:59 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:52 Message: Logged In: YES user_id=432579 Certainly, but I meant that we could emit bytecode to compare the result of INPLACE_OR and do a conditional writeback. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:41 Message: Logged In: YES user_id=1188172 The bytecode generation happens before any code is executed, so the generated bytecode for x |= y is always the same (except, perhaps, when constants are involved). ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:53:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:53:45 -0700 Subject: [ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wrong Message-ID: Bugs item #1306449, was opened at 2005-09-28 05:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470 Please note that this 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: Gregory Bond (gnbond) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PyString_AsStringAndSize() return value documented wrong Initial Comment: The C/C++ API document (latest version from docs.python.org) has: int PyString_AsStringAndSize( PyObject *obj, char **buffer, int *length) [snip] If string is not a string object at all, PyString_AsString() returns NULL and raises TypeError. But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4 source): { PyErr_Format(PyExc_TypeError, "expected string or Unicode object, " "%.200s found", obj->ob_type->tp_name); return -1; } ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:53 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/api/concrete.tex r1.67, 1.58.2.4. ---------------------------------------------------------------------- Comment By: Gregory Bond (gnbond) Date: 2005-09-28 08:05 Message: Logged In: YES user_id=293157 Fix the summary! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:54:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:54:42 -0700 Subject: [ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType Message-ID: Bugs item #1306484, was opened at 2005-09-28 06:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 Please note that this 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: V?gv?lgyi Attila (wigy) >Assigned to: Martin v. L?wis (loewis) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 From noreply at sourceforge.net Wed Sep 28 15:02:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 06:02:55 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Wed Sep 28 14:17:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 05:17:32 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 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=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 15:13:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 06:13:22 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 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=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:13 Message: Logged In: YES user_id=1188172 I don't know. This way, __setitem__ would not be called even if it exists. That may pose b/w compatibility problems. I'm asking python-dev. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:52 Message: Logged In: YES user_id=432579 Certainly, but I meant that we could emit bytecode to compare the result of INPLACE_OR and do a conditional writeback. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:41 Message: Logged In: YES user_id=1188172 The bytecode generation happens before any code is executed, so the generated bytecode for x |= y is always the same (except, perhaps, when constants are involved). ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 16:27:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 07:27:56 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 10:59 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2005-09-28 14:27 Message: Logged In: YES user_id=56214 This is not a bug. The language-defined behavior of augmented assignment is that: lvalue |= rvalue translates to: lvalue = lvalue.__ior__(rvalue) Since in this example the lvalue cannot be assigned to, it is your code that has the bug. Note that some objects' __ior__ method may not return the same object! Therefore, using a tuple to store the target of an in-place update would only work with objects whose __ior__ returns self. If you know that this will always be the case in your code, then simply do this: ts = t[0] ts |= set([7]) Again, note that this means that if t[0].__ior__ does not return self, then ts will not be the same object as t[0], leaving the tuple un-updated. In short, you can't use augmented assignments to tuple items in the general case. Note, by the way, that sets have other methods for in-place updating, and your code would probably be clearer using one of those, since no lvalue confusion arises. The whole purpose of augmented assignment is to deal with the possibility that an in-place update might or might not result in the same object. If an object offers a method that unequivocally mutates it, your code will be clearer using that. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:13 Message: Logged In: YES user_id=1188172 I don't know. This way, __setitem__ would not be called even if it exists. That may pose b/w compatibility problems. I'm asking python-dev. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 12:52 Message: Logged In: YES user_id=432579 Certainly, but I meant that we could emit bytecode to compare the result of INPLACE_OR and do a conditional writeback. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 12:41 Message: Logged In: YES user_id=1188172 The bytecode generation happens before any code is executed, so the generated bytecode for x |= y is always the same (except, perhaps, when constants are involved). ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 12:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 12:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 11:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 18:22:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 09:22:25 -0700 Subject: [ python-Bugs-1306777 ] Augmented assigment to mutable objects in tuples fail Message-ID: Bugs item #1306777, was opened at 2005-09-28 12:59 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 Please note that this message 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: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: Augmented assigment to mutable objects in tuples fail Initial Comment: >>> t=(set([2]),) >>> t[0] |= set([7]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment but the contained set is mutable, and in fact: >>> t[0].__ior__(set([7])) set([2, 7]) >>> t (set([2, 7]),) If I use a mutable container (a list) in the first case, it works: >>> u=[set([2])] >>> u[0] |= set([7]) >>> u [set([2, 7])] But note that the list has not been mutated - only the set, so there would be no need for a mutable container. This is highly counter-intuitive - augmented assigment should do in-place operations on mutable types (which it does) and should therefore pose no restriction on the mutability of the container (which fails). ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 18:22 Message: Logged In: YES user_id=432579 Then maybe the language definition is in error since its consequences are counter-intuitive and impractical. Would any reasonable code break if it was modified to what a na?ve user would expect? For instance, the conditional writeback suggested earlier. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2005-09-28 16:27 Message: Logged In: YES user_id=56214 This is not a bug. The language-defined behavior of augmented assignment is that: lvalue |= rvalue translates to: lvalue = lvalue.__ior__(rvalue) Since in this example the lvalue cannot be assigned to, it is your code that has the bug. Note that some objects' __ior__ method may not return the same object! Therefore, using a tuple to store the target of an in-place update would only work with objects whose __ior__ returns self. If you know that this will always be the case in your code, then simply do this: ts = t[0] ts |= set([7]) Again, note that this means that if t[0].__ior__ does not return self, then ts will not be the same object as t[0], leaving the tuple un-updated. In short, you can't use augmented assignments to tuple items in the general case. Note, by the way, that sets have other methods for in-place updating, and your code would probably be clearer using one of those, since no lvalue confusion arises. The whole purpose of augmented assignment is to deal with the possibility that an in-place update might or might not result in the same object. If an object offers a method that unequivocally mutates it, your code will be clearer using that. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:13 Message: Logged In: YES user_id=1188172 I don't know. This way, __setitem__ would not be called even if it exists. That may pose b/w compatibility problems. I'm asking python-dev. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:52 Message: Logged In: YES user_id=432579 Certainly, but I meant that we could emit bytecode to compare the result of INPLACE_OR and do a conditional writeback. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:41 Message: Logged In: YES user_id=1188172 The bytecode generation happens before any code is executed, so the generated bytecode for x |= y is always the same (except, perhaps, when constants are involved). ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-09-28 14:24 Message: Logged In: YES user_id=432579 Thank you for your analysis. I'm not intimitely familiar with the bytecodes, but one way would be to omit the writeback (STORE_SUBSCR) if the result of INPLACE_OR is identical to its input. This could probably be done without changing the bytecodes but might profit from some changes for speed and compactness. That is (pseudocode): _t1 = t[i] _t2 = inplace_or(_t1, a) if _t2 is not _t1: t[i] = _t2 Another variant would be to add indexed variants of the augmented assigment methods; that is, augmented variants of __setitem__, but that has other drawbacks. However, it might be useful in its own regard in some cases. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:17 Message: Logged In: YES user_id=1188172 Generally there are two possibilites for the __ixxx__ methods: 1) Modify self and return self 2) Create a new instance with desired attributes and return it (necessary for e.g. integers) The second case cannot be handled by immutable containers. Hmm, maybe PySequence_SetItem should check whether the assigned item is already there and then succeed. Attaching a minimal patch for PySequence_SetItem (not sure about PyObject_SetItem). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-28 13:50 Message: Logged In: YES user_id=6656 Yuck, I agree that that's pretty icky. But the disassembly makes things clear: >>> dis.dis(compile('t[0] |= a', '', 'single')) 1 0 LOAD_NAME 0 (t) 3 LOAD_CONST 0 (0) 6 DUP_TOPX 2 9 BINARY_SUBSCR 10 LOAD_NAME 1 (a) 13 INPLACE_OR 14 ROT_THREE 15 STORE_SUBSCR 16 LOAD_CONST 1 (None) 19 RETURN_VALUE In fact... >>> s = set([1]) >>> t = (s,) >>> t[0] |= set([2]) Traceback (most recent call last): File "", line 1, in ? TypeError: object does not support item assignment >>> s set([1, 2]) >>> Oof. Not sure what to do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306777&group_id=5470 From noreply at sourceforge.net Wed Sep 28 18:59:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 09:59:05 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by jfriesne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 16:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Wed Sep 28 20:08:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 11:08:38 -0700 Subject: [ python-Bugs-1307188 ] =, not == Message-ID: Bugs item #1307188, was opened at 2005-09-28 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307188&group_id=5470 Please note that this 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: Davide Andrea (davideandrea) Assigned to: Nobody/Anonymous (nobody) Summary: =, not == Initial Comment: In:http://python.org/doc/2.4.2/lib/node597.html Each time you say: # me == the sender's email address and each time you say: # you == the recipient's email address you mean '=', not '==' D'de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307188&group_id=5470 From noreply at sourceforge.net Wed Sep 28 21:11:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 12:11:01 -0700 Subject: [ python-Bugs-636648 ] os.path.normpath leading '//' Message-ID: Bugs item #636648, was opened at 2002-11-11 10:00 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 Please note that this message will contain a full 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.1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nicholas Jones (carpaski) Assigned to: Neal Norwitz (nnorwitz) Summary: os.path.normpath leading '//' Initial Comment: normpath does not remove leading double slashes. (Linux) Python 2.2.1 (#1, Oct 30 2002, 19:46:40) >>> import os.path >>> os.path.normpath("//usr/bin") '//usr/bin' >>> os.path.normpath("///usr/bin") '/usr/bin' >>> os.path.normpath("//./usr/bin") '//usr/bin' ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-09-28 14:11 Message: Logged In: YES user_id=555 Nonetheless, keeping an initial double slash renders this function useless for its expected purpose. If this cannot be fixed outright, could be add a flag (with doc) to provide the expected behavior (i.e., squish all multiple slash sequences)? This document (link below) says "Application developers should avoid generating pathnames that start with "//". Implementations are strongly encouraged to avoid using this special interpretation..." http://64.233.167.104/search?q=cache:DY5cJbmtg7QJ:www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap04.html+posix+path+double+initial+slash&hl=en ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 21:39 Message: Logged In: YES user_id=33168 This is the intent of the code. The comment says: # POSIX allows one or two initial slashes, but treats three or more # as single slash. Therefore, I'm closing this as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 From noreply at sourceforge.net Wed Sep 28 21:16:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 12:16:24 -0700 Subject: [ python-Bugs-1307188 ] =, not == Message-ID: Bugs item #1307188, was opened at 2005-09-28 20:08 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307188&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Davide Andrea (davideandrea) Assigned to: Nobody/Anonymous (nobody) Summary: =, not == Initial Comment: In:http://python.org/doc/2.4.2/lib/node597.html Each time you say: # me == the sender's email address and each time you say: # you == the recipient's email address you mean '=', not '==' D'de ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 21:16 Message: Logged In: YES user_id=1188172 It's okay as it is, it is short for "me should be equal to..." or "you is equal to...". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307188&group_id=5470 From noreply at sourceforge.net Wed Sep 28 23:20:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 14:20:33 -0700 Subject: [ python-Bugs-1307357 ] Datagram Socket Timeouts Message-ID: Bugs item #1307357, was opened at 2005-09-28 17: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=1307357&group_id=5470 Please note that this message will contain a full 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 Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 From noreply at sourceforge.net Thu Sep 29 07:11:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 22:11:25 -0700 Subject: [ python-Bugs-636648 ] os.path.normpath leading '//' Message-ID: Bugs item #636648, was opened at 2002-11-11 08:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 Please note that this message will contain a full 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.1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nicholas Jones (carpaski) Assigned to: Neal Norwitz (nnorwitz) Summary: os.path.normpath leading '//' Initial Comment: normpath does not remove leading double slashes. (Linux) Python 2.2.1 (#1, Oct 30 2002, 19:46:40) >>> import os.path >>> os.path.normpath("//usr/bin") '//usr/bin' >>> os.path.normpath("///usr/bin") '/usr/bin' >>> os.path.normpath("//./usr/bin") '//usr/bin' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-28 22:11 Message: Logged In: YES user_id=33168 I am not an expert in this area by any means. You are welcome to submit a patch to modify the current behaviour. I don't know if the patch is likely to be accepted. You can also bring this issue up on comp.lang.python (python-list at python.org). It's probably not appropriate for python-dev. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2005-09-28 12:11 Message: Logged In: YES user_id=555 Nonetheless, keeping an initial double slash renders this function useless for its expected purpose. If this cannot be fixed outright, could be add a flag (with doc) to provide the expected behavior (i.e., squish all multiple slash sequences)? This document (link below) says "Application developers should avoid generating pathnames that start with "//". Implementations are strongly encouraged to avoid using this special interpretation..." http://64.233.167.104/search?q=cache:DY5cJbmtg7QJ:www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap04.html+posix+path+double+initial+slash&hl=en ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 19:39 Message: Logged In: YES user_id=33168 This is the intent of the code. The comment says: # POSIX allows one or two initial slashes, but treats three or more # as single slash. Therefore, I'm closing this as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:20:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:20:07 -0700 Subject: [ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType Message-ID: Bugs item #1306484, was opened at 2005-09-28 06:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 Please note that this 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: V?gv?lgyi Attila (wigy) Assigned to: Martin v. L?wis (loewis) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:20 Message: Logged In: YES user_id=21627 Why couldn't co_filename just be the Unicode string? I think one would have to change: - code_repr, to convert the filename into a byte string (preferably using 'ascii', 'replace') - tb_printinternal (not sure what to do here) - code_new, to accept either strings or unicode strings - builtin_compile, which probably indeed needs to convert the string using the file system encoding, and then patch the resulting code object to point to the unicode object originally passed (unless we can accept more pythonrun functions). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:21:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:21:35 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 23:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:34:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:34:47 -0700 Subject: [ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType Message-ID: Bugs item #1306484, was opened at 2005-09-28 04:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 Please note that this 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: V?gv?lgyi Attila (wigy) Assigned to: Martin v. L?wis (loewis) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-09-29 06:34 Message: Logged In: YES user_id=849994 Sounds sound. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:20 Message: Logged In: YES user_id=21627 Why couldn't co_filename just be the Unicode string? I think one would have to change: - code_repr, to convert the filename into a byte string (preferably using 'ascii', 'replace') - tb_printinternal (not sure what to do here) - code_new, to accept either strings or unicode strings - builtin_compile, which probably indeed needs to convert the string using the file system encoding, and then patch the resulting code object to point to the unicode object originally passed (unless we can accept more pythonrun functions). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 12:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 From noreply at sourceforge.net Thu Sep 29 08:41:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2005 23:41:13 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 23:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Thu Sep 29 09:54:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 00:54:43 -0700 Subject: [ python-Bugs-1305706 ] windows unicode write is messing up the EOL. Message-ID: Bugs item #1305706, was opened at 2005-09-27 13:43 Message generated for change (Comment added) made by visike You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 Please note that this 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: Closed Resolution: None Priority: 5 Submitted By: Istvan Visegradi (visike) Assigned to: Nobody/Anonymous (nobody) Summary: windows unicode write is messing up the EOL. Initial Comment: User has an Unicode UTF-16 input file and trys to read it line-by-line and write it back to a new file. With the read line the program does nothing. code example: ... ln=fi.readline() fo.write(ln) ... In linux this code works perfectly with the input UTF-16 type file. In windows Python put an extra \x0D into the EOL. EOL should look like: 0D 00 0A 00 In windows it will be: 0D 00 0D 0A 00 Please inform when correction is available. ---------------------------------------------------------------------- >Comment By: Istvan Visegradi (visike) Date: 2005-09-29 10:54 Message: Logged In: YES user_id=1352468 I made the wrong file open without codecs. With codecs it is opening OK and works correctly. Sorry for my beginners problem but in the documentation regarding Unicode is not too clear for me. (I think the problem is probably with me). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 22:57 Message: Logged In: YES user_id=21627 Can you provide a small test program that demonstrates the problem? I cannot reproduce it: >>> f=codecs.open("f.txt","w",encoding="utf-16") >>> f.write(u"Hallo\n") >>> f.write(u"Welt\r\n") >>> f.close() >>> open("f.txt").read() '\xff\xfeH\x00a\x00l\x00l\x00o\x00\n\x00W\x00e\x00l\x00t\x00\r\x00\n\x00' This looks right to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 From noreply at sourceforge.net Thu Sep 29 10:29:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 01:29:06 -0700 Subject: [ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType Message-ID: Bugs item #1306484, was opened at 2005-09-28 06:49 Message generated for change (Comment added) made by wigy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 Please note that this 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: V?gv?lgyi Attila (wigy) Assigned to: Martin v. L?wis (loewis) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? ---------------------------------------------------------------------- >Comment By: V?gv?lgyi Attila (wigy) Date: 2005-09-29 10:29 Message: Logged In: YES user_id=156682 loewis, I confess I could not understand a word. But as I see, it would have some advantages to have a completely unicode internal filename representation on systems having multiple filesystems mounted with different encodings, or systems having simply utf-8 filesystems (no 'ascii', 'replace' for allowing two filenames differing only in accents). I agree with Joel Spolsky (http://www.joelonsoftware.com/articles/Unicode.html), and I think that if choosing unicode could be easier in a language, than most of l10n problems would be solved. I understand, that coding unicode in C is a pain. Imagine - theoretically - if a literal like "hello" would automatically mean a unicode object in python, and you had to write s"hello" to make a literal string object encoded in a way some enviromental settings (or maybe the PEP 0263 header of the specific source file?) determine, so you have control on what happens. Imagine the case when there is a latin1 and a utf-8 partition mounted, and the console is latin2! Life would be much, much easier for a non-American programmer if she had to be aware from the first moment, that she is in an international environment. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2005-09-29 08:34 Message: Logged In: YES user_id=849994 Sounds sound. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:20 Message: Logged In: YES user_id=21627 Why couldn't co_filename just be the Unicode string? I think one would have to change: - code_repr, to convert the filename into a byte string (preferably using 'ascii', 'replace') - tb_printinternal (not sure what to do here) - code_new, to accept either strings or unicode strings - builtin_compile, which probably indeed needs to convert the string using the file system encoding, and then patch the resulting code object to point to the unicode object originally passed (unless we can accept more pythonrun functions). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 From noreply at sourceforge.net Thu Sep 29 12:05:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 03:05:19 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 12:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this 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: Jacek Poplawski (jacek_poplawski) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Thu Sep 29 12:08:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 03:08:45 -0700 Subject: [ python-Bugs-1307806 ] PCbuild vcproj project files need a cleanup Message-ID: Bugs item #1307806, was opened at 2005-09-29 13:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470 Please note that this 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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PCbuild vcproj project files need a cleanup Initial Comment: The Visual Studio .NET vcproj files were probably generated by importing the older Visual C++ 6.0 dsp files and saving them back into the new format. The convertor is not perfect. The bigest problem it has it's the handling of the configuration macro defines. Instead of defining the used macros once for each configuration, it defines them for each individual file. This causes file bloat and could cause problems when new files are added to the project since we could get builds with mixed defines due to the $(NoInherit) flag which makes the compiler ignore global defines. For example, the current pythoncore.vcproj file has 100 KB. A cleaned up version is less than 25 KB. NOW: CLEANED-UP: There are a couple of files which require custom options: ..\Modules\getbuildinfo.c - PreprocessorDefinitions="BUILD=67" ..\PC\import_nt.c - AdditionalIncludeDirectories="..\Python" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470 From noreply at sourceforge.net Thu Sep 29 12:37:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 03:37:36 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Comment added) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Martin v. L?wis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 19:51 Message: Logged In: YES user_id=21627 In additon, can you please provide the settings under HKEY_CURRENT_USER\Software\Policies\Microsoft Windows\Installer and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft Windows\Installer on your machine? If possible, can you try setting EnableUserControl to (DWORD)1 under the HKLM key? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 14:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 11:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 04:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Thu Sep 29 12:40:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 03:40:09 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Comment added) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Martin v. L?wis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:40 Message: Logged In: YES user_id=597393 I have attached the install log ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 19:51 Message: Logged In: YES user_id=21627 In additon, can you please provide the settings under HKEY_CURRENT_USER\Software\Policies\Microsoft Windows\Installer and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft Windows\Installer on your machine? If possible, can you try setting EnableUserControl to (DWORD)1 under the HKLM key? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 14:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 11:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 04:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Thu Sep 29 15:14:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 06:14:43 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 15:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Goetz Isenmann (isenmann) Assigned to: Nobody/Anonymous (nobody) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Thu Sep 29 15:28:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 06:28:59 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Goetz Isenmann (isenmann) >Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Thu Sep 29 15:32:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 06:32:07 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 15:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 15:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Thu Sep 29 16:04:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 07:04:26 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:04 Message: Logged In: YES user_id=6656 Can you try the attached? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 14:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Thu Sep 29 16:05:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 07:05:52 -0700 Subject: [ python-Bugs-1308042 ] Datagram Socket Timeouts Message-ID: Bugs item #1308042, was opened at 2005-09-29 10: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=1308042&group_id=5470 Please note that this message will contain a full 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 Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 From noreply at sourceforge.net Thu Sep 29 17:33:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 08:33:22 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21:10 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 17:46:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 08:46:40 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21:10 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 15:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 18:06:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 09:06:04 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 23:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 17:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Thu Sep 29 18:08:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 09:08:41 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 23:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 17:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 17:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 18:35:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 09:35:35 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21:10 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ In any case, adding -xc99=%none disables the c99 extensions which conflict with the old POSIX standards. This probably has to do with language changes that occured in c99 that may be incompatible with the oldest POSIX APIs. (elimination of default type promotion to int perhaps?) I agree that it's annoying, but that's the way the new headers work, and many other packages have already updated their build flags to cope. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 16:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 18:14:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 09:14:00 -0700 Subject: [ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI Message-ID: Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Martin v. L?wis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:14 Message: Logged In: YES user_id=21627 Thanks. Unfortunately, this logfile appears to start too late. Can you please recreate it with msiexec /i python-2.4.x.msi /l*v python.log Are you being asked whether this is a per-user or per-machine install? If yes, what is your response? I'm still puzzled as to what is causing the problem here. ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 12:40 Message: Logged In: YES user_id=597393 I have attached the install log ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 12:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 21:51 Message: Logged In: YES user_id=21627 In additon, can you please provide the settings under HKEY_CURRENT_USER\Software\Policies\Microsoft Windows\Installer and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft Windows\Installer on your machine? If possible, can you try setting EnableUserControl to (DWORD)1 under the HKLM key? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 16:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? ---------------------------------------------------------------------- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 13:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 From noreply at sourceforge.net Thu Sep 29 18:41:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 09:41:07 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 21:04 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 16:41 Message: Logged In: YES user_id=48806 I understand your reluctance to add cruft to the README, but given that there's no "configure --64-bit --without-gcc" that works, I think that adding something to the docs would be helpful. There's already a history of documenting bugs/limitations of the Python build system in the README, so while I agree with your view that fixing the build system would be best, adding something to the README is a good short-term solution until the 64-bit build kinks are fixed up. I suggest adding something along the lines of what has already been done for AIX/HP-UX 64-bit builds, since those also require unusual steps. Keep it short like these?: AIX 5.3: To build a 64-bit version with IBM's compiler, I used the following: export PATH=/usr/bin:/usr/vacpp/bin ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64" make HP-UX: When using threading, you may have to add -D_REENTRANT to the OPT variable in the top-level Makefile; reported by Pat Knight, this seems to make a difference (at least for HP-UX 10.20) even though pyconfig.h defines it. This seems unnecessary when using HP/UX 11 and later - threading seems to work "out of the box". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 16:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Thu Sep 29 17:12:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 08:12:30 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 21:04 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 15:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Thu Sep 29 19:14:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 10:14:55 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 12:05 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this 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: Jacek Poplawski (jacek_poplawski) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Thu Sep 29 19:15:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 10:15:24 -0700 Subject: [ python-Bugs-1307357 ] Datagram Socket Timeouts Message-ID: Bugs item #1307357, was opened at 2005-09-28 17:20 Message generated for change (Comment added) made by tvrankar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 Please note that this message will contain a full 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 Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Tom Vrankar (tvrankar) Date: 2005-09-29 13:15 Message: Logged In: YES user_id=1353485 BTW: On Solaris 8 it works as expected, with a "timed out" exception after the requested time out for each recvfrom until the server appears. This may be a Windoze-specific socket-ism. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 From noreply at sourceforge.net Thu Sep 29 20:36:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 11:36:54 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 23:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 20:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 18:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ In any case, adding -xc99=%none disables the c99 extensions which conflict with the old POSIX standards. This probably has to do with language changes that occured in c99 that may be incompatible with the oldest POSIX APIs. (elimination of default type promotion to int perhaps?) I agree that it's annoying, but that's the way the new headers work, and many other packages have already updated their build flags to cope. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 17:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 17:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 08:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 20:57:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 11:57:29 -0700 Subject: [ python-Bugs-1308740 ] Py_BuildValue (C/API): "K" format Message-ID: Bugs item #1308740, was opened at 2005-09-29 18: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=1308740&group_id=5470 Please note that this 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: Yair Chuchem (bigorilla) Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue (C/API): "K" format Initial Comment: In section "5.5 Parsing arguments and building values" at the C/API documentation. At the description of Py_BuildValue's format strings, the "K" format char is not mentioned, though it is implemented. Here's a possible text to add: "K" (integer) [unsigned PY_LONG_LONG] Convert a C unsigned long long to a python int object. and maybe add a (New in version 2.3) I don't know if it's new from 2.3 or something. I know that for PyArg_ParseTuple it says that for "K" Before I found that "K" is implemented out I used the "N" format and PyLong_FromLongLong, which is far less elegant :) Thanks, Yair. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&group_id=5470 From noreply at sourceforge.net Thu Sep 29 21:14:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 12:14:42 -0700 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 17:16 Message generated for change (Comment added) made by jhein-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 19:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Thu Sep 29 21:28:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 12:28:54 -0700 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 17:16 Message generated for change (Comment added) made by jhein-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 19:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 19:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Thu Sep 29 21:32:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 12:32:50 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 12:05 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this 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: Jacek Poplawski (jacek_poplawski) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-09-29 21:32 Message: Logged In: YES user_id=344921 Does the testsuite test_subprocess.py work correctly on this platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Thu Sep 29 21:42:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 12:42:46 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21:10 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 19:42 Message: Logged In: YES user_id=48806 The distutils patch you provided definitely cures the build problems I encountered when using the -xc99=%none compiler flag, so that at least gives one way to build. Your patch plus these options built fine (skipped C++ thus far) setenv CC "cc -xc99=%none -xarch=native64" ./configure --without-cxx I'll attach the pyconfig.h etc for this combination and I can send you the same info without those flags if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ In any case, adding -xc99=%none disables the c99 extensions which conflict with the old POSIX standards. This probably has to do with language changes that occured in c99 that may be incompatible with the oldest POSIX APIs. (elimination of default type promotion to int perhaps?) I agree that it's annoying, but that's the way the new headers work, and many other packages have already updated their build flags to cope. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 16:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 21:54:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 12:54:13 -0700 Subject: [ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10 Message-ID: Bugs item #1306253, was opened at 2005-09-27 21:10 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' ---------------------------------------------------------------------- >Comment By: John Stone (jestone) Date: 2005-09-29 19:54 Message: Logged In: YES user_id=48806 Ok, those two preproc.txt and preproc2.txt.gz ought to help you see what's going on there. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 19:42 Message: Logged In: YES user_id=48806 The distutils patch you provided definitely cures the build problems I encountered when using the -xc99=%none compiler flag, so that at least gives one way to build. Your patch plus these options built fine (skipped C++ thus far) setenv CC "cc -xc99=%none -xarch=native64" ./configure --without-cxx I'll attach the pyconfig.h etc for this combination and I can send you the same info without those flags if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 18:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ In any case, adding -xc99=%none disables the c99 extensions which conflict with the old POSIX standards. This probably has to do with language changes that occured in c99 that may be incompatible with the oldest POSIX APIs. (elimination of default type promotion to int perhaps?) I agree that it's annoying, but that's the way the new headers work, and many other packages have already updated their build flags to cope. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 16:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 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 "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.build_extension(self, ext) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 06:21 Message: Logged In: YES user_id=21627 These look like bugs in the operating system. Please report them to Sun. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:03:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:03:40 -0700 Subject: [ python-Bugs-1308740 ] Py_BuildValue (C/API): "K" format Message-ID: Bugs item #1308740, was opened at 2005-09-29 20:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Yair Chuchem (bigorilla) Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue (C/API): "K" format Initial Comment: In section "5.5 Parsing arguments and building values" at the C/API documentation. At the description of Py_BuildValue's format strings, the "K" format char is not mentioned, though it is implemented. Here's a possible text to add: "K" (integer) [unsigned PY_LONG_LONG] Convert a C unsigned long long to a python int object. and maybe add a (New in version 2.3) I don't know if it's new from 2.3 or something. I know that for PyArg_ParseTuple it says that for "K" Before I found that "K" is implemented out I used the "N" format and PyLong_FromLongLong, which is far less elegant :) Thanks, Yair. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:03 Message: Logged In: YES user_id=1188172 Duplicate of #1281408. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:04:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:04:25 -0700 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this 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: Barry A. Warsaw (bwarsaw) >Assigned to: Martin v. L?wis (loewis) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:04 Message: Logged In: YES user_id=1188172 Well, pwd will be built-in then, if that's a problem. Assigning to loewis to look over it. ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:06:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:06:45 -0700 Subject: [ python-Bugs-1299051 ] "Howto RE" link is dead Message-ID: Bugs item #1299051, was opened at 2005-09-22 21:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Macs R We (macsrwe) Assigned to: Nobody/Anonymous (nobody) Summary: "Howto RE" link is dead Initial Comment: On page http://www.python.org/doc/2.3.5/lib/re-syntax.html The link to "Regular expressions HOWTO" documentation ends up at http://www.amk.ca/python/howto/, which is a dead host. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:06 Message: Logged In: YES user_id=1188172 The host works for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:16:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:16:31 -0700 Subject: [ python-Bugs-1296004 ] MemoryError in httplib Message-ID: Bugs item #1296004, was opened at 2005-09-20 07:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 Please note that this message will contain a full 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: Yue Zhang (yuezhang) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError in httplib Initial Comment: The problem from http://www.thescripts.com/forum/thread25490.html can be repeated here with python2.4.1 on WinXP. Test sample: sending about 5MB http data. It appears to be caused by line 545, httplib.py. chunk = self.fp.read(amt) It seems that reading too much from that sock causes leak. Thus trying to edit the line making it chunk = self.fp.read(min(amt,50000)) the problem will be solved. //Not sure whether it was sock error for using pure sock for http won't cause this problem. If you need an example of this bug, please contact me. Also, the method in httplib is using string concatenation, which might turn slow when the strings are large. An alternative is using a temp list to cache the string sections, and join the list at last. This will be faster, with the draw back of some more memory usage. Best regards, Zhang Yue ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:16 Message: Logged In: YES user_id=1188172 I added a "max amount" of 1 MB in httplib.py r1.96, 1.94.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:24:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:24:35 -0700 Subject: [ python-Bugs-1298120 ] shlex does not support unicode Message-ID: Bugs item #1298120, was opened at 2005-09-21 22:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&group_id=5470 Please note that this 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: shlex does not support unicode Initial Comment: Should make prominent notice that shlex does not support unicode. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:24 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libshlex.tex r1.19, r1.18.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:30:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:30:11 -0700 Subject: [ python-Bugs-985651 ] BaseHTTPServer to take host from cmdline? Message-ID: Bugs item #985651, was opened at 2004-07-06 01:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 2 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer to take host from cmdline? Initial Comment: BaseHTTPServer.py can be run from the command line, in which case it takes its port from the command line but it assumes the hostname is empty. My grasp of these things is poor, but my understanding is that empty hostname implies not externally visible. Shouldn't it be possible to supply the hostname on the command line too (even if the above belief is incorrect)? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:30 Message: Logged In: YES user_id=1188172 Calling BaseHTTPServer directly only calls a test() method, which means that this is not intended for serious use. For that you should create your own server instance. If you feel otherwise, you can reopen this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:36:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:36:41 -0700 Subject: [ python-Bugs-869197 ] setgroups rejects long integer arguments Message-ID: Bugs item #869197, was opened at 2004-01-02 10:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Martin v. L?wis (loewis) Summary: setgroups rejects long integer arguments Initial Comment: os.setgroups ought to accept long integer arguments, just as os.setgid does. I think this worked in an earlier version of Python - or maybe it was that string.atol used to return a non-long integer if the number was small enough, so I didn't encounter long integers at all. >>> import os >>> os.setgid(1L) >>> os.setgroups((1L,)) Traceback (most recent call last): File "", line 1, in ? TypeError: groups must be integers >>> import sys >>> print sys.version 2.3.3 (#1, Dec 30 2003, 22:52:56) [GCC 3.2.3] ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=1188172 Attaching patch against CVS head. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:37:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:37:54 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 18:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:48:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:48:03 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by jfriesne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 20:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 16:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Thu Sep 29 22:50:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 13:50:26 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) >Assigned to: Martin v. L?wis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 22:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 18:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:14:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:14:36 -0700 Subject: [ python-Bugs-883495 ] python crash in pyexpat's XmlInitUnknownEncodingNS Message-ID: Bugs item #883495, was opened at 2004-01-23 23:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470 Please note that this 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: Works For Me Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python crash in pyexpat's XmlInitUnknownEncodingNS Initial Comment: [forwarded from http://bugs.debian.org/229281] seen with 2.3.3, works with 2.2.3 and 2.1.3 (after fixing the 2.1 incompatibilities). The pyexpat code used is the one direct from the distribution, no external library. The attached testcase demonstrates a bug in, apparently, /usr/lib/python2.3/lib-dynload/pyexpat.so. Here's the bug in gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 28350)] 0x40566800 in XmlInitUnknownEncodingNS () from /usr/lib/python2.3/lib-dynload/pyexpat.so To try it youself, run "make" in the testcase directory. I apoligise for the size of this testcase; I would have whitteled it down to something simpler, but I am not a python programmer. I also apoligise if the bug is really in some library that python uses; I only went back as far as pyexpat.so. Some developers on IRC feel this may be exploitable. Talk with Scott James Remnant , who also has some idea of the encoding problems in the rss file that are causing the crash. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:14 Message: Logged In: YES user_id=33168 Martin, this seems to work in Python 2.3.4, 2.4.2 and CVS. Has it been fixed and can it be closed? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-20 12:44 Message: Logged In: YES user_id=21627 The parser crashes because it invokes GetBuffer inside Parser, when Python is providing the next chunk of input, which reallocs the buffer to a different location. However, eventPtr is not updated inside GetBuffer (and neither is positionPtr). As a result, the next access to eventPtr (in XML_GetCurrentLineNumber, invoked from set_error), will cause a segfault. It is not clear to me why these pointers are not adjusted when the buffer is reallocated. However, a consistent fix appears to be to update the eventPtr close to the place where positionPtr is initialized, which is done in the attached patch exp.diff, which fixes this test case. Fred, can you please review this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:19:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:19:08 -0700 Subject: [ python-Bugs-1122301 ] marshal may crash on truncated input Message-ID: Bugs item #1122301, was opened at 2005-02-14 03:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 Please note that this message will contain a full 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: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: marshal may crash on truncated input Initial Comment: marshal doesn't behave well on truncated or otherwise malformed input. here's a short demo script, from a recent comp.lang.python thread: ::: the problem is that the following may or may not reach the "done!" statement, somewhat depending on python version, memory allocator, and what data you pass to dumps. import marshal data = marshal.dumps((1, 2, 3, "hello", 4, 5, 6)) for i in range(len(data), -1, -1): try: print marshal.loads(data[:i]) except EOFError: print "EOFError" except ValueError: print "ValueError" print "done!" (try different data combinations, to see how far you get on your platform...) fixing this should be relatively easy, and should result in a safe unmarshaller (your application will still have to limit the amount of data fed into load/loads, of course). ::: (also note that marshal may raise either EOFError or ValueError exceptions, again somewhat depending on how the file is damaged. a little consistency wouldn't hurt, but I'm not sure if/how this can be fixed...) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:19 Message: Logged In: YES user_id=33168 This works in CVS, but still not in 2.4. I guess the patch didn't get backported. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-27 02:36 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 07:58 Message: Logged In: YES user_id=6656 I think the attached fixes this example, and another involving marshalled sets. I spent a while feeding random data to marshal a few days ago and found that the commonest problem was attempting to allocate really huge sequences. Also, the TYPE_STRINGREF is horribly fragile, but I'm hoping Martin's going to fix that (he has a bug filed against him, anyway). Can you test/check it in? My marshal.c has rather a lot of local changes. Also, a test suite entry would be nice... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:30:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:30:26 -0700 Subject: [ python-Bugs-1308042 ] Datagram Socket Timeouts Message-ID: Bugs item #1308042, was opened at 2005-09-29 07:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 Please note that this message will contain a full 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: Works For Me Priority: 5 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:30 Message: Logged In: YES user_id=33168 Can you program the client in C and see if it behaves the same? Sockets are mostly just wrappers around the OS calls. It's possible this is the expected behaviour on Windows and python is just exposing that to you. I ran this on Linux and got this (which is what I think you want): neal at janus clean $ ./python PyBug/client.py & [1] 31484 neal at janus clean $ timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out ./python PyBug/server.py timed out timed out timed out ('127.0.0.1', 40899) says CHECK ('127.0.0.1', 3000) says OK [10587 refs] [10585 refs] [1]+ Done ./python PyBug/client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:31:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:31:40 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 06:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:31 Message: Logged In: YES user_id=33168 Wasn't a fix for this checked in? Can this be closed? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 07:04 Message: Logged In: YES user_id=6656 Can you try the attached? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 06:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 06:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:33:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:33:02 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 03:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this 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: Jacek Poplawski (jacek_poplawski) >Assigned to: Jason Tishler (jlt63) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:33 Message: Logged In: YES user_id=33168 Jason, any comments? Is this cygwin specific or a general subprocess issue? ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-09-29 12:32 Message: Logged In: YES user_id=344921 Does the testsuite test_subprocess.py work correctly on this platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:34:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:34:49 -0700 Subject: [ python-Bugs-1180147 ] test_posix fails on cygwin Message-ID: Bugs item #1180147, was opened at 2005-04-10 04:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Henrik Wist (wist) >Assigned to: Jason Tishler (jlt63) Summary: test_posix fails on cygwin Initial Comment: $ python test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ERROR test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok ====================================================================== ERROR: testNoArgFunctions (__main__.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Ran 18 tests in 0.038s FAILED (errors=1) Traceback (most recent call last): File "test/test_posix.py", line 159, in ? test_main() File "test/test_posix.py", line 156, in test_main test_support.run_unittest(PosixTester) File "/usr/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument This is with cygwin 1.5.12-1 and python 2.3.4-2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:34 Message: Logged In: YES user_id=33168 Jason, any comments? ---------------------------------------------------------------------- Comment By: Henrik Wist (wist) Date: 2005-04-14 02:56 Message: Logged In: YES user_id=1256464 Strangely enough, this works when deleting /etc/group or creating it with either local groups (mkgroup -l) or domain groups (mkgroup -d). I guess it is more a cygwin problem, then. ---------------------------------------------------------------------- Comment By: Henrik Wist (wist) Date: 2005-04-10 04:12 Message: Logged In: YES user_id=1256464 And, I forgot, this is with WinXP SP2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:36:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:36:03 -0700 Subject: [ python-Bugs-1179412 ] can't import thru cygwin symlink Message-ID: Bugs item #1179412, was opened at 2005-04-08 12:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&group_id=5470 Please note that this 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: steveward (steveward) >Assigned to: Jason Tishler (jlt63) Summary: can't import thru cygwin symlink Initial Comment: This may be a cygwin-specific problem: given foo.py: > ln -s foo.py bar.py > python Python 2.4 (#1, Dec 4 2004, 20:10:33) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import foo This is file foo.py. >>> import bar Traceback (most recent call last): File "", line 1, in ? ImportError: No module named bar Despite the problem with imports, most os.path utilities (exists, isfile, islink, isdir) work on cygwin symlinks. An exception is reailpath: realpath("bar.py") returns a path to the symlink, not to the real file. Suspecting this as a key to the import problem, I tried several recent python/cygwin release versions (all installed via cygwin's setup.exe). FIndings: Cygwin Python realpath Import 1.5.xx: 2.yy: Works? Works? --------- -------------- ----------- ---------- 1.5.14 2.4 NO NO 1.5.13 2.3.4 YES NO 1.5.14 2.3.4 YES NO 1.5.12 2.4 NO YES Neither bug shows up under Linux. The two problems seem uncorrelated, although it may be that each is due to some assumpion about symlink semantics that isn't true of the Cygwin implementation. Apologies if these problems have been previously submitted in a form my quick scan didn't identify. A corresponding note has been submitted to the cygwin mailing list. - Steve ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=33168 Jason, comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:36:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:36:33 -0700 Subject: [ python-Bugs-1101756 ] popen4/cygwin ssh hangs Message-ID: Bugs item #1101756, was opened at 2005-01-13 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ph.E (ph_e) >Assigned to: Jason Tishler (jlt63) Summary: popen4/cygwin ssh hangs Initial Comment: The following python code hangs on executing cmd2 (works with cmd1). The commands works fine when executed on a shell. I have the same problem with Python 2.3.4 and 2.4 (Windows). I use the latest Cygwin binaries import os cmd1 = "bin\ssh" cmd2 = "bin\ssh -i id_dsa admin at myserver.com uptime" def docmd(cmd): print "Doing %s ..." % cmd (stdin, stdouterr) = os.popen4(cmd) for line in stdouterr.readlines(): print line stdin.close() stdouterr.close() print "Done." if __name__ == '__main__': docmd(cmd1) docmd(cmd2) Give me some advice for testing (popen, linux, ...). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=33168 Jason? ---------------------------------------------------------------------- Comment By: Ph.E (ph_e) Date: 2005-01-13 09:33 Message: Logged In: YES user_id=1196530 The same code in Linux Python 2.3.4 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:37:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:37:19 -0700 Subject: [ python-Bugs-902151 ] Thread start - strange error under Cygwin Message-ID: Bugs item #902151, was opened at 2004-02-22 07:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902151&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) >Assigned to: Jason Tishler (jlt63) Summary: Thread start - strange error under Cygwin Initial Comment: I wrote a short script that launches several threads (parallel download using urllib.urlretrieve in this case). Sometimes when I launch my script under Cygwin, I get strange error messages like: 2 [win] python 1912 Winmain: Cannot register window class Sometimes all of the threads run OK, otherwise after the "correct" ones finish the console stops responding. No problems with this script directly under Windows ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=33168 Jason? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902151&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:37:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:37:56 -0700 Subject: [ python-Bugs-864374 ] 2.3.3 tests on cygwin Message-ID: Bugs item #864374, was opened at 2003-12-22 03:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 Please note that this message will contain a full 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: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=33168 Jason? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-08-28 04:02 Message: Logged In: YES user_id=358087 Sorry, due to some bizzar DLL relocation problems with cygwin I can't run the rull test suite. However test_bz2 fails *before* the test suite gets stuck ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 06:28 Message: Logged In: YES user_id=1188172 Can you verify this with 2.4.1 or a CVS version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:43:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:43:28 -0700 Subject: [ python-Bugs-1308042 ] Datagram Socket Timeouts Message-ID: Bugs item #1308042, was opened at 2005-09-29 07:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 Please note that this message will contain a full 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: Works For Me Priority: 5 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:43 Message: Logged In: YES user_id=33168 This is a dupe of 1307357, but I'm closing that one since most of the comments are here. However, note this one comment from twv in the other report that says it also works on Solaris 8 and could well be Windoze specific. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:30 Message: Logged In: YES user_id=33168 Can you program the client in C and see if it behaves the same? Sockets are mostly just wrappers around the OS calls. It's possible this is the expected behaviour on Windows and python is just exposing that to you. I ran this on Linux and got this (which is what I think you want): neal at janus clean $ ./python PyBug/client.py & [1] 31484 neal at janus clean $ timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out ./python PyBug/server.py timed out timed out timed out ('127.0.0.1', 40899) says CHECK ('127.0.0.1', 3000) says OK [10587 refs] [10585 refs] [1]+ Done ./python PyBug/client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 From noreply at sourceforge.net Fri Sep 30 07:44:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 22:44:11 -0700 Subject: [ python-Bugs-1307357 ] Datagram Socket Timeouts Message-ID: Bugs item #1307357, was opened at 2005-09-28 14:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 Please note that this message will contain a full 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: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:44 Message: Logged In: YES user_id=33168 Dupe of 1308042 ---------------------------------------------------------------------- Comment By: Tom Vrankar (tvrankar) Date: 2005-09-29 10:15 Message: Logged In: YES user_id=1353485 BTW: On Solaris 8 it works as expected, with a "timed out" exception after the requested time out for each recvfrom until the server appears. This may be a Windoze-specific socket-ism. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:01:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:01:19 -0700 Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat Message-ID: Bugs item #1295808, was opened at 2005-09-19 14:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 Please note that this 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: Trent Mick (tmick) >Assigned to: Martin v. L?wis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:01:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:01:16 -0700 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 05:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:01 Message: Logged In: YES user_id=33168 The problem seems to be related (same?) as bug #1295808. Does the patch there fix these problems? ---------------------------------------------------------------------- Comment By: Steve Juranich (sjuranic) Date: 2005-07-19 09:22 Message: Logged In: YES user_id=1315245 FWIW, this same problem crops up when using Python & VTK together (which also ships with its own version of expat). bos's workaround will make things work, though. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-03-29 10:11 Message: Logged In: YES user_id=2369 I ran into this problem as well on a debian GNU/Linux system on x86 hardware. It occurs both with pygtk 2.4 and wxPython 2.5 both built against gtk 2.4. bos' patch at least solves the immediate problem of the segmentation fault. It may be a good idea to print a warning message if some of the error codes cannot be translated to strings, though. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-04 15:16 Message: Logged In: YES user_id=28380 With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 02:35 Message: Logged In: YES user_id=6656 It's a nasty one, I'll give you that. Fred, what do you think of bos's patch? It solves the immediate issue, but I'm not sure it's a complete fix. It seems to me that it would be better to resolve the expat symbols at builf time, but I don't know how to arrange for that. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 22:09 Message: Logged In: YES user_id=28380 By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-01-31 23:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 05:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 05:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 01:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 09:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 08:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 08:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:02:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:02:37 -0700 Subject: [ python-Bugs-1294032 ] Distutils writes keywords comma-separated Message-ID: Bugs item #1294032, was opened at 2005-09-17 12:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) >Assigned to: A.M. Kuchling (akuchling) Summary: Distutils writes keywords comma-separated Initial Comment: The distutils package writes out the Keywords metadata field in PKG-INFO comma-separated, while the Cheeseshop/PyPI follows the PEP 341 example and seems to expect space separated keywords. Either this needs clarifying in the PEP or docutils or PyPI should be altered to better integrate. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:02 Message: Logged In: YES user_id=33168 Andrew are you working on this stuff now? If not, is Richard? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294032&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:29:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:29:08 -0700 Subject: [ python-Bugs-1276768 ] dirutils.mkpath (verbose option does not work) Message-ID: Bugs item #1276768, was opened at 2005-08-30 08:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: gorilla_killa (gorilla_killa) Assigned to: Nobody/Anonymous (nobody) Summary: dirutils.mkpath (verbose option does not work) Initial Comment: The Verbose option does not work. Looked at the python script for dir_utils.py and the verbose parameter is not used in the code. Please fix this simple bug. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:29 Message: Logged In: YES user_id=33168 Can you provide a patch which behaves as you expect? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:30:33 -0700 Subject: [ python-Bugs-1261714 ] precompiled code and nameError. Message-ID: Bugs item #1261714, was opened at 2005-08-16 23:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470 Please note that this message 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: Vladimir Menshakov (megath) Assigned to: Nobody/Anonymous (nobody) Summary: precompiled code and nameError. Initial Comment: i experienced problem with call'ing python unmarshalled and eval'ed code. similar problem described in mailing list, but unfortunately has not got any solution or work-around. http://mail.python.org/pipermail/c++-sig/2003-October/006094.html actually I have code like this: ------------- import m class A: def do(self): print m.User().GetName() ------------ test.py a = A() a.do() running script from python works perfectly. but when I call 'do' from c++ code I get following error : PyObject_CallMethod: exceptions.NameError:global name 'm' is not defined I checked locals dictionary, it contains missing name ('m'). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:30 Message: Logged In: YES user_id=33168 Can you provide the c++ code? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:33:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:33:50 -0700 Subject: [ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on misconfigured system Message-ID: Bugs item #1250170, was opened at 2005-08-02 05:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 Please note that this message will contain 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: Tadeusz Andrzej Kadlubowski (tkadlubo) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyname(gethostname()) fails on misconfigured system Initial Comment: Hello, I downloaded python CVS tree, compiled it and ran tests. Two tests failed: urllib2 and mimetools. Both in the same fashion, when doing socket.gethostbyname(socket.gethostname()) (It is used in mimetools.py library in line 130 and in test_urllib2.py test unit in line 352.) In the interpreter it fails in the following way: >>> import socket >>> socket.gethostbyname(socket.gethostname()) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-2, 'Name or service not known') The reason is that my hostname is bogus, no single DNS knows about it, and I don't see any reason to set up a DNS server on my box. Of course editing /etc/hosts and adding my hostname as an alias for 127.0.0.1 solves the problem. Anyway I don't see any particular reason why the library shouldn't handle such situation i.e. when there's no connection between hostname and IP address. What do you think about it? I can make a SF patch item to solve this issue if you like. I am quite sure adding try/catch will make it in both cases. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:33 Message: Logged In: YES user_id=33168 Please provide a patch and attach it to this report. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:36:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:36:56 -0700 Subject: [ python-Bugs-1245381 ] log() on a big number fails on powerpc64 Message-ID: Bugs item #1245381, was opened at 2005-07-26 09:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470 Please note that this message 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: Jiri Dluhos (jdluhos) Assigned to: Nobody/Anonymous (nobody) Summary: log() on a big number fails on powerpc64 Initial Comment: The log() function seems to give incorrect results for large numbers on a 64-bit powerpc architecture. The test_math program from the Python test suite fails with the following message: math module, testing with eps 1e-05 constants acos asin atan atan2 ceil cos cosh degrees exp fabs floor fmod frexp hypot ldexp log Traceback (most recent call last): File "test_math.py", line 117, in ? testit('log(10**40, 10)', math.log(10**40, 10), 40) File "test_math.py", line 13, in testit raise TestFailed, '%s returned %f, expected %f'%test.test_support.TestFailed: log(10**40, 10) returned 21.938200, expected 40.000000 Tested on a SMP IBM PowerPC machine, with Python 2.3.4 (64-bit build). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:36 Message: Logged In: YES user_id=33168 Can you test with newer versions of Python, preferrably 2.4.2 or current CVS? 2.3.4 worked for me on 64-bit Opteron. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470 From noreply at sourceforge.net Fri Sep 30 08:39:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Sep 2005 23:39:18 -0700 Subject: [ python-Bugs-1234328 ] 'insufficient disk space' message wrong (msi on win xp pro) Message-ID: Bugs item #1234328, was opened at 2005-07-07 11:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&group_id=5470 Please note that this 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: Patrick Vrijlandt (pvrijlandt) >Assigned to: Martin v. L?wis (loewis) Summary: 'insufficient disk space' message wrong (msi on win xp pro) Initial Comment: I'm trying to do a non-admin install of python 2.4.1 using the msi on win xp pro. Our environment is pretty customized; in an ordinary explorer window I see drives I, J but no C. "My Documents" refers to i:\ which is an alias for \\\username. I'm installing to i:\\python241 for my user only. The server has enough diskspace and my diskspace is not limited. When I try to install, bug #1232947 occurs; but when I try to do the same install with a usb-stick attached (which appears as volume "e:"), the installer complains that E has insufficient disk space. In fact, this was true: but I was not installing on E but on I. The disk usage button by the way shows enough diskspace on I: and does not list E: ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:39 Message: Logged In: YES user_id=33168 Martin, do you have time for this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&group_id=5470 From noreply at sourceforge.net Fri Sep 30 10:07:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 01:07:03 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 12:05 Message generated for change (Comment added) made by jacek_poplawski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this 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: Jacek Poplawski (jacek_poplawski) Assigned to: Jason Tishler (jlt63) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- >Comment By: Jacek Poplawski (jacek_poplawski) Date: 2005-09-30 10:07 Message: Logged In: YES user_id=264913 Yes, I can run test_subprocess.py and all 38 tests are OK (in 15 seconds). Just like I wrote I can't reproduce that with any simple command, so maybe problem is that subprocess.Popen locks _if_ application does something specific - but what? PS. But I can reproduce that on few different computers with different Python installations so it is not just installation problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 07:33 Message: Logged In: YES user_id=33168 Jason, any comments? Is this cygwin specific or a general subprocess issue? ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-09-29 21:32 Message: Logged In: YES user_id=344921 Does the testsuite test_subprocess.py work correctly on this platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Fri Sep 30 10:20:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 01:20:55 -0700 Subject: [ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code) Message-ID: Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-30 09:20 Message: Logged In: YES user_id=6656 It's fixed now: Python/pystate.c revision 2.43 Python/pystate.c revision 2.38.2.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:31 Message: Logged In: YES user_id=33168 Wasn't a fix for this checked in? Can this be closed? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:04 Message: Logged In: YES user_id=6656 Can you try the attached? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 14:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 From noreply at sourceforge.net Fri Sep 30 10:44:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 01:44:45 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Martin v. L?wis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-09-30 09:44 Message: Logged In: YES user_id=6656 I'm not particularly convinced that this is a great idea. Python uses 'new' and 'class' as C identifiers which mean you can't compile it as C++ -- but Python isn't written in C++, so this is fine. Similarly, Python isn't designed to be fed to moc -- so why feed it to moc? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 21:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 21:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 21:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 17:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Fri Sep 30 16:55:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 07:55:35 -0700 Subject: [ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README Message-ID: Bugs item #1306248, was opened at 2005-09-27 17:04 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 Please note that this 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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-30 10:55 Message: Logged In: YES user_id=593130 Perhaps there should be a separate README64 file and a line in README "For 64 bit builds, also see README64". This would shrink README for most people while giving full system-specific details for those who need them. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 12:41 Message: Logged In: YES user_id=48806 I understand your reluctance to add cruft to the README, but given that there's no "configure --64-bit --without-gcc" that works, I think that adding something to the docs would be helpful. There's already a history of documenting bugs/limitations of the Python build system in the README, so while I agree with your view that fixing the build system would be best, adding something to the README is a good short-term solution until the 64-bit build kinks are fixed up. I suggest adding something along the lines of what has already been done for AIX/HP-UX 64-bit builds, since those also require unusual steps. Keep it short like these?: AIX 5.3: To build a 64-bit version with IBM's compiler, I used the following: export PATH=/usr/bin:/usr/vacpp/bin ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64" make HP-UX: When using threading, you may have to add -D_REENTRANT to the OPT variable in the top-level Makefile; reported by Pat Knight, this seems to make a difference (at least for HP-UX 10.20) even though pyconfig.h defines it. This seems unnecessary when using HP/UX 11 and later - threading seems to work "out of the box". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 12:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. ---------------------------------------------------------------------- Comment By: John Stone (jestone) Date: 2005-09-29 11:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-29 02:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 From noreply at sourceforge.net Fri Sep 30 16:57:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 07:57:17 -0700 Subject: [ python-Bugs-1309567 ] linechache module returns wrong results Message-ID: Bugs item #1309567, was opened at 2005-09-30 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=1309567&group_id=5470 Please note that this 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: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 From noreply at sourceforge.net Fri Sep 30 17:08:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 08:08:04 -0700 Subject: [ python-Bugs-1309567 ] linechache module returns wrong results Message-ID: Bugs item #1309567, was opened at 2005-09-30 16:57 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 Please note that this 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: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-09-30 17:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 From noreply at sourceforge.net Fri Sep 30 17:38:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 08:38:50 -0700 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by jfriesne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Please note that this 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: Jeremy Friesner (jfriesne) Assigned to: Martin v. L?wis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- >Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-30 15:38 Message: Logged In: YES user_id=383828 On second thought, I believe mwh is right; most of those changes are unnecessary. (I made the changes a long time ago, so when I grepped for them the other day the memory for their motivation wasn't fresh). The Python .c files aren't fed to moc, so references to 'signals' and 'slots' in the .c files should compile okay. It's just the references to those identifiers in the Python .h files that cause a problem, if the .h files are #included in a Qt-using C++ program, after #including a Qt header. So I think probably just the original three changes are sufficient. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-30 08:44 Message: Logged In: YES user_id=6656 I'm not particularly convinced that this is a great idea. Python uses 'new' and 'class' as C identifiers which mean you can't compile it as C++ -- but Python isn't written in C++, so this is fine. Similarly, Python isn't designed to be fed to moc -- so why feed it to moc? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 20:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 16:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Fri Sep 30 18:24:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 09:24:08 -0700 Subject: [ python-Bugs-1309567 ] linechache module returns wrong results Message-ID: Bugs item #1309567, was opened at 2005-09-30 10:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 Please note that this 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: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: linechache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-30 12:24 Message: Logged In: YES user_id=6380 Radical indeed. But what about the use case of modules compiled on one system and moved to a different system? Is that use case important enough? There used to be a different use case, because bytecode files used to contain relative path names. I believe that's been fixed, if only by code in site.py that absolutizes sys.path. (Except the initial '' -- is that important?) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-09-30 11:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 From noreply at sourceforge.net Fri Sep 30 20:38:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 11:38:18 -0700 Subject: [ python-Feature Requests-1309676 ] Add os.path.relpath Message-ID: Feature Requests item #1309676, was opened at 2005-09-30 20:38 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=1309676&group_id=5470 Please note that this message will contain 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 From noreply at sourceforge.net Fri Sep 30 19:50:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 10:50:39 -0700 Subject: [ python-Bugs-1308042 ] Datagram Socket Timeouts Message-ID: Bugs item #1308042, was opened at 2005-09-29 10:05 Message generated for change (Comment added) made by tvrankar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 Please note that this message will contain a full 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: Works For Me Priority: 5 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Tom Vrankar (tvrankar) Date: 2005-09-30 13:50 Message: Logged In: YES user_id=1353485 With Python around, I don't program much in C anymore, and for the same reason I usually assume platform independence (ensured by some clever Python programmer -- C or lib -- spackling over minor underlying differences) unless the Python docs explicitly tell me otherwise. nnorwitz's Linux results match my Solaris 8 results (and are what I intended). I submitted this report since the docs didn't provide any warnings about Python's UDP sockets behaving differently per platform. The behavior I saw would be wacky even on Windoze, but I don't know just how tolerant Windoze developers are of a poor sockets implementation :-). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 01:43 Message: Logged In: YES user_id=33168 This is a dupe of 1307357, but I'm closing that one since most of the comments are here. However, note this one comment from twv in the other report that says it also works on Solaris 8 and could well be Windoze specific. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 01:30 Message: Logged In: YES user_id=33168 Can you program the client in C and see if it behaves the same? Sockets are mostly just wrappers around the OS calls. It's possible this is the expected behaviour on Windows and python is just exposing that to you. I ran this on Linux and got this (which is what I think you want): neal at janus clean $ ./python PyBug/client.py & [1] 31484 neal at janus clean $ timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out ./python PyBug/server.py timed out timed out timed out ('127.0.0.1', 40899) says CHECK ('127.0.0.1', 3000) says OK [10587 refs] [10585 refs] [1]+ Done ./python PyBug/client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 From rkijewski at swri.org Tue Sep 27 17:35:32 2005 From: rkijewski at swri.org (RK) Date: Tue, 27 Sep 2005 15:35:32 -0000 Subject: errors when trying to send mail Message-ID: <433966DD.8070406@swri.org> I've seen another bug submission similar to this. I am using 2.3.4 and I get almost the exact same error. I'm on a linux box (2.6.9-5.ELsmp) and the same code runs fine on other machines and previous versions of python - here's the code snippet: msg = MIMEMultipart() COMMASPACE = ', ' msg['Subject'] = 'NO Build (' + tstr + ')' msg['From'] = 'rkijewski at swri.org' msg['To'] = COMMASPACE.join(buildmgrs) msg['To'] = buildlead msg.preamble = 'Build Results' msg.epilogue = '' mailsrv = smtplib.SMTP('server') mailsrv.sendmail(buildlead, buildlead, msg.as_string()) time.sleep(5) mailsrv.close() ################################################ Here's the error: Traceback (most recent call last): File "./testMail.py", line 60, in ? mailsrv.sendmail(buildlead, buildlead, msg.as_string(unixfrom=True)) File "/usr/lib64/python2.3/email/Message.py", line 130, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib64/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib64/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/lib64/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib64/python2.3/email/Header.py", line 415, in encode return self._encode_chunks(newchunks, maxlinelen) File "/usr/lib64/python2.3/email/Header.py", line 375, in _encode_chunks _max_append(chunks, s, maxlinelen, extra) File "/usr/lib64/python2.3/email/quopriMIME.py", line 84, in _max_append L.append(s.lstrip()) AttributeError: 'list' object has no attribute 'lstrip' Thanks From ronald.kijewski at swri.org Wed Sep 28 16:00:06 2005 From: ronald.kijewski at swri.org (Ronald Kijewski) Date: Wed, 28 Sep 2005 14:00:06 -0000 Subject: errors while trying to send email Message-ID: <1f8f6d1f719b.1f719b1f8f6d@swri.org> I've seen another bug submission similar to this. I am using 2.3.4 and I get almost the exact same error. I'm on a linux box (2.6.9-5.ELsmp) and the same code runs fine on other machines and previous versions of python - here's the code snippet: msg = MIMEMultipart() COMMASPACE = ', ' msg['Subject'] = 'NO Build (' + tstr + ')' msg['From'] = 'rkijewski at swri.org' msg['To'] = COMMASPACE.join(buildmgrs) msg['To'] = buildlead msg.preamble = 'Build Results' msg.epilogue = '' mailsrv = smtplib.SMTP('server') mailsrv.sendmail(buildlead, buildlead, msg.as_string()) time.sleep(5) mailsrv.close() ################################################ Here's the error: Traceback (most recent call last): File "./testMail.py", line 60, in ? mailsrv.sendmail(buildlead, buildlead, msg.as_string(unixfrom=True)) File "/usr/lib64/python2.3/email/Message.py", line 130, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib64/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib64/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/lib64/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib64/python2.3/email/Header.py", line 415, in encode return self._encode_chunks(newchunks, maxlinelen) File "/usr/lib64/python2.3/email/Header.py", line 375, in _encode_chunks _max_append(chunks, s, maxlinelen, extra) File "/usr/lib64/python2.3/email/quopriMIME.py", line 84, in _max_append L.append(s.lstrip()) AttributeError: 'list' object has no attribute 'lstrip' Thanks