From noreply@sourceforge.net Sun Sep 1 13:23:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Sep 2002 05:23:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-601534 ] xmlrpclib ignores CDATA Message-ID: Bugs item #601534, was opened at 2002-08-28 22:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601534&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martijn Pieters (mjpieters) >Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib ignores CDATA Initial Comment: The SlowParser in xmlrpclib ignores CDATA character data sections. No handler is defined for it so any XML-RPC client that escapes parameter values with a CDATA section will result in empty parameters being passed on to the application. The fix is simple, add a self.handle_cdata = target.data line in the SlowParser __init__. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-09-01 14:23 Message: Logged In: YES user_id=38376 already fixed in CVS (june 27, 2002) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601534&group_id=5470 From noreply@sourceforge.net Sun Sep 1 16:07:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Sep 2002 08:07:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-601775 ] some int results that should be bool Message-ID: Bugs item #601775, was opened at 2002-08-29 05:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Christos Georgiou (tzot) >Assigned to: Guido van Rossum (gvanrossum) Summary: some int results that should be bool Initial Comment: Posting this as a SF bug since the relevant patch would be very small. (I can post it as a patch if requested, though). 1. cStringIO.c, line 136, IO_isatty returns PyInt_FromLong (0), while this should be PyBool_FromLong(0). StringIO.isatty returns False --which is -- and so should cStringIO. Note: documentation states that file-like objects not being real files should not define this method. Perhaps it should be removed from cStringIO and StringIO. 2. posixmodule.c, line 759, posix_access returns PyInt_FromLong. It should be PyBool_FromLong. 3. (rather indifferent, this one) svmodule.c, line 393, sv_IsVideoDisplayed should return a bool also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-01 11:07 Message: Logged In: YES user_id=6380 Thanks! I've fixed 1 and 2. I don't think 3 is worth fixing. I think removing the isatty() method serves no purpose except possibly breaking existing code; maybe the docs could be updated, but I don't care enough. BTW, please don't assign bugs to developers. We'll do that on triage. Ditto for the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601775&group_id=5470 From noreply@sourceforge.net Sun Sep 1 23:42:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Sep 2002 15:42:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Jeremy Hylton (jhylton) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Mon Sep 2 00:30:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Sep 2002 16:30:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: Bugs item #602345, was opened at 2002-08-30 07:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) >Assigned to: Guido van Rossum (gvanrossum) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 19:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Mon Sep 2 14:56:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 06:56:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-603509 ] MemoryError when eval'ing string Message-ID: Bugs item #603509, was opened at 2002-09-02 09:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: MemoryError when eval'ing string Initial Comment: eval("'label;home;encoding=quoted-printable:r.'") dies with a bogus MemoryError. Assigned to Martin because this minimal substring dies the same way: eval("'coding=q'") Of course the result should be the string coding=q Somehow it looks like parsing a string literal is getting mixed up with searching for a source-file encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 From noreply@sourceforge.net Mon Sep 2 18:40:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 10:40:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-603509 ] MemoryError when eval'ing string Message-ID: Bugs item #603509, was opened at 2002-09-02 15:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: MemoryError when eval'ing string Initial Comment: eval("'label;home;encoding=quoted-printable:r.'") dies with a bogus MemoryError. Assigned to Martin because this minimal substring dies the same way: eval("'coding=q'") Of course the result should be the string coding=q Somehow it looks like parsing a string literal is getting mixed up with searching for a source-file encoding. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 19:40 Message: Logged In: YES user_id=21627 The attached patch fixes the problem. It is still possible to trick this code, with eval("'#coding=q'") I'm not really sure how to deal with that; I see the following options: 1. tighten PEP 263 to require that the encoding comment is the only thing in a source line. 2. perform some minimal scanning of the line, to see whether we are inside a string literal when we see the #. This can probably be tricked with a multi-line string. 3. perform source encoding analysis after in the tokenizer proper, where comments are detected. This would be a heavy change. 4. Just apply this patch, and wait until somebody complains. Directions appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 From noreply@sourceforge.net Mon Sep 2 22:23:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 14:23:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-603509 ] MemoryError when eval'ing string Message-ID: Bugs item #603509, was opened at 2002-09-02 09:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: MemoryError when eval'ing string Initial Comment: eval("'label;home;encoding=quoted-printable:r.'") dies with a bogus MemoryError. Assigned to Martin because this minimal substring dies the same way: eval("'coding=q'") Of course the result should be the string coding=q Somehow it looks like parsing a string literal is getting mixed up with searching for a source-file encoding. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-02 17:23 Message: Logged In: YES user_id=31435 I don't understand the deeper issues here, but eval(repr(s)) == s must be true for every string s. Take that as an absolute requirement and I'm sure you'll find a way to do it . Waiting for a complaint isn't really an option. It's been perfectly safe to dump strings out to text files via repr(), and restore them via eval(), since Python's first release. The program I was running when this happened was doing exactly that. The strings it was dumping and restoring came from c.l.py msgs, and there's no string that can be guaranteed not to show up there. In particular, it's likely that a msg containing an encoding decoration will show up there as an example. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 13:40 Message: Logged In: YES user_id=21627 The attached patch fixes the problem. It is still possible to trick this code, with eval("'#coding=q'") I'm not really sure how to deal with that; I see the following options: 1. tighten PEP 263 to require that the encoding comment is the only thing in a source line. 2. perform some minimal scanning of the line, to see whether we are inside a string literal when we see the #. This can probably be tricked with a multi-line string. 3. perform source encoding analysis after in the tokenizer proper, where comments are detected. This would be a heavy change. 4. Just apply this patch, and wait until somebody complains. Directions appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 From noreply@sourceforge.net Mon Sep 2 23:37:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 15:37:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-603724 ] setting file buffer size is unreliable Message-ID: Bugs item #603724, was opened at 2002-09-02 22:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: setting file buffer size is unreliable Initial Comment: The description of open() (ie file()) says: "If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size." PyFile_SetBufSize() passes the requested buffer size on to setvbuf(), with NULL as setvbuf()'s second parameter. The C89 standard doesn't guarantee any change to the buffer size when the second parameter is NULL, and some stdio implementations (legitimately) ignore the size parmater in such circumstances. C99's gives more guidelines, but nothing that can be relied upon: "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by the setvbuf function and the argument size specifies the size of the array; otherwise, size may determine the size of buffer allocated by the setvbuf function." (7.19.5.6) (What good is "may" to anyone?) The result of all this is that fd = open('file', 'w', 8) will not have the desired (and documented) effect (flushing the output buffer every 8 characters) on some platforms, so either the documentation of open() or the code (PyFile_SetBufSize()) should be fixed. The same problems exist with setbuf() as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 From noreply@sourceforge.net Tue Sep 3 12:03:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 04:03:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-603930 ] string.punctuation Message-ID: Bugs item #603930, was opened at 2002-09-03 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ignacio Dosil Lago (do_sil) Assigned to: Nobody/Anonymous (nobody) Summary: string.punctuation Initial Comment: string.punctuation doesn't include the characters ¡ and ¿ used in spanish and galician. When I start a python interactive session, import the string module and "print string.punctuation" these two characters never appear (indipendently of the interpreter version). Zope uses this module to implement structured text. When somebody tries to write structured text, in spanish, galician or ..., that includes any of these two characters it doesn't work. For item, **¡this should be bold text if it where structured text in galician!** Is this a lack in the python library or does it depend on a third party? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 From noreply@sourceforge.net Tue Sep 3 12:28:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 04:28:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-603937 ] Exception during _PyString_Resize Message-ID: Bugs item #603937, was opened at 2002-09-03 06:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: Exception during _PyString_Resize Initial Comment: I *think* this is related to the newly mortal string interning (or maybe to the recent changes Walter Dörwald checked in. I'll start with Walter. ;-) The attached little zipfile contains a trivial module (serverdir.py) and an ASCII pickle (foo.dat) which has not changed for a couple years. Today, I noticed that Python began barfing during startup (this particular pickle gets read in as a side effect of my rather heavyweight interactive initialization stuff). In a python -S session, if I execute: import pickle o = pickle.Unpickler(open("foo.dat")).load() I get the following traceback: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/pickle.py", line 674, in load dispatch[key](self) File "/usr/local/lib/python2.3/pickle.py", line 753, in load_string self.append(rep.decode("string-escape")) SystemError: ../Objects/stringobject.c:3268: bad argument to internal function Line 3268 in stringobject.c is in _PyString_Resize. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 From noreply@sourceforge.net Tue Sep 3 12:54:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 04:54:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-603509 ] MemoryError when eval'ing string Message-ID: Bugs item #603509, was opened at 2002-09-02 15:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: MemoryError when eval'ing string Initial Comment: eval("'label;home;encoding=quoted-printable:r.'") dies with a bogus MemoryError. Assigned to Martin because this minimal substring dies the same way: eval("'coding=q'") Of course the result should be the string coding=q Somehow it looks like parsing a string literal is getting mixed up with searching for a source-file encoding. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-03 13:54 Message: Logged In: YES user_id=21627 Fixed with tokenizer.c 2.66; tokenizer.h 2.19; ref2.tex 1.43; ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-02 23:23 Message: Logged In: YES user_id=31435 I don't understand the deeper issues here, but eval(repr(s)) == s must be true for every string s. Take that as an absolute requirement and I'm sure you'll find a way to do it . Waiting for a complaint isn't really an option. It's been perfectly safe to dump strings out to text files via repr(), and restore them via eval(), since Python's first release. The program I was running when this happened was doing exactly that. The strings it was dumping and restoring came from c.l.py msgs, and there's no string that can be guaranteed not to show up there. In particular, it's likely that a msg containing an encoding decoration will show up there as an example. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 19:40 Message: Logged In: YES user_id=21627 The attached patch fixes the problem. It is still possible to trick this code, with eval("'#coding=q'") I'm not really sure how to deal with that; I see the following options: 1. tighten PEP 263 to require that the encoding comment is the only thing in a source line. 2. perform some minimal scanning of the line, to see whether we are inside a string literal when we see the #. This can probably be tricked with a multi-line string. 3. perform source encoding analysis after in the tokenizer proper, where comments are detected. This would be a heavy change. 4. Just apply this patch, and wait until somebody complains. Directions appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603509&group_id=5470 From noreply@sourceforge.net Tue Sep 3 14:11:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 06:11:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-603937 ] Exception during _PyString_Resize Message-ID: Bugs item #603937, was opened at 2002-09-03 13:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: Exception during _PyString_Resize Initial Comment: I *think* this is related to the newly mortal string interning (or maybe to the recent changes Walter Dörwald checked in. I'll start with Walter. ;-) The attached little zipfile contains a trivial module (serverdir.py) and an ASCII pickle (foo.dat) which has not changed for a couple years. Today, I noticed that Python began barfing during startup (this particular pickle gets read in as a side effect of my rather heavyweight interactive initialization stuff). In a python -S session, if I execute: import pickle o = pickle.Unpickler(open("foo.dat")).load() I get the following traceback: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/pickle.py", line 674, in load dispatch[key](self) File "/usr/local/lib/python2.3/pickle.py", line 753, in load_string self.append(rep.decode("string-escape")) SystemError: ../Objects/stringobject.c:3268: bad argument to internal function Line 3268 in stringobject.c is in _PyString_Resize. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-03 15:11 Message: Logged In: YES user_id=89016 This is a problem with PyString_DecodeEscape, not with the PEP293 patch. The simplest test case is the following: >>> import codecs >>> codecs.escape_decode('') # empty string Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/stringobject.c:3268: bad argument to internal function PyString_DecodeEscape tries to resize the empty string (which it got from PyString_FromStringAndSize(..., 0)) to the length 0, which fails, because this empty string has more than one reference. Checking whether a resize is neccessary fixes this bug. I'll check in the fix and a test case for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 From noreply@sourceforge.net Tue Sep 3 14:55:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 06:55:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-603937 ] Exception during _PyString_Resize Message-ID: Bugs item #603937, was opened at 2002-09-03 13:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: Exception during _PyString_Resize Initial Comment: I *think* this is related to the newly mortal string interning (or maybe to the recent changes Walter Dörwald checked in. I'll start with Walter. ;-) The attached little zipfile contains a trivial module (serverdir.py) and an ASCII pickle (foo.dat) which has not changed for a couple years. Today, I noticed that Python began barfing during startup (this particular pickle gets read in as a side effect of my rather heavyweight interactive initialization stuff). In a python -S session, if I execute: import pickle o = pickle.Unpickler(open("foo.dat")).load() I get the following traceback: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/pickle.py", line 674, in load dispatch[key](self) File "/usr/local/lib/python2.3/pickle.py", line 753, in load_string self.append(rep.decode("string-escape")) SystemError: ../Objects/stringobject.c:3268: bad argument to internal function Line 3268 in stringobject.c is in _PyString_Resize. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-03 15:55 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_codecs.py 1.4 Objects/stringobject.c 2.187 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-03 15:11 Message: Logged In: YES user_id=89016 This is a problem with PyString_DecodeEscape, not with the PEP293 patch. The simplest test case is the following: >>> import codecs >>> codecs.escape_decode('') # empty string Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/stringobject.c:3268: bad argument to internal function PyString_DecodeEscape tries to resize the empty string (which it got from PyString_FromStringAndSize(..., 0)) to the length 0, which fails, because this empty string has more than one reference. Checking whether a resize is neccessary fixes this bug. I'll check in the fix and a test case for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603937&group_id=5470 From noreply@sourceforge.net Tue Sep 3 15:02:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 07:02:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Jeremy Hylton (jhylton) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Tue Sep 3 16:39:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 08:39:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: Bugs item #602345, was opened at 2002-08-30 07:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) >Assigned to: Neal Norwitz (nnorwitz) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 19:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Tue Sep 3 17:05:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 09:05:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Tue Sep 3 17:38:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 09:38:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe Message-ID: Bugs item #601077, was opened at 2002-08-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: bug in new execvpe Initial Comment: From: "Steve M. Robbins" I think the patch associated with this thread has an unintended consequence. In http://mail.python.org/pipermail/python-dev/2002-August/027229.html Zack pointed out three flaws in the original code: [...] Third, if an error other than the expected one comes back, the loop clobbers the saved exception info and keeps going. Consider the situation where PATH=/bin:/usr/bin, /bin/foobar exists but is not executable by the invoking user, and /usr/bin/foobar does not exist. The exception thrown will be 'No such file or directory', not the expected 'Permission denied'. The patch, as I understand it, changes the behaviour so as to raise the exception "Permission denied" in this case. Consider a similar situation in which both /bin/foobar (not executable by the user) and /usr/bin/foobar (executable by the user) exist. Given the command "foobar", the shell will execute /usr/bin/foobar. If I understand the patch correctly, python will give up when it encounters /bin/foobar and raise the "Permission denied" exception. I believe this just happened to me today. I had a shell script named "gcc" in ~/bin (first on my path) some months back. When I was finished with it, I just did "chmod -x ~/bin/gcc" and forgot about it. Today was the first time since this patch went in that I ran gcc via python (using scipy's weave). Boy was I surprised at the message "unable to execute gcc: Permission denied"! I guess the fix is to save the EPERM exception and keep going in case there is an executable later in the path. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 12:38 Message: Logged In: YES user_id=6380 Thanks, Zack! Checked in for 2.2 and CVS head. ---------------------------------------------------------------------- Comment By: Zack Weinberg (zackw) Date: 2002-08-31 15:10 Message: Logged In: YES user_id=580015 I've created a patch for this bug. I would like to attach it, but Sourceforge doesn't want to let me do that, so I'll just insert it inline here: =================================================================== Index: Lib/os.py --- Lib/os.py 5 Aug 2002 16:13:24 -0000 1.59 +++ Lib/os.py 31 Aug 2002 19:08:34 -0000 @@ -309,7 +309,7 @@ def execvp(file, args): _execvpe(file, args) def execvpe(file, args, env): - """execv(file, args, env) + """execvpe(file, args, env) Execute the executable file (which is searched for along $PATH) with argument list args and environment env , replacing the @@ -339,14 +339,21 @@ def _execvpe(file, args, env=None): else: envpath = defpath PATH = envpath.split(pathsep) + saved_exc = None + saved_tb = None for dir in PATH: fullname = path.join(dir, file) try: apply(func, (fullname,) + argrest) - except error, (errno, msg): - if errno != ENOENT and errno != ENOTDIR: - raise - raise error, (errno, msg) + except error, e: + tb = sys.exc_info()[2] + if (e.errno != ENOENT and e.errno != ENOTDIR + and saved_exc is None): + saved_exc = e + saved_tb = tb + if saved_exc: + raise error, saved_exc, saved_tb + raise error, e, tb # Change environ to automatically call putenv() if it exists try: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-27 21:06 Message: Logged In: YES user_id=6380 Since I applied Zack's patch to the trunk as well as to the 2.2 maintenance branch, this needs to be fixed in both places. This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I haven't tested that). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 From noreply@sourceforge.net Tue Sep 3 17:29:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 09:29:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Jeremy Hylton (jhylton) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 12:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Tue Sep 3 18:54:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 10:54:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Jeremy Hylton (jhylton) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Mark Moales (mmoales) Date: 2002-09-03 13:54 Message: Logged In: YES user_id=565165 I was able to get 2.3 to build (with the latest stuff from CVS) and the problem seems to be fixed. I'll try and update 2.2.1 when I have some time and test that. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 12:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:12:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:12:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-591586 ] Get rid of etype struct Message-ID: Bugs item #591586, was opened at 2002-08-06 17:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Get rid of etype struct Initial Comment: The 'etype' struct in typeobject.c prevents people like David Abrahams and Christian Tismer from defining C-level metatypes that add slots to the end of the type structure. It should be possible for type_new() to place the additional structures after an offset determined by tp_basicsize of the metatype, rather than at a fixed offset. ---------------------------------------------------------------------- >Comment By: Christian Tismer (tismer) Date: 2002-09-03 20:12 Message: Logged In: YES user_id=105700 Hi Guido, I think I have a solution for this one, see the attached diff. I did what you suggested: Make the adressing of the members dependant from the metatype. The etype struct has lost its members[1] field, to make it easier to extend the structure. Instead, the allocator always adds one to the size, to have the sentinel in place. I did not yet publish the etype stucture, since I didn't find a good name and place for it. Testing was also not very thorow. I just checked that types work from Python and that I can add __slots__ to them. Will re-port this stuff to my Py2.2 Stackless base and try it out as base type for my own C types. ciao - chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:49:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:49:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-604128 ] time.struct_time undocumented Message-ID: Bugs item #604128, was opened at 2002-09-03 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.struct_time undocumented Initial Comment: The time module has a mystery name called "struct_time" which is undocumented. It is used in a couple of places such as imaplib.py, test_structseq.py and test_strptime.py. It should be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:23:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-597795 ] spawn*() doesn't handle errors well Message-ID: Bugs item #597795, was opened at 2002-08-20 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597795&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Hickey (gohickey) >Assigned to: Guido van Rossum (gvanrossum) Summary: spawn*() doesn't handle errors well Initial Comment: spawn*() routines are supposed to return the child's pid, but if an error occurs (such as bad parameters, etc.), it returns 127. This "looks" like a valid pid, so the caller has no way of knowing if something when wrong. Throwing an exception would be much more informational (and python-esque). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:23 Message: Logged In: YES user_id=6380 There's nothing that can be done about this. These errors are detected in the child process; the child process cannot cause an exception to be raised in the parent. _exit(127) is what the C library's system() function does in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597795&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:27:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:27:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-597797 ] exec*() doesn't handle errors well Message-ID: Bugs item #597797, was opened at 2002-08-20 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None >Priority: 3 Submitted By: Jim Hickey (gohickey) >Assigned to: Guido van Rossum (gvanrossum) Summary: exec*() doesn't handle errors well Initial Comment: If an error occurs in exec*(), (such as bad parameters, etc.) exec*() returns to the caller. exec*() is not supposed to return. Throwing an exception would be a better way to handle errors. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:27 Message: Logged In: YES user_id=6380 I don't understand this report. I *do* get an error about exec*() arguments. Can you show an example of this bad behavior, and indicate what you'd like it to do instead? If I don't get a response within a week, I'll close this bug report as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597797&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:34:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:34:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-598451 ] The KeyError message doesn't use repr on the key value repor Message-ID: Bugs item #598451, was opened at 2002-08-21 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Guido van Rossum (gvanrossum) >Summary: The KeyError message doesn't use repr on the key value repor Initial Comment: >>> {}[1] Traceback (most recent call last): File "", line 1, in ? KeyError: 1 >>> {}[''] Traceback (most recent call last): File "", line 1, in ? KeyError Note that the second message is very confusing if you don't know that it means the KeyError is on a blank key. In any case I think KeyError should use repr on the key value in order to make it clear what is being used as the key. According to zigg, that should also fix the fact that the : goes missing in the second case. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:34 Message: Logged In: YES user_id=6380 This could be considered a feature -- it was done this way on purpose. But it's a very annoying feature, and I think we may want to change this. I'll see if I can get some feedback from python-dev. Since it's a feature change, I can only change this in 2.3, not in 2.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:31:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:31:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-598160 ] import _tkinter python dumps core. Message-ID: Bugs item #598160, was opened at 2002-08-21 05:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 Category: Build >Group: Platform-specific Status: Open Resolution: None >Priority: 3 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: import _tkinter python dumps core. Initial Comment: We are trying to build python on a HP-UX 11.00 using gcc 3.1. But when it comes to the stage when it tries to load _tkinter i.e. import _tkinter python dumps core. running gdb on the core file gives us that it get's a segfault on the line Python/import.c:210 i.e if (interp->modules == NULL) and yes, interp is null... any clue how to continue? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:31 Message: Logged In: YES user_id=6380 Things like this are notoriously hard to debug. Perhaps GCC 3.1 has a bug (it's rather new, and HP-UX is an infrequently used platform for this compiler). Could you try with an older GCC version? I don't think I've seen this report before. Are there problems with any other modules? Does the test suite run successfully? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:40:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:40:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-599163 ] execfile() not show filename when IOErro Message-ID: Bugs item #599163, was opened at 2002-08-23 06:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Peter Schneider-Kamp (nowonder) Summary: execfile() not show filename when IOErro Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 >>> try: execfile('non_existent_file') ... except IOError, msg: msg.__dict__ {'errno': 2, 'args': (2, 'No such file or directory'), 'strerror': 'No such file or directory', 'filename': None} There should be a filename, not None. -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:40 Message: Logged In: YES user_id=6380 Credit where credit is due. :-) ---------------------------------------------------------------------- Comment By: Peter Schneider-Kamp (nowonder) Date: 2002-08-27 12:59 Message: Logged In: YES user_id=14463 execfile incorrectly called PyErr_SetFromErrno instead of PyErr_SetFromErrnoWithFilename. Resolution is obvious and already committed to cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599163&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:41:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:41:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-599452 ] Method resolution order in Py 2.2 - 2.3 Message-ID: Bugs item #599452, was opened at 2002-08-23 19:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alex A. Naanou (alex_nanou) Assigned to: Nobody/Anonymous (nobody) Summary: Method resolution order in Py 2.2 - 2.3 Initial Comment: -- from "What's new in Python 2.2" section 2.3 "Multiple Inheritance: The Diamond Rule" """ Multiple inheritance has also been made more useful through changing the rules under which names are resolved. """ Well, for a feature that was officially "introduced" in version 2.2 it shows a remarkable lack of presence (even in the CVS versions of 2.3)!! // though, I could have missed something (an elephant in // my backyard!), if so please point it out... Description: Actually, there is nothing wrong... the function in question is just not changed since version 2.1.x, thus we get the old style lookup table (Method resolution order). I'll try not to get too carried away.. here is an example 'almost' literally taken from that same section of the documentation mentioned above: ---cut--- class A: def save(self): return "I am 'A.save'" class B(A): pass class C(A): def save(self): return "I am 'C.save'" class D(B,C): pass print D().save() ---uncut--- Expected Results: something printed EXACTLY like: >>> I am 'C.save' Actual Result: //here is the part where I faint... :| we get: >>> I am 'A.save' The results are identical for: - Python 2.2 - Python 2.2.1 - Python 2.3 (CVS) Thanks!! ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-08-23 19:30 Message: Logged In: YES user_id=35752 You need to make 'A' subclass from 'object' in order to get the new MRO behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599452&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:42:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:42:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-599679 ] CRAM-MD5 module Message-ID: Bugs item #599679, was opened at 2002-08-24 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Piers Lauder (pierslauder) Summary: CRAM-MD5 module Initial Comment: [Taken from http://bugs.debian.org/154283] A request to provide CRAM-MD5 authentification (in imaplib). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:42 Message: Logged In: YES user_id=6380 Assigning to Piers Lauder, who supports the imaplib module. But it would be nice if you submitted a patch. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-25 08:31 Message: Logged In: YES user_id=163326 Well, the necessary code could probably be found in smtplib.py. Perhaps it only needs to be adapted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470 From noreply@sourceforge.net Tue Sep 3 21:25:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 13:25:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-598451 ] The KeyError message doesn't use repr on the key value repor Message-ID: Bugs item #598451, was opened at 2002-08-21 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Guido van Rossum (gvanrossum) Summary: The KeyError message doesn't use repr on the key value repor Initial Comment: >>> {}[1] Traceback (most recent call last): File "", line 1, in ? KeyError: 1 >>> {}[''] Traceback (most recent call last): File "", line 1, in ? KeyError Note that the second message is very confusing if you don't know that it means the KeyError is on a blank key. In any case I think KeyError should use repr on the key value in order to make it clear what is being used as the key. According to zigg, that should also fix the fact that the : goes missing in the second case. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 16:25 Message: Logged In: YES user_id=6380 Fixed in CVS head. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:34 Message: Logged In: YES user_id=6380 This could be considered a feature -- it was done this way on purpose. But it's a very annoying feature, and I think we may want to change this. I'll see if I can get some feedback from python-dev. Since it's a feature change, I can only change this in 2.3, not in 2.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598451&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:19:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:19:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-603930 ] string.punctuation Message-ID: Bugs item #603930, was opened at 2002-09-03 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ignacio Dosil Lago (do_sil) Assigned to: Nobody/Anonymous (nobody) Summary: string.punctuation Initial Comment: string.punctuation doesn't include the characters ¡ and ¿ used in spanish and galician. When I start a python interactive session, import the string module and "print string.punctuation" these two characters never appear (indipendently of the interpreter version). Zope uses this module to implement structured text. When somebody tries to write structured text, in spanish, galician or ..., that includes any of these two characters it doesn't work. For item, **¡this should be bold text if it where structured text in galician!** Is this a lack in the python library or does it depend on a third party? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-03 23:19 Message: Logged In: YES user_id=21627 However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking g objects, which would be locale-aware. However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking unicodedata.category(u"\xa1"); this gives "Po". The Unicode database recognizes the following punctuation categories: Pc Punctuation, Connector Pd Punctuation, Dash Ps Punctuation, Open Pe Punctuation, Close Pi Punctuation, Initial quote (may behave like Ps or Pe depending on usage) Pf Punctuation, Final quote (may behave like Ps or Pe depending on usage) Po Punctuation, Other So I would recommend that Zope uses the Unicode database. They should either check for categories starting with "P". It might be worth noting that string.punctuation contains characters that are not classified as punctuators in Unicode: $ Sc + Sm < Sm = Sm > Sm ^ Sk ` Sk | Sm ~ Sm (Sm: Symbol, Math; Sc Symbol, Currency; Sk Symbol, Modifier) So it might be that Zope is also interested in symbols (categories starting with "S"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:21:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:21:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-602102 ] configure finds c++ w/o --with-cxx Message-ID: Bugs item #602102, was opened at 2002-08-29 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: configure finds c++ w/o --with-cxx Initial Comment: When I run configure on today's Python CVS HEAD (2.3a0) on an Alpha/Tru64 machine, configure finds c++ even though I didn't ask for it (and it doesn't work): odoalpha2> ./configure --prefix=$HOME/work --without-gcc checking MACHDEP... osf1V5 checking for --without-gcc... yes checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output... a.out checking whether the C++ compiler works... 1129800:./a.out: /sbin/loader: Fatal Error: Cannot map library libstdc++.so.2.9.0 configure: error: cannot run C++ compiled programs. If you meant to cross compile, use `--host'. Is this a bug? Is there a simple work around? ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2002-08-30 15:15 Message: Logged In: YES user_id=320512 Sorry about this one guys. Looks like the secret is: --with-cxx=no Please close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602102&group_id=5470 From noreply@sourceforge.net Tue Sep 3 23:20:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:20:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib throws a TypeError when the target host disconnects Message-ID: Bugs item #591349, was opened at 2002-08-06 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Rob Green (rbgrn) Assigned to: Jeremy Hylton (jhylton) Summary: httplib throws a TypeError when the target host disconnects Initial Comment: This is the output that occurs about 1 in 500 hits to any particular URL. I've only seen it so far hitting servers running Apache 1.3.20, but I don't have enough data to limit it to that. Python 2.1.2 (#1, Mar 16 2002, 18:24:08) [GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4 h = httplib.HTTPConnection(host) response = h.getresponse() data = response.read() File "/usr/local/lib/python2.1/httplib.py", line 246, in read value = value + self._safe_read(chunk_left) File "/usr/local/lib/python2.1/httplib.py", line 314, in _safe_read chunk = self.fp.read(amt) TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:20 Message: Logged In: YES user_id=31392 A bunch of questions. You seem to have narrowed this problem down a lot, but I'm not sure I understand the diagnosis. First off, have you tried the latest version of the code from CVS? It has changed in several ways, so it would be helpful if you could test with that version. I've been running a test driver for about an hour now without seeing any errors caused by httplib. The real problem I have is understanding what path through the code leaves chunked set to a true value and chunk_left set to something invalid. The begin() method of an HTTPResponse always sets chunked to 1 or 0. If it sets chunked to 1, it sets chunk_left to None. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-08 04:14 Message: Logged In: YES user_id=590105 Line 245 should be "if chunk_left is not _UNKNOWN:" And the next block up to line 259 should be indented. This causes an IncompleteRead exception to be thrown, which is IMO the correct one in this case. I attached a diff that patches the Python 2.1.2 httplib. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-08 03:51 Message: Logged In: YES user_id=590105 Ok I figured out what causes this. It's not a threading issue or anything like that, basically what happens is this: When httplib connects to a server and the hostname is good and the port is open and connects, but the server immediately disconnects without printing any text or anything, this exception is then thrown. I was able to reproduce it by running netcat -l -p locally and starting an HTTPConnection to that port, then punting netcat which causes python to throw the exception. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 06:16 Message: Logged In: YES user_id=590105 Ok I put together some test code that reproduced the bug in under an hour on my machine. Here it is... ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 05:14 Message: Logged In: YES user_id=590105 I'd give you the URLs but I don't think it matters that much, I've seen this problem now hitting 4 different machines, all running linux/apache. It's not something very easy for me to reproduce because I only see the exception thrown once or maybe twice during the day where there are 20,000 hits from my daemon that day. I suppose that the way to reproduce it would be to have a list of urls, and to just have an app sit there and cycle through them doing a GET every 5 seconds or so, and eventually it should show up. I suppose to be more accurate the app would have to be threaded as well, maybe having a thread for each url that just opens an HTTPConnection every 5 seconds. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-06 12:42 Message: Logged In: YES user_id=31392 Can you provide any more information about what URLs cause problems? You could call set_debuglevel(1) to enable output of all HTTP trafffic. Or just a list of some of the URLs that failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 From noreply@sourceforge.net Tue Sep 3 23:21:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:21:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:21 Message: Logged In: YES user_id=31392 Maybe it isn't innocuous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Tue Sep 3 23:38:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:38:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:38 Message: Logged In: YES user_id=31392 Right, in this particular case it is safe. The programmer can also use the warnings module to stop the warning about the optimization. The same would happen is someone used "None=None" in an argument list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 22:35 Message: Logged In: YES user_id=44345 Granted, perhaps it's not. In this case it is. The programmer was copying None from builtins to the local scope to speed up access to that object. If they had done something like None = 87 I would have expected a warning. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:21 Message: Logged In: YES user_id=31392 Maybe it isn't innocuous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Tue Sep 3 23:35:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:35:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-603724 ] setting file buffer size is unreliable Message-ID: Bugs item #603724, was opened at 2002-09-02 22:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: setting file buffer size is unreliable Initial Comment: The description of open() (ie file()) says: "If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size." PyFile_SetBufSize() passes the requested buffer size on to setvbuf(), with NULL as setvbuf()'s second parameter. The C89 standard doesn't guarantee any change to the buffer size when the second parameter is NULL, and some stdio implementations (legitimately) ignore the size parmater in such circumstances. C99's gives more guidelines, but nothing that can be relied upon: "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by the setvbuf function and the argument size specifies the size of the array; otherwise, size may determine the size of buffer allocated by the setvbuf function." (7.19.5.6) (What good is "may" to anyone?) The result of all this is that fd = open('file', 'w', 8) will not have the desired (and documented) effect (flushing the output buffer every 8 characters) on some platforms, so either the documentation of open() or the code (PyFile_SetBufSize()) should be fixed. The same problems exist with setbuf() as well. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:35 Message: Logged In: YES user_id=31392 The C99 rationale has a helpful comment on the subject of setvbuf(): C90 was not clear about what, if anything, the size argument means when buf is a null pointer. Existing practice is mixed: some implementations ignore it completely, other implementations use it as guidance for determining the size of the buffer allocated by setvbuf. C9X gives warning that size might be ignored in this case, so portable programs must be sure to supply a reasonable value. I'd be mostly inclined to change the documentation to say that the buffer is under control of the C library and that Python does whatever setvbuf() does. Or however we write the C99 weasel words in Python docstring-ease. Thankfully, Linux and Windows both have sane setvbuf() implementations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 From noreply@sourceforge.net Tue Sep 3 23:35:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:35:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 17:35 Message: Logged In: YES user_id=44345 Granted, perhaps it's not. In this case it is. The programmer was copying None from builtins to the local scope to speed up access to that object. If they had done something like None = 87 I would have expected a warning. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 17:21 Message: Logged In: YES user_id=31392 Maybe it isn't innocuous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Wed Sep 4 02:57:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 18:57:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-604128 ] time.struct_time undocumented Message-ID: Bugs item #604128, was opened at 2002-09-03 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.struct_time undocumented Initial Comment: The time module has a mystery name called "struct_time" which is undocumented. It is used in a couple of places such as imaplib.py, test_structseq.py and test_strptime.py. It should be documented. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 21:57 Message: Logged In: YES user_id=12800 It should also be renamed to be something like TimeStructType. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 From noreply@sourceforge.net Wed Sep 4 07:36:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 23:36:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-604387 ] long list in Pythonwin -> weird text Message-ID: Bugs item #604387, was opened at 2002-09-04 06:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: James Briggs (jbriggs66) Assigned to: Tim Peters (tim_one) Summary: long list in Pythonwin -> weird text Initial Comment: Using Pythonwin (build 148) with ActiveState 2.2.1 >>> import sys >>> sys.modules.keys() ['code', 'pywin.framework.cmdline', .... after about 15 lines the output goes weird. Text is mostly stuck on 1st column, some text appears and disappears as the scroll bar is moved. Tried this with Python 2.1 and Pythonwin (build 147 also) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 From noreply@sourceforge.net Wed Sep 4 07:58:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 23:58:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe Message-ID: Bugs item #601077, was opened at 2002-08-28 01:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: bug in new execvpe Initial Comment: From: "Steve M. Robbins" I think the patch associated with this thread has an unintended consequence. In http://mail.python.org/pipermail/python-dev/2002-August/027229.html Zack pointed out three flaws in the original code: [...] Third, if an error other than the expected one comes back, the loop clobbers the saved exception info and keeps going. Consider the situation where PATH=/bin:/usr/bin, /bin/foobar exists but is not executable by the invoking user, and /usr/bin/foobar does not exist. The exception thrown will be 'No such file or directory', not the expected 'Permission denied'. The patch, as I understand it, changes the behaviour so as to raise the exception "Permission denied" in this case. Consider a similar situation in which both /bin/foobar (not executable by the user) and /usr/bin/foobar (executable by the user) exist. Given the command "foobar", the shell will execute /usr/bin/foobar. If I understand the patch correctly, python will give up when it encounters /bin/foobar and raise the "Permission denied" exception. I believe this just happened to me today. I had a shell script named "gcc" in ~/bin (first on my path) some months back. When I was finished with it, I just did "chmod -x ~/bin/gcc" and forgot about it. Today was the first time since this patch went in that I ran gcc via python (using scipy's weave). Boy was I surprised at the message "unable to execute gcc: Permission denied"! I guess the fix is to save the EPERM exception and keep going in case there is an executable later in the path. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-09-04 06:58 Message: Logged In: YES user_id=60903 should be checked in to the 2.1 branch as well. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 16:38 Message: Logged In: YES user_id=6380 Thanks, Zack! Checked in for 2.2 and CVS head. ---------------------------------------------------------------------- Comment By: Zack Weinberg (zackw) Date: 2002-08-31 19:10 Message: Logged In: YES user_id=580015 I've created a patch for this bug. I would like to attach it, but Sourceforge doesn't want to let me do that, so I'll just insert it inline here: =================================================================== Index: Lib/os.py --- Lib/os.py 5 Aug 2002 16:13:24 -0000 1.59 +++ Lib/os.py 31 Aug 2002 19:08:34 -0000 @@ -309,7 +309,7 @@ def execvp(file, args): _execvpe(file, args) def execvpe(file, args, env): - """execv(file, args, env) + """execvpe(file, args, env) Execute the executable file (which is searched for along $PATH) with argument list args and environment env , replacing the @@ -339,14 +339,21 @@ def _execvpe(file, args, env=None): else: envpath = defpath PATH = envpath.split(pathsep) + saved_exc = None + saved_tb = None for dir in PATH: fullname = path.join(dir, file) try: apply(func, (fullname,) + argrest) - except error, (errno, msg): - if errno != ENOENT and errno != ENOTDIR: - raise - raise error, (errno, msg) + except error, e: + tb = sys.exc_info()[2] + if (e.errno != ENOENT and e.errno != ENOTDIR + and saved_exc is None): + saved_exc = e + saved_tb = tb + if saved_exc: + raise error, saved_exc, saved_tb + raise error, e, tb # Change environ to automatically call putenv() if it exists try: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-28 01:06 Message: Logged In: YES user_id=6380 Since I applied Zack's patch to the trunk as well as to the 2.2 maintenance branch, this needs to be fixed in both places. This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I haven't tested that). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 From noreply@sourceforge.net Wed Sep 4 09:01:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 01:01:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-603930 ] string.punctuation Message-ID: Bugs item #603930, was opened at 2002-09-03 07:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ignacio Dosil Lago (do_sil) Assigned to: Nobody/Anonymous (nobody) Summary: string.punctuation Initial Comment: string.punctuation doesn't include the characters ¡ and ¿ used in spanish and galician. When I start a python interactive session, import the string module and "print string.punctuation" these two characters never appear (indipendently of the interpreter version). Zope uses this module to implement structured text. When somebody tries to write structured text, in spanish, galician or ..., that includes any of these two characters it doesn't work. For item, **¡this should be bold text if it where structured text in galician!** Is this a lack in the python library or does it depend on a third party? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2002-09-04 04:01 Message: Logged In: YES user_id=11084 I agree with Martin that it would be better to use the informations from unicode. On the other side there is restructuredtext approaching as standard for Python and there is also a reStructuredText product for Zope available that resolves most of the related problem by having a better markup and a clear markup. It is a pain to give these kind of punctuation problems for every country and language. I suggest to hack STletters.py for your needs. The current StructuredText implementation in Zope has these problems by design and it is hard to fix them. -aj ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-03 17:19 Message: Logged In: YES user_id=21627 However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking g objects, which would be locale-aware. However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking unicodedata.category(u"\xa1"); this gives "Po". The Unicode database recognizes the following punctuation categories: Pc Punctuation, Connector Pd Punctuation, Dash Ps Punctuation, Open Pe Punctuation, Close Pi Punctuation, Initial quote (may behave like Ps or Pe depending on usage) Pf Punctuation, Final quote (may behave like Ps or Pe depending on usage) Po Punctuation, Other So I would recommend that Zope uses the Unicode database. They should either check for categories starting with "P". It might be worth noting that string.punctuation contains characters that are not classified as punctuators in Unicode: $ Sc + Sm < Sm = Sm > Sm ^ Sk ` Sk | Sm ~ Sm (Sm: Symbol, Math; Sc Symbol, Currency; Sk Symbol, Modifier) So it might be that Zope is also interested in symbols (categories starting with "S"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 From noreply@sourceforge.net Wed Sep 4 09:47:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 01:47:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-603930 ] string.punctuation Message-ID: Bugs item #603930, was opened at 2002-09-03 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ignacio Dosil Lago (do_sil) Assigned to: Nobody/Anonymous (nobody) Summary: string.punctuation Initial Comment: string.punctuation doesn't include the characters ¡ and ¿ used in spanish and galician. When I start a python interactive session, import the string module and "print string.punctuation" these two characters never appear (indipendently of the interpreter version). Zope uses this module to implement structured text. When somebody tries to write structured text, in spanish, galician or ..., that includes any of these two characters it doesn't work. For item, **¡this should be bold text if it where structured text in galician!** Is this a lack in the python library or does it depend on a third party? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 10:47 Message: Logged In: YES user_id=21627 Closing this bug as not-a-python-problem. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2002-09-04 10:01 Message: Logged In: YES user_id=11084 I agree with Martin that it would be better to use the informations from unicode. On the other side there is restructuredtext approaching as standard for Python and there is also a reStructuredText product for Zope available that resolves most of the related problem by having a better markup and a clear markup. It is a pain to give these kind of punctuation problems for every country and language. I suggest to hack STletters.py for your needs. The current StructuredText implementation in Zope has these problems by design and it is hard to fix them. -aj ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-03 23:19 Message: Logged In: YES user_id=21627 However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking g objects, which would be locale-aware. However, it might be better for Zope to use a truly locale-independent determination of punctuation, namely the Unicode database. Invoking unicodedata.category(u"\xa1"); this gives "Po". The Unicode database recognizes the following punctuation categories: Pc Punctuation, Connector Pd Punctuation, Dash Ps Punctuation, Open Pe Punctuation, Close Pi Punctuation, Initial quote (may behave like Ps or Pe depending on usage) Pf Punctuation, Final quote (may behave like Ps or Pe depending on usage) Po Punctuation, Other So I would recommend that Zope uses the Unicode database. They should either check for categories starting with "P". It might be worth noting that string.punctuation contains characters that are not classified as punctuators in Unicode: $ Sc + Sm < Sm = Sm > Sm ^ Sk ` Sk | Sm ~ Sm (Sm: Symbol, Math; Sc Symbol, Currency; Sk Symbol, Modifier) So it might be that Zope is also interested in symbols (categories starting with "S"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603930&group_id=5470 From noreply@sourceforge.net Wed Sep 4 09:53:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 01:53:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-598160 ] import _tkinter python dumps core. Message-ID: Bugs item #598160, was opened at 2002-08-21 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 3 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: import _tkinter python dumps core. Initial Comment: We are trying to build python on a HP-UX 11.00 using gcc 3.1. But when it comes to the stage when it tries to load _tkinter i.e. import _tkinter python dumps core. running gdb on the core file gives us that it get's a segfault on the line Python/import.c:210 i.e if (interp->modules == NULL) and yes, interp is null... any clue how to continue? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 10:53 Message: Logged In: YES user_id=21627 I would recommend to trace the value of _PyThreadState_Current, perhaps by adding printfs every time this variable changes, and is accessed. I think it is impossible to create a thread state that has a NULL interp, so when you find that the thread state is the same all the time, you should then try to find out where ->interp is cleared (do you have watchpoints in gdb on HP-UX?) Somebody might be overwriting memory. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:31 Message: Logged In: YES user_id=6380 Things like this are notoriously hard to debug. Perhaps GCC 3.1 has a bug (it's rather new, and HP-UX is an infrequently used platform for this compiler). Could you try with an older GCC version? I don't think I've seen this report before. Are there problems with any other modules? Does the test suite run successfully? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 From noreply@sourceforge.net Wed Sep 4 09:55:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 01:55:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-596576 ] NetBSD 1.4.3, a.out, shared modules Message-ID: Bugs item #596576, was opened at 2002-08-17 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596576&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Sobanski (lord-silk) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD 1.4.3, a.out, shared modules Initial Comment: Because of check in configure, it is using on a.out system ld to link shared modules on a.out NetBSD. But it is run with both -Wl,-R and so it won't build any module ending in unusable installation. Had to modify configure to get the package installed correctly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 10:55 Message: Logged In: YES user_id=21627 Could you kindly provide a patch to configure.in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596576&group_id=5470 From noreply@sourceforge.net Wed Sep 4 11:06:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 03:06:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-604465 ] codeop module documentation typo (3.23) Message-ID: Bugs item #604465, was opened at 2002-09-04 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604465&group_id=5470 Category: Documentation Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Lewis Collard (joevs) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: codeop module documentation typo (3.23) Initial Comment: The final example given on the page on the first page of the codeop documentation (section 3.23) reads: try: from codeop import CommandCompiler except ImportError: def CommandCompiler(): from codeop import compile_command return compile_comamnd There is a clear typo on the final line of this example. -- l ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604465&group_id=5470 From noreply@sourceforge.net Wed Sep 4 11:09:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 03:09:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-604467 ] Typo in builtins documentation (2.1) Message-ID: Bugs item #604467, was opened at 2002-09-04 10:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604467&group_id=5470 Category: Documentation Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Lewis Collard (joevs) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Typo in builtins documentation (2.1) Initial Comment: Under section 2.1 (Built-in Functions), the documentation for apply reads: ...the number of arguments is the the length of the tuple. Two "the"s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604467&group_id=5470 From noreply@sourceforge.net Wed Sep 4 12:42:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 04:42:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-601077 ] bug in new execvpe Message-ID: Bugs item #601077, was opened at 2002-08-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: bug in new execvpe Initial Comment: From: "Steve M. Robbins" I think the patch associated with this thread has an unintended consequence. In http://mail.python.org/pipermail/python-dev/2002-August/027229.html Zack pointed out three flaws in the original code: [...] Third, if an error other than the expected one comes back, the loop clobbers the saved exception info and keeps going. Consider the situation where PATH=/bin:/usr/bin, /bin/foobar exists but is not executable by the invoking user, and /usr/bin/foobar does not exist. The exception thrown will be 'No such file or directory', not the expected 'Permission denied'. The patch, as I understand it, changes the behaviour so as to raise the exception "Permission denied" in this case. Consider a similar situation in which both /bin/foobar (not executable by the user) and /usr/bin/foobar (executable by the user) exist. Given the command "foobar", the shell will execute /usr/bin/foobar. If I understand the patch correctly, python will give up when it encounters /bin/foobar and raise the "Permission denied" exception. I believe this just happened to me today. I had a shell script named "gcc" in ~/bin (first on my path) some months back. When I was finished with it, I just did "chmod -x ~/bin/gcc" and forgot about it. Today was the first time since this patch went in that I ran gcc via python (using scipy's weave). Boy was I surprised at the message "unable to execute gcc: Permission denied"! I guess the fix is to save the EPERM exception and keep going in case there is an executable later in the path. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-04 07:42 Message: Logged In: YES user_id=6380 Good point, doko! Done. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-09-04 02:58 Message: Logged In: YES user_id=60903 should be checked in to the 2.1 branch as well. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 12:38 Message: Logged In: YES user_id=6380 Thanks, Zack! Checked in for 2.2 and CVS head. ---------------------------------------------------------------------- Comment By: Zack Weinberg (zackw) Date: 2002-08-31 15:10 Message: Logged In: YES user_id=580015 I've created a patch for this bug. I would like to attach it, but Sourceforge doesn't want to let me do that, so I'll just insert it inline here: =================================================================== Index: Lib/os.py --- Lib/os.py 5 Aug 2002 16:13:24 -0000 1.59 +++ Lib/os.py 31 Aug 2002 19:08:34 -0000 @@ -309,7 +309,7 @@ def execvp(file, args): _execvpe(file, args) def execvpe(file, args, env): - """execv(file, args, env) + """execvpe(file, args, env) Execute the executable file (which is searched for along $PATH) with argument list args and environment env , replacing the @@ -339,14 +339,21 @@ def _execvpe(file, args, env=None): else: envpath = defpath PATH = envpath.split(pathsep) + saved_exc = None + saved_tb = None for dir in PATH: fullname = path.join(dir, file) try: apply(func, (fullname,) + argrest) - except error, (errno, msg): - if errno != ENOENT and errno != ENOTDIR: - raise - raise error, (errno, msg) + except error, e: + tb = sys.exc_info()[2] + if (e.errno != ENOENT and e.errno != ENOTDIR + and saved_exc is None): + saved_exc = e + saved_tb = tb + if saved_exc: + raise error, saved_exc, saved_tb + raise error, e, tb # Change environ to automatically call putenv() if it exists try: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-27 21:06 Message: Logged In: YES user_id=6380 Since I applied Zack's patch to the trunk as well as to the 2.2 maintenance branch, this needs to be fixed in both places. This worked correctly in 2.1 and 2.2 (and in 2.2.1, but I haven't tested that). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601077&group_id=5470 From noreply@sourceforge.net Wed Sep 4 16:05:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 08:05:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-604467 ] Typo in builtins documentation (2.1) Message-ID: Bugs item #604467, was opened at 2002-09-04 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604467&group_id=5470 Category: Documentation Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lewis Collard (joevs) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Typo in builtins documentation (2.1) Initial Comment: Under section 2.1 (Built-in Functions), the documentation for apply reads: ...the number of arguments is the the length of the tuple. Two "the"s. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 10:05 Message: Logged In: YES user_id=80475 Fixed in the 2.2.2 and 2.3 documentation. Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604467&group_id=5470 From noreply@sourceforge.net Wed Sep 4 16:13:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 08:13:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-604465 ] codeop module documentation typo (3.23) Message-ID: Bugs item #604465, was opened at 2002-09-04 05:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604465&group_id=5470 Category: Documentation Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lewis Collard (joevs) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: codeop module documentation typo (3.23) Initial Comment: The final example given on the page on the first page of the codeop documentation (section 3.23) reads: try: from codeop import CommandCompiler except ImportError: def CommandCompiler(): from codeop import compile_command return compile_comamnd There is a clear typo on the final line of this example. -- l ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 10:13 Message: Logged In: YES user_id=80475 Fixed documentation for 2.2.2 and 2.3. Thank you for the clear, accurate bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604465&group_id=5470 From noreply@sourceforge.net Wed Sep 4 16:35:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 08:35:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-604387 ] long list in Pythonwin -> weird text Message-ID: Bugs item #604387, was opened at 2002-09-04 02:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 Category: Windows >Group: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: James Briggs (jbriggs66) >Assigned to: Mark Hammond (mhammond) Summary: long list in Pythonwin -> weird text Initial Comment: Using Pythonwin (build 148) with ActiveState 2.2.1 >>> import sys >>> sys.modules.keys() ['code', 'pywin.framework.cmdline', .... after about 15 lines the output goes weird. Text is mostly stuck on 1st column, some text appears and disappears as the scroll bar is moved. Tried this with Python 2.1 and Pythonwin (build 147 also) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-04 11:35 Message: Logged In: YES user_id=31435 Note that PythonWin isn't part of the core Python project, so marked 3rdParty and assigned to Mark Hammond. I don't see any problems under a DOS box, or under IDLE, so if there is a problem here, it seems unlikely to be in the core. Help Mark by giving more info: which flavor of Windows are you using? Is it a non-US version (French, Japanese, etc)? Is the problem specific to sys.modules.keys(), or is it common across every list that requires more than "about 15 lines" to display?: How wide is your display window? Which font and point size are you using? Etc. As is, I doubt there's enough info here for anyone to help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 From noreply@sourceforge.net Wed Sep 4 17:41:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 09:41:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 20:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mike Carifio (carifio) Assigned to: Nobody/Anonymous (nobody) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 19:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-08 01:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-03 00:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 21:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 21:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 21:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 21:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 21:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Wed Sep 4 17:22:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 09:22:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 11:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 19:22 Message: Logged In: YES user_id=539787 See patch 604600 ---------------------------------------------------------------------- Comment By: Matthias Kirst (mattkirst) Date: 2001-12-10 13:06 Message: Logged In: YES user_id=397984 That's correct when using the command interactively. But when the command is used in an environment where source and destination path come from user interactions over a GUI for instance the programmer won't check for the source and destination path each time the command is called. In my example I had a relative and an absolute path to compare. So I would have had the relative path tracked programmatically. At the end it seemed clearer to me to read the source file out, create an empty destination (open "w+") and write the dump to this file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 12:42 Message: Logged In: YES user_id=6656 To the OP, if you're paying attention: shutil is pretty useless. You might consider using distutils.file_util instead (though I don't know if that suffers from this "problem"). I wanted to do somthing about this before 2.2, sigh... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 19:17 Message: Logged In: YES user_id=6380 I know the Unix 'cp' command tests for this condition, but shouldn't this fall in the category of "don't do that, then" in the Python world? How stupid do we expect the programmer to be? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Wed Sep 4 20:03:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 12:03:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 12:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 21:03 Message: Logged In: YES user_id=89016 import.c 2.207 should have fixed this problem, so I hope we can close this bug now. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 14:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 11:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 11:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 09:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 11:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-02 00:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Wed Sep 4 20:11:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 12:11:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 12:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 21:03 Message: Logged In: YES user_id=89016 import.c 2.207 should have fixed this problem, so I hope we can close this bug now. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 14:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 11:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 11:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 09:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 11:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-02 00:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Wed Sep 4 21:20:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 13:20:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Wed Sep 4 21:37:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 13:37:11 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-403100 ] Multicharacter replacements in PyUnicode_TranslateCharmap Message-ID: Feature Requests item #403100, was opened at 2001-01-04 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=403100&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Multicharacter replacements in PyUnicode_TranslateCharmap Initial Comment: This patch modifies Objects/unicodeobject.c/PyUnicode_TranslateCharmap, so that the error PyErr_SetString(PyExc_NotImplementedError, "1-n mappings are currently not implemented"); no longer occurs. I.e. u"ab".translate({ord(u"a"): u"bbb", ord(u"b"): u"aaa"}) now works. It does this by exponentially reallocating the string, when there is no more available space. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 22:37 Message: Logged In: YES user_id=89016 This is implemented by the PEP 293 patch. Closing the request. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 23:02 Message: Logged In: YES user_id=31435 Changed to Feature Requests, at MvL's request. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-07 14:32 Message: Logged In: YES user_id=38388 Reopened. This should really be marked as feature request but for some reason SF won't let me change the Data Type. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-07 12:09 Message: Logged In: YES user_id=89016 The patch that was checked in changes PyUnicode_DecodeCharmap and PyUnicode_EncodeCharmap, but not PyUnicode_TranslateCharmap, where this functionality is also useful. . (e.g. for u"".translate({ord("<"): u"<", ord(">"): u">"}) ) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-01-06 16:03 Message: Checked in a different patch providing the same functionality. Please see the CVS checking message for details. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-05 19:45 Message: I'll checkin a patch for this tomorrow which implements what I had in mind. The patch doesn't change the performance of the charmap codec. Thanks, -- Marc-Andre ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-01-05 18:07 Message: The problem, that you can't know beforehand how long the result string will be, i.e. if there really will be any 1-n replacements happening. It would be possible to do a loop through the replacement strings and see if there are any that are longer than one character, but even if there are, you don't know if they will really be used. So you have three choices: (1) You either guess how much space you need and reallocate when the space is not enough or (2) you do a dry run of the algorithm once and count how much space you need and do the algorithm a second time and this time use the strings. (3) you can keep the strings in a list and join the list into one string in the end. For the case of 1-1 mapping the following will happen: (1) The first allocation has exactly the right amount of space, there won't be any reallocations, but a size check for every character will be don (which should be only a few assembler instructions). The mapping will have to be accessed for every character in the source string once. (2) There will only be one allocation, but for every character in the source string, the mapping has to be accessed twice, which are calls to Python function, exception handling etc. (3) You have to make as many memory allocations are are parts of the final string that you create, including error handling etc. I think (1) is clearly the fastest method. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-01-04 19:33 Message: I like the idea, but the implementation needs some reworking: the common case is 1-1 mapping so this should be as fast as possible; extra size checks slow things down too much. You can take a different approach, though: leave things as they are and only add a special case for the 1-n which does resizing depending on how many extra chars are inserted. Then as final step, if resizing occurred, call _PyUnicode_Resize() to cut down the allocate buffer to its true size. -- Marc-Andre ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=403100&group_id=5470 From noreply@sourceforge.net Wed Sep 4 21:45:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 13:45:41 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 17:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 22:45 Message: Logged In: YES user_id=89016 String reversing is possible now via extended slices: >>> "spam"[::-1] 'maps' I guess we can close the request. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 05:57 Message: Logged In: YES user_id=31435 Here's an application of (sub)string reversal in dartboard design: http://www.combinatorics.org/Volume_8/PDF/v8i2r4.pdf I'd hate to see Python fall behind in the lucrative dartboard designer market . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 05:22 Message: Logged In: YES user_id=6380 Write a PEP. :-) ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2001-12-18 05:17 Message: Logged In: YES user_id=39733 > Show me one real-life application of reversing a string. Ummm.... easy way to check for palindromes? > This comes from textbook exercises IMO, > and doesn't occur in real life. It may not occur in many serious applications, but there have been occasions where I've simply wanted to reverse a string just for the fun of it really (or just to check quickly what something is backwards). > Adding the method would reduce the > utility of the textbook exercise... Not unless you explicitly said not to use str.reverse... You could argue that doing l = list('something'); l.reverse (); ''.join(l) perhaps is still a bit too easy for a text book. Something more appropriate like for loops and ranges would be suitable for an exercise. I dunno, it just seems like it's the sort of method that should be part of str, and it doesn't seem like the method would be that huge or problematic to implement... If that doesn't convince you, then at least say you'll implement it if I figure out a worthwhile use for it. :)) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 17:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Wed Sep 4 22:59:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 14:59:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-598160 ] import _tkinter python dumps core. Message-ID: Bugs item #598160, was opened at 2002-08-21 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 3 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: import _tkinter python dumps core. Initial Comment: We are trying to build python on a HP-UX 11.00 using gcc 3.1. But when it comes to the stage when it tries to load _tkinter i.e. import _tkinter python dumps core. running gdb on the core file gives us that it get's a segfault on the line Python/import.c:210 i.e if (interp->modules == NULL) and yes, interp is null... any clue how to continue? ---------------------------------------------------------------------- >Comment By: Göran Uddeborg (goeran) Date: 2002-09-04 23:59 Message: Logged In: YES user_id=55884 We don't have any previous GCC, 2.9x-series didn't like HP-UX 11 very much. But to begin with I'll compile GCC 3.2 for it and see if that makes any difference. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 10:53 Message: Logged In: YES user_id=21627 I would recommend to trace the value of _PyThreadState_Current, perhaps by adding printfs every time this variable changes, and is accessed. I think it is impossible to create a thread state that has a NULL interp, so when you find that the thread state is the same all the time, you should then try to find out where ->interp is cleared (do you have watchpoints in gdb on HP-UX?) Somebody might be overwriting memory. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:31 Message: Logged In: YES user_id=6380 Things like this are notoriously hard to debug. Perhaps GCC 3.1 has a bug (it's rather new, and HP-UX is an infrequently used platform for this compiler). Could you try with an older GCC version? I don't think I've seen this report before. Are there problems with any other modules? Does the test suite run successfully? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598160&group_id=5470 From noreply@sourceforge.net Thu Sep 5 00:06:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 16:06:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-604387 ] long list in Pythonwin -> weird text Message-ID: Bugs item #604387, was opened at 2002-09-04 06:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 Category: Windows >Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: James Briggs (jbriggs66) Assigned to: Mark Hammond (mhammond) Summary: long list in Pythonwin -> weird text Initial Comment: Using Pythonwin (build 148) with ActiveState 2.2.1 >>> import sys >>> sys.modules.keys() ['code', 'pywin.framework.cmdline', .... after about 15 lines the output goes weird. Text is mostly stuck on 1st column, some text appears and disappears as the scroll bar is moved. Tried this with Python 2.1 and Pythonwin (build 147 also) ---------------------------------------------------------------------- >Comment By: James Briggs (jbriggs66) Date: 2002-09-04 23:06 Message: Logged In: YES user_id=605472 Yes, I should have mentioned it worked in IDLE and on cthe command line. Currently using Windows 2000 (Sp2). Any very long sequence with enough text seems to cause the problem. Try also: >>> range(1,1000) # will go wierd after 771 >>> s=str(range(1,780)) It seems to be when the total string length gets around 3750 characters. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-04 15:35 Message: Logged In: YES user_id=31435 Note that PythonWin isn't part of the core Python project, so marked 3rdParty and assigned to Mark Hammond. I don't see any problems under a DOS box, or under IDLE, so if there is a problem here, it seems unlikely to be in the core. Help Mark by giving more info: which flavor of Windows are you using? Is it a non-US version (French, Japanese, etc)? Is the problem specific to sys.modules.keys(), or is it common across every list that requires more than "about 15 lines" to display?: How wide is your display window? Which font and point size are you using? Etc. As is, I doubt there's enough info here for anyone to help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 From noreply@sourceforge.net Thu Sep 5 00:20:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 16:20:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-604803 ] pre bug Message-ID: Bugs item #604803, was opened at 2002-09-05 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604803&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Fredrik Lundh (effbot) Summary: pre bug Initial Comment: Hi there, I have an annoying bug with python 2.2 -- a workaround is also appreciated. Thanks. blauw:~/usr/src/lilypond$ cat q.py import pre print pre.sub ('(@)', r'@\1', r"\key c \minor r8 c16 b c8 g as c16 b c8 d | g,4 ") blauw:~/usr/src/lilypond$ python2 q.py Traceback (most recent call last): File "q.py", line 4, in ? print pre.sub ('(@)', r'@\1', r"\key c \minor r8 c16 b c8 g as c16 b c8 d | g,4 ") File "/usr/lib/python2.2/pre.py", line 179, in sub return pattern.sub(repl, string, count) File "/usr/lib/python2.2/pre.py", line 344, in sub return self.subn(repl, string, count)[0] File "/usr/lib/python2.2/pre.py", line 366, in subn repl = pcre_expand(_Dummy, repl) TypeError: 'NoneType' object is not callable blauw:~/usr/src/lilypond$ rpm -q python2 python2-2.2-16 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604803&group_id=5470 From noreply@sourceforge.net Thu Sep 5 01:04:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 17:04:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-604387 ] long list in Pythonwin -> weird text Message-ID: Bugs item #604387, was opened at 2002-09-04 06:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 Category: Windows >Group: 3rd Party Status: Open Resolution: None >Priority: 2 Submitted By: James Briggs (jbriggs66) Assigned to: Mark Hammond (mhammond) Summary: long list in Pythonwin -> weird text Initial Comment: Using Pythonwin (build 148) with ActiveState 2.2.1 >>> import sys >>> sys.modules.keys() ['code', 'pywin.framework.cmdline', .... after about 15 lines the output goes weird. Text is mostly stuck on 1st column, some text appears and disappears as the scroll bar is moved. Tried this with Python 2.1 and Pythonwin (build 147 also) ---------------------------------------------------------------------- >Comment By: James Briggs (jbriggs66) Date: 2002-09-05 00:04 Message: Logged In: YES user_id=605472 Another folloup. All tests were done with the default window size, and full size window on 1024x768. Screen width effects the where you see the Changing to non-fixed size font gets the range(1,000) to work, but the display still goes wierd on the range(1,2000). Fonts sizes seem to make no difference. Fonts used were Fixed width - Courier New 10 pt, Proportional - Arial 10 pt. ---------------------------------------------------------------------- Comment By: James Briggs (jbriggs66) Date: 2002-09-04 23:06 Message: Logged In: YES user_id=605472 Yes, I should have mentioned it worked in IDLE and on cthe command line. Currently using Windows 2000 (Sp2). Any very long sequence with enough text seems to cause the problem. Try also: >>> range(1,1000) # will go wierd after 771 >>> s=str(range(1,780)) It seems to be when the total string length gets around 3750 characters. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-04 15:35 Message: Logged In: YES user_id=31435 Note that PythonWin isn't part of the core Python project, so marked 3rdParty and assigned to Mark Hammond. I don't see any problems under a DOS box, or under IDLE, so if there is a problem here, it seems unlikely to be in the core. Help Mark by giving more info: which flavor of Windows are you using? Is it a non-US version (French, Japanese, etc)? Is the problem specific to sys.modules.keys(), or is it common across every list that requires more than "about 15 lines" to display?: How wide is your display window? Which font and point size are you using? Etc. As is, I doubt there's enough info here for anyone to help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 From noreply@sourceforge.net Thu Sep 5 01:06:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 17:06:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-604387 ] long list in Pythonwin -> weird text Message-ID: Bugs item #604387, was opened at 2002-09-04 06:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 Category: Windows Group: 3rd Party Status: Open Resolution: None Priority: 2 Submitted By: James Briggs (jbriggs66) Assigned to: Mark Hammond (mhammond) Summary: long list in Pythonwin -> weird text Initial Comment: Using Pythonwin (build 148) with ActiveState 2.2.1 >>> import sys >>> sys.modules.keys() ['code', 'pywin.framework.cmdline', .... after about 15 lines the output goes weird. Text is mostly stuck on 1st column, some text appears and disappears as the scroll bar is moved. Tried this with Python 2.1 and Pythonwin (build 147 also) ---------------------------------------------------------------------- >Comment By: James Briggs (jbriggs66) Date: 2002-09-05 00:06 Message: Logged In: YES user_id=605472 Make that - screen width effects what you see, but not when the bug appears. ---------------------------------------------------------------------- Comment By: James Briggs (jbriggs66) Date: 2002-09-05 00:04 Message: Logged In: YES user_id=605472 Another folloup. All tests were done with the default window size, and full size window on 1024x768. Screen width effects the where you see the Changing to non-fixed size font gets the range(1,000) to work, but the display still goes wierd on the range(1,2000). Fonts sizes seem to make no difference. Fonts used were Fixed width - Courier New 10 pt, Proportional - Arial 10 pt. ---------------------------------------------------------------------- Comment By: James Briggs (jbriggs66) Date: 2002-09-04 23:06 Message: Logged In: YES user_id=605472 Yes, I should have mentioned it worked in IDLE and on cthe command line. Currently using Windows 2000 (Sp2). Any very long sequence with enough text seems to cause the problem. Try also: >>> range(1,1000) # will go wierd after 771 >>> s=str(range(1,780)) It seems to be when the total string length gets around 3750 characters. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-04 15:35 Message: Logged In: YES user_id=31435 Note that PythonWin isn't part of the core Python project, so marked 3rdParty and assigned to Mark Hammond. I don't see any problems under a DOS box, or under IDLE, so if there is a problem here, it seems unlikely to be in the core. Help Mark by giving more info: which flavor of Windows are you using? Is it a non-US version (French, Japanese, etc)? Is the problem specific to sys.modules.keys(), or is it common across every list that requires more than "about 15 lines" to display?: How wide is your display window? Which font and point size are you using? Etc. As is, I doubt there's enough info here for anyone to help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604387&group_id=5470 From noreply@sourceforge.net Thu Sep 5 02:20:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 18:20:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-602029 ] smtplib mishandles empty sender Message-ID: Bugs item #602029, was opened at 2002-08-29 13:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Raymond Hettinger (rhettinger) Summary: smtplib mishandles empty sender Initial Comment: If you pass a non-empty string to SMTP.mail(), it gets it right, ie. smtp.mail("gward@python.net") becomes MAIL FROM: But if you pass the empty string, things go badly: smtp.mail("") becomes MAIL FROM: which most SMTP servers should reject. (I only tried one.) The culprit appears to be the "if not m" branch in quoteaddr(). One possible fix: --- smtplib.py 8 Aug 2002 20:19:18 -0000 1.61 +++ smtplib.py 29 Aug 2002 18:52:42 -0000 @@ -173,11 +173,7 @@ m=rfc822.parseaddr(addr)[1] except AttributeError: pass - if not m: - #something weird here.. punt -ddm - return addr - else: - return "<%s>" % m + return "<%s>" % m def quotedata(data): """Quote data for email. Another possible fix: --- smtplib.py 8 Aug 2002 20:19:18 -0000 1.61 +++ smtplib.py 29 Aug 2002 18:53:28 -0000 @@ -168,6 +168,8 @@ Should be able to handle anything rfc822.parseaddr can handle. """ + if addr == "": + return "<>" m=None try: m=rfc822.parseaddr(addr)[1] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:20 Message: Logged In: YES user_id=80475 rfc822.parseaddr() is already finding a problem with an empty address. The real problem in this code block is that the return value upon failure was expected to be None, instead of (None, None) as documented. Fixed for Python 2.3. See smtplib.py revision 1.62. I am reluctant to backport the error correction because it involves a behavioral change to a possibly common case of a blank address. Since this hasn't been a problem until now, I'll forgo the backport. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602029&group_id=5470 From noreply@sourceforge.net Thu Sep 5 02:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 18:45:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Thu Sep 5 14:10:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 06:10:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-605047 ] Tutorial and list comprehension scope Message-ID: Bugs item #605047, was opened at 2002-09-05 14:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tutorial and list comprehension scope Initial Comment: I just made an expensive mistake with a list comprehension: val = mean(vals) bad_vals = sum([val < 0.0 or val > 1.0 for val in vals]) val gets clobbered by the list comprehension, silently messing up my statistics. Shouldn't there be a mention of this behaviour in the tutorial (section 5.1.4, or in the part of section 9 on scope)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 From noreply@sourceforge.net Thu Sep 5 12:31:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 04:31:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-591586 ] Get rid of etype struct Message-ID: Bugs item #591586, was opened at 2002-08-06 17:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Get rid of etype struct Initial Comment: The 'etype' struct in typeobject.c prevents people like David Abrahams and Christian Tismer from defining C-level metatypes that add slots to the end of the type structure. It should be possible for type_new() to place the additional structures after an offset determined by tp_basicsize of the metatype, rather than at a fixed offset. ---------------------------------------------------------------------- >Comment By: Christian Tismer (tismer) Date: 2002-09-05 13:31 Message: Logged In: YES user_id=105700 Hi again, I fixed a minor bug/omission in my patch. Also, the etype struct is now gone. Instead, there is a PyHeaptypeObject definition in object.h which simply can be used in your own extended type definition like this: struct _mytype = { PyHeaptypeObject etype; int field1; PyObject *something; char and_so_on[20]; } But I'm quite convinced that this is not the end of the story. I would like to solve the issue about how to efficiently call object methods from C which might be overridden? I believe we could provide an extension to heap types that handles this automatically. I'm working on a prototype. ciao - chris ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-09-03 20:12 Message: Logged In: YES user_id=105700 Hi Guido, I think I have a solution for this one, see the attached diff. I did what you suggested: Make the adressing of the members dependant from the metatype. The etype struct has lost its members[1] field, to make it easier to extend the structure. Instead, the allocator always adds one to the size, to have the sentinel in place. I did not yet publish the etype stucture, since I didn't find a good name and place for it. Testing was also not very thorow. I just checked that types work from Python and that I can add __slots__ to them. Will re-port this stuff to my Py2.2 Stackless base and try it out as base type for my own C types. ciao - chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470 From noreply@sourceforge.net Thu Sep 5 08:37:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 00:37:19 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Feature Requests item #487331, was opened at 2001-11-30 02:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-09-05 07:37 Message: Logged In: YES user_id=38388 Passed on top Barry. I won't have time for this in the next few weeks. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-06 00:34 Message: Logged In: YES user_id=85984 Marc-André, I apologize for previously misspelling your name a bunch of times. Oops. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 23:58 Message: Logged In: YES user_id=85984 Mark, To answer your question from a couple days ago, my exact requirements are: The ability to produce an rfc2822 compliant "Date" string that corresponds to the current value of 'TZ' in the environment. I'm currently using email.Utils.formatdate() to produce the Date, but this breaks as soon as I set 'TZ' within my application. Setting 'TZ' from within Python is necessary. I don't currently know of a way to get around this problem as the breakage is in the lower level time module. Again, mxDateTime is NOT an option. Whether it integrates nicely with Python and runs on many platforms is not relevant. I'm sure both of these facts are true, but I don't want my application to depend on any external packages. This complicates the installation procedure unnecessarily. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 09:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-12-04 16:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 15:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-12-04 15:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-12-04 15:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 09:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 21:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 20:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-30 20:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 19:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 From noreply@sourceforge.net Thu Sep 5 08:26:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 00:26:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 11:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 3 Submitted By: Paul Boddie (pboddie) >Assigned to: Walter Dörwald (doerwalter) Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-09-05 07:26 Message: Logged In: YES user_id=38388 No time to check; can you do this, Walter ? Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 19:03 Message: Logged In: YES user_id=89016 import.c 2.207 should have fixed this problem, so I hope we can close this bug now. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 13:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 10:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 10:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 08:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 10:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 23:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Thu Sep 5 14:46:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 06:46:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-567607 ] whatsnew explains noargs incorrectly Message-ID: Bugs item #567607, was opened at 2002-06-11 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567607&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: A.M. Kuchling (akuchling) Summary: whatsnew explains noargs incorrectly Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node8.html says that PyArg_NoArgs is deprectated and that ParseTuple should be used instead. I believe that the recommendations should be to use METH_NOARGS instead. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-07-11 15:25 Message: Logged In: YES user_id=11375 I've revised the text, which still mentions ParseTuple, for pre-2.2 compatibility. New text follows. Thanks for pointing this out! \item The \cfunction{PyArg_NoArgs()} macro is now deprecated. Code that uses it should be changed. For Python 2.2 and later, the method definition table can specify the \constant{METH_NOARGS} flag, signalling that there are no arguments, and the argument checking can then be removed. If compatibility with pre-2.2 versions of Python is important, the code could use \code{PyArg_ParseTuple(args, "")} instead, but this will be slower than using \constant{METH_NOARGS}. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=567607&group_id=5470 From noreply@sourceforge.net Thu Sep 5 14:53:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 06:53:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-550364 ] Version number handling Message-ID: Bugs item #550364, was opened at 2002-04-29 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Version number handling Initial Comment: A while ago, Tim Peters mentioned in a check-in message: "Change the version string from "2.2+" to "2.3a0". distutils peels off the first 3 characters of this string in several places, so for as long as they remain "2.2" it confuses the heck out of attempts to build 2.3 stuff using distutils." It's true; distutils does sys.version[:3] in a few places. The attached patch factors this out so it'll be easier to change. (There's also a Python development issue here, namely when the version number gets bumped in the CVS tree.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:53 Message: Logged In: YES user_id=11375 Probably we can just use sys.version_info, since we don't care about 1.5.2 any more. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-25 12:12 Message: Logged In: YES user_id=31392 Do we still care about this patch? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-05-15 16:54 Message: Logged In: YES user_id=11375 Maybe. But I don't know if I still care about 1.5.2. If I don't, then the code can just always use sys.version_info. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 06:51 Message: Logged In: YES user_id=80475 Nice factoring. Would it be more bulletproof to use sys.version_info instead of sys.version[:3]? Perhaps, wrap it in try/except to catch versions before Py2.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470 From noreply@sourceforge.net Thu Sep 5 16:37:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 08:37:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-605109 ] webbrowser.open() fails on Linux Message-ID: Bugs item #605109, was opened at 2002-09-05 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dave Hein (dthein) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open() fails on Linux Initial Comment: webbrowser.open( "http://www.python.org" ) just launches the browser, but without the URL. In other words, the default ("home") page of the browser opens, rather than the URL specified in the call. This fails on Linux. Function works on Win32. I'm using Python 2.2.1, Tk/Tcl 8.4b2, Linux 2.4.9. Web browser is Mozilla 1.0RC3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 From noreply@sourceforge.net Thu Sep 5 16:45:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 08:45:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 12:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: Walter Dörwald (doerwalter) Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-05 17:45 Message: Logged In: YES user_id=89016 It seems to work under Linux, can anyone check it under Windows with non-ascii directory names? > echo >/tmp/foo.py "print 'foo'" > ./python Python 2.3a0 (#12, Sep 4 2002, 22:04:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, imp >>> sys.path.append(u"/tmp") >>> imp.find_module("foo") (, '/tmp/foo.py', ('.py', 'U', 1)) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-09-05 09:26 Message: Logged In: YES user_id=38388 No time to check; can you do this, Walter ? Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 21:03 Message: Logged In: YES user_id=89016 import.c 2.207 should have fixed this problem, so I hope we can close this bug now. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 14:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 11:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 11:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 09:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 11:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-02 00:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Thu Sep 5 18:22:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 10:22:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 12:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: Walter Dörwald (doerwalter) Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-05 19:22 Message: Logged In: YES user_id=89016 It works on Windows 2000 too: Python 2.3a0 (#29, Sep 5 2002, 18:43:40) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os, imp [8623 refs] >>> os.mkdir(u"c:\n\xfcx") [10435 refs] >>> sys.path.append(u"c:\n\xfcx") [10436 refs] >>> open(u"c:\n\xfcx\hurz.py", "wb").write('print "hurz"') [10567 refs] >>> imp.find_module(u"hurz") (, 'c:\n\xfcx\hurz.py', ('.py', 'U', 1)) [10580 refs] >>> The repr() of the file seems a little strange, but looking in the Explorer I see the correct directory name. Using a Unicode character that is outside the Latin-1 range instead \xfc fails in the os.mkdir() call, because this is a problem of the "mbcs" encoding, which returns ?, which is illegal in directory names. On Linux it works with non-ascii directory names too, if the appropriate locale.setlocale is called: >>> import os, sys, imp, locale >>> locale.setlocale(locale.LC_ALL, 'de_DE') >>> os.mkdir(u"/tmp/gürk") >>> open(u"/tmp/gürk/hurz.py", "wb").write("print 'hurz'") >>> sys.path.append(u"/tmp/gürk") >>> imp.find_module(u"hurz") (, '/tmp/g\xfcrk/hurz.py', ('.py', 'U', 1)) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-05 17:45 Message: Logged In: YES user_id=89016 It seems to work under Linux, can anyone check it under Windows with non-ascii directory names? > echo >/tmp/foo.py "print 'foo'" > ./python Python 2.3a0 (#12, Sep 4 2002, 22:04:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, imp >>> sys.path.append(u"/tmp") >>> imp.find_module("foo") (, '/tmp/foo.py', ('.py', 'U', 1)) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-09-05 09:26 Message: Logged In: YES user_id=38388 No time to check; can you do this, Walter ? Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 21:03 Message: Logged In: YES user_id=89016 import.c 2.207 should have fixed this problem, so I hope we can close this bug now. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 14:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 11:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 11:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 09:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 11:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-02 00:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Thu Sep 5 22:08:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 14:08:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-555779 ] import user doesn't work with CGIs Message-ID: Bugs item #555779, was opened at 2002-05-14 03:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555779&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Stephen Hansen (ixokai_) >Assigned to: Neal Norwitz (nnorwitz) Summary: import user doesn't work with CGIs Initial Comment: I'm doing some CGI scripts for a job, and I've made some a series of libraries i'd like them to share-- but I don't wish them to be publically installed into site-packages. The user mechanism seems quite suited to the task of easily modifying sys.path to include a more "private" library directory. Unfortunately, it won't work in this secnario, because there is no $HOME environment variable set when Apache calls the script. Here are a couple small patches to make it work if the scripts are running SUID or with Apache's suEXEC feature. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-05 17:08 Message: Logged In: YES user_id=33168 Checked in as: user.py 1.7, posixpath.py 1.52. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 14:36 Message: Logged In: YES user_id=6380 Looks good to me. Anybody can check this in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555779&group_id=5470 From noreply@sourceforge.net Thu Sep 5 23:33:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 15:33:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-585792 ] Invalid mmap crashes Python interpreter Message-ID: Bugs item #585792, was opened at 2002-07-24 04:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470 >Category: Extension Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: paul rubin (phr) Assigned to: Neal Norwitz (nnorwitz) Summary: Invalid mmap crashes Python interpreter Initial Comment: This is under Red Hat 7.2, Linux kernel 2.4.7. "x" is an empty file, i.e. zero bytes long. import mmap f = open(x,"r+")m = mmap.mmap(f.fileno(), 10) print m[1] Crashes Python with a bus error. Python should catch the bus error signal and raise an appropriate exception that the script can catch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-05 18:33 Message: Logged In: YES user_id=33168 Sorry Martin, I apparently didn't upload the last patch. Feel free to fix the test if you see a problem. Checked in as: Modules/mmapmodule.c: 2.41, 2.35.6.3 Lib/test/test_mmap.py: 1.24, 1.19.8.3 Lib/test/output/test_mmap: 1.9, 1.8.6.1 Misc/NEWS: 1.480, 1.337.2.4.2.34 I backported the fix, since your last message Guido seemed to indicate that we are still supposed to do it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-17 13:09 Message: Logged In: YES user_id=21627 I may be missing something: How precisely does this special-case Windows in the test? Apart from that, the patch is fine. I'm uncertain on backporting it, because I'm uncertain how backporting works at all since the PBF got instantiated. So I'd suggest to mark this as a backport candidate, and let the patch czar decide. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-17 12:08 Message: Logged In: YES user_id=33168 Martin, would you like one last review and test on windows before I check in? Also, should this be backported to 2.2.? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-13 13:39 Message: Logged In: YES user_id=33168 I can't test windows. I've attached a patch which tries to test windows doesn't raise an exception. I also modified the NEWS to state this change affects non-Windows platforms. Tim/Martin, can you test (or at least review the test code) that this works on Windows before I check it in? Or let me know if you want me to check it in. It should be easy to fix if it doesn't work on Windows. Thanks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-12 22:11 Message: Logged In: NO I'd say the following is reasonable: - on mmap object creation, stat the file and check its size against the size arg passed to mmap. Signal an error if the file is smaller than the requested mmap size. - On access, compare the subscript to the mmap object size and signal an error if out of bounds (presumably this is done already) - Figure out if another process can truncate the file while the mmap is alive. If yes, maybe add a method to the mmap object that re-stats the file and makes sure it's still larger than the mmap size. - Add warnings to the mmap documentation that weirdness can result from the file size changing etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 12:31 Message: Logged In: YES user_id=21627 I think we should special-case Windows, then. For the mmapmodule patch proper, nothing needs to be done; for the testsuite test, pass and fail are exactly reversed on Windows (but then, we'd test the implementation of Windows, so skipping that test sounds reasonable as well). With those changes, the patch is fine. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-12 11:59 Message: Logged In: YES user_id=31435 mmap() on WIndows doesn't care if you map more bytes than exist in the file -- if you do, it grows the file to match. """ If an application specifies a size for the file mapping object that is larger than the size of the actual named file on disk, the file on disk is grown to match the specified size of the file mapping object. If the file cannot be grown, this results in a failure to create the file mapping object. GetLastError will return ERROR_DISK_FULL. """ Like so: >>> import mmap >>> import os >>> os.path.getsize('abc.abc') 12L >>> f = file('abc.abc', 'r+') >>> m = mmap.mmap(f.fileno(), 10000) >>> m.close() >>> os.path.getsize('abc.abc') 10000L >>> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-12 11:49 Message: Logged In: YES user_id=33168 That last comment was supposed to be: I don't know how Windows behaves... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-12 11:47 Message: Logged In: YES user_id=33168 I thought the st_size was updated by the code in new_buffersize. It was only the position, so the comment should go. ValueError is fine with me. Should I add an entry to NEWS? New patch attached w/NEWS and test. There is another issue--Windows. I how Windows behaves and I can't test it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 10:45 Message: Logged In: YES user_id=21627 I'd say it is a ValueError if the map size is larger than the file size, instead of silently decreasing the size: Errors should never pass silently, Unless explicitly silenced. On the trick of new_buffersize: I'm not sure I understand what you are referring to: we don't use stdio in mmap at all. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-12 09:30 Message: Logged In: YES user_id=33168 I wasn't sure if I could change the size. For Solaris at least, it seems this is the right thing to do. Is it likely that other systems allow the file size to change? I've forced the size to be the max(size_arg, size_of_file). This has the added benefit of working for writing too. Prior to this patch, writing past the end crashed on Linux. There are 2 comments in the patch: one worrying about the file changing, the other producing a warning message if the size argument is larger than the file. Do we have to worry about the size changing? Should we tell the user what they did? Sorry about the old style diff. I remembered to do the cvs -f diff part, but forgot the -C5. My defaults are unified. New context patch attached. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-12 03:45 Message: Logged In: NO Please don't even think of adding a stat call to every access. The whole idea of mmap is to speed up access by eliminating system calls when you touch the file contents. Checking the file size at map creation is reasonable. Some note should also be added to the mmap doc about possible crashes if the file size changes. >From a Python script writer's viewpoint, the most convenient fix is for Python to catch the bus error signal and inspect the stack to figure out that the trap occurred in the mmap routine, then generate and return an appropriate Python exception. However, doing that is pretty platform-dependent, and attempting it in all the Python ports that support mmap doesn't sound practical. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 03:15 Message: Logged In: YES user_id=21627 Ah, an old-style diff. I assume that goes into mmap_item? I'd rather avoid the stat call on every access, and check the size on map creation. The Solaris man page says this about changing files: If the size of the mapped file changes after the call to mmap() as a result of some other operation on the mapped file, the effect of references to portions of the mapped region that correspond to added or removed portions of the file is unspecified. So it appears that this is a case of "don"t do this, then", and that it atleast won't crash - but we might want to perform a few experiments. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 11:05 Message: Logged In: YES user_id=33168 Martin, could you please review the patch? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-28 11:00 Message: Logged In: YES user_id=33168 Attached is a patch which fixes this problem. I'm not sure this patch it correct nor appropriate. But it stops the crash. I'm hoping some mmap expert can shed some light on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585792&group_id=5470 From noreply@sourceforge.net Fri Sep 6 07:27:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 23:27:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-605436 ] Inconsistency in re docs Message-ID: Bugs item #605436, was opened at 2002-09-06 02:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605436&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in re docs Initial Comment: >From the Library Reference (2.2.1): \b Matches the empty string, but only at the beginning or end of a word. A word is defined as a sequence of alphanumeric characters, so the end of a word is indicated by whitespace or a non-alphanumeric character. Inside a character range, \b represents the backspace character, for compatibility with Python's string literals. Now reality: Python 2.2.1 (#2, Apr 22 2002, 17:53:10) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> t = re.compile(r'\bbag\b') >>> t.search('test bag') <_sre.SRE_Match object at 0x812aad0> >>> t.search('test+bag') <_sre.SRE_Match object at 0x815d528> >>> t.search('test_bag') >>> [ chr(i) for i in xrange(256) if not t.search('test' + chr(i) + 'bag') ] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '_', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'] >>> So the implementation appears to define a word as a sequence of alphanumeric characters or underscores, which means either the documentation, or the library is wrong. Now it happens that this was found while a friend of mine and I were looking to get the exact behavior that is implemented, so I'd prefer it if the documentation were updated to meet the implementation <.8 wink>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605436&group_id=5470 From noreply@sourceforge.net Fri Sep 6 10:49:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 02:49:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-605109 ] webbrowser.open() fails on Linux Message-ID: Bugs item #605109, was opened at 2002-09-05 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dave Hein (dthein) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open() fails on Linux Initial Comment: webbrowser.open( "http://www.python.org" ) just launches the browser, but without the URL. In other words, the default ("home") page of the browser opens, rather than the URL specified in the call. This fails on Linux. Function works on Win32. I'm using Python 2.2.1, Tk/Tcl 8.4b2, Linux 2.4.9. Web browser is Mozilla 1.0RC3. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:49 Message: Logged In: YES user_id=21627 Can you please edit webbrowser.Netscape._remote, to add print cmd before rc = os.system(cmd) Can you also add a print statement into the 'if rc' block? Can you then please report the output of these print statements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 From noreply@sourceforge.net Fri Sep 6 10:53:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 02:53:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 22:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-05 03:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Fri Sep 6 12:27:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 04:27:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-605109 ] webbrowser.open() fails on Linux Message-ID: Bugs item #605109, was opened at 2002-09-05 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dave Hein (dthein) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open() fails on Linux Initial Comment: webbrowser.open( "http://www.python.org" ) just launches the browser, but without the URL. In other words, the default ("home") page of the browser opens, rather than the URL specified in the call. This fails on Linux. Function works on Win32. I'm using Python 2.2.1, Tk/Tcl 8.4b2, Linux 2.4.9. Web browser is Mozilla 1.0RC3. ---------------------------------------------------------------------- >Comment By: Dave Hein (dthein) Date: 2002-09-06 11:27 Message: Logged In: YES user_id=603528 Here is the log of my test: [quote] Python 2.2.1 (#3, Sep 1 2002, 15:04:10) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.open( "http://www.sf.net" ) cmd: "mozilla -raise -remote 'openURL(http://www.sf.net)' >/dev/null 2>&1" rc: 0 >>> [end quote] For completeness, here is the chunk of code with the additional print statements (with [TB] to indicate leading tabs since these postings destroy whitespace): [TB]print "cmd: \" + cmd + "\" #DEBUG [TB]rc = os.system(cmd) [TB]print "rc: " + `rc` #DEBUG [TB]if rc: [TB][TB]import time [TB][TB]os.system("%s &" % self.name) [TB][TB]time.sleep(PROCESS_CREATION_DELAY) [TB][TB]print "before os.system(cmd)" #DEBUG [TB][TB]rc = os.system(cmd) [TB][TB]print "after os.system(cmd)" #DEBUG [TB]return not rc ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 09:49 Message: Logged In: YES user_id=21627 Can you please edit webbrowser.Netscape._remote, to add print cmd before rc = os.system(cmd) Can you also add a print statement into the 'if rc' block? Can you then please report the output of these print statements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 From noreply@sourceforge.net Fri Sep 6 12:39:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 04:39:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-605109 ] webbrowser.open() fails on Linux Message-ID: Bugs item #605109, was opened at 2002-09-05 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dave Hein (dthein) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open() fails on Linux Initial Comment: webbrowser.open( "http://www.python.org" ) just launches the browser, but without the URL. In other words, the default ("home") page of the browser opens, rather than the URL specified in the call. This fails on Linux. Function works on Win32. I'm using Python 2.2.1, Tk/Tcl 8.4b2, Linux 2.4.9. Web browser is Mozilla 1.0RC3. ---------------------------------------------------------------------- >Comment By: Dave Hein (dthein) Date: 2002-09-06 11:39 Message: Logged In: YES user_id=603528 OK, now that I see the command, I found the problem. I had a shell script, "mozilla", in the path that was only taking one argument. (I used this script to invoke mozilla from the command line so that I could easily switch between various test versions) I modified the script to pass in up to 5 arguments. Now webbrowser.open() works as expected. Thanks for the quick follow-up! Sorry for the "user error" bug. This bug can be closed. ---------------------------------------------------------------------- Comment By: Dave Hein (dthein) Date: 2002-09-06 11:27 Message: Logged In: YES user_id=603528 Here is the log of my test: [quote] Python 2.2.1 (#3, Sep 1 2002, 15:04:10) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.open( "http://www.sf.net" ) cmd: "mozilla -raise -remote 'openURL(http://www.sf.net)' >/dev/null 2>&1" rc: 0 >>> [end quote] For completeness, here is the chunk of code with the additional print statements (with [TB] to indicate leading tabs since these postings destroy whitespace): [TB]print "cmd: \" + cmd + "\" #DEBUG [TB]rc = os.system(cmd) [TB]print "rc: " + `rc` #DEBUG [TB]if rc: [TB][TB]import time [TB][TB]os.system("%s &" % self.name) [TB][TB]time.sleep(PROCESS_CREATION_DELAY) [TB][TB]print "before os.system(cmd)" #DEBUG [TB][TB]rc = os.system(cmd) [TB][TB]print "after os.system(cmd)" #DEBUG [TB]return not rc ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 09:49 Message: Logged In: YES user_id=21627 Can you please edit webbrowser.Netscape._remote, to add print cmd before rc = os.system(cmd) Can you also add a print statement into the 'if rc' block? Can you then please report the output of these print statements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 From noreply@sourceforge.net Fri Sep 6 13:40:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 05:40:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-605109 ] webbrowser.open() fails on Linux Message-ID: Bugs item #605109, was opened at 2002-09-05 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 Category: Extension Modules Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dave Hein (dthein) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open() fails on Linux Initial Comment: webbrowser.open( "http://www.python.org" ) just launches the browser, but without the URL. In other words, the default ("home") page of the browser opens, rather than the URL specified in the call. This fails on Linux. Function works on Win32. I'm using Python 2.2.1, Tk/Tcl 8.4b2, Linux 2.4.9. Web browser is Mozilla 1.0RC3. ---------------------------------------------------------------------- Comment By: Dave Hein (dthein) Date: 2002-09-06 13:39 Message: Logged In: YES user_id=603528 OK, now that I see the command, I found the problem. I had a shell script, "mozilla", in the path that was only taking one argument. (I used this script to invoke mozilla from the command line so that I could easily switch between various test versions) I modified the script to pass in up to 5 arguments. Now webbrowser.open() works as expected. Thanks for the quick follow-up! Sorry for the "user error" bug. This bug can be closed. ---------------------------------------------------------------------- Comment By: Dave Hein (dthein) Date: 2002-09-06 13:27 Message: Logged In: YES user_id=603528 Here is the log of my test: [quote] Python 2.2.1 (#3, Sep 1 2002, 15:04:10) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.open( "http://www.sf.net" ) cmd: "mozilla -raise -remote 'openURL(http://www.sf.net)' >/dev/null 2>&1" rc: 0 >>> [end quote] For completeness, here is the chunk of code with the additional print statements (with [TB] to indicate leading tabs since these postings destroy whitespace): [TB]print "cmd: \" + cmd + "\" #DEBUG [TB]rc = os.system(cmd) [TB]print "rc: " + `rc` #DEBUG [TB]if rc: [TB][TB]import time [TB][TB]os.system("%s &" % self.name) [TB][TB]time.sleep(PROCESS_CREATION_DELAY) [TB][TB]print "before os.system(cmd)" #DEBUG [TB][TB]rc = os.system(cmd) [TB][TB]print "after os.system(cmd)" #DEBUG [TB]return not rc ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:49 Message: Logged In: YES user_id=21627 Can you please edit webbrowser.Netscape._remote, to add print cmd before rc = os.system(cmd) Can you also add a print statement into the 'if rc' block? Can you then please report the output of these print statements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605109&group_id=5470 From noreply@sourceforge.net Fri Sep 6 14:30:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 06:30:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-605047 ] Tutorial and list comprehension scope Message-ID: Bugs item #605047, was opened at 2002-09-05 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial and list comprehension scope Initial Comment: I just made an expensive mistake with a list comprehension: val = mean(vals) bad_vals = sum([val < 0.0 or val > 1.0 for val in vals]) val gets clobbered by the list comprehension, silently messing up my statistics. Shouldn't there be a mention of this behaviour in the tutorial (section 5.1.4, or in the part of section 9 on scope)? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 08:30 Message: Logged In: YES user_id=80475 I'll add a note to the tutorial because this has surprised my than one person. Using xbar as a variable name would've avoided the problem, but I digress. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 From noreply@sourceforge.net Fri Sep 6 15:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 07:45:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-605436 ] Inconsistency in re docs Message-ID: Bugs item #605436, was opened at 2002-09-06 01:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605436&group_id=5470 >Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in re docs Initial Comment: >From the Library Reference (2.2.1): \b Matches the empty string, but only at the beginning or end of a word. A word is defined as a sequence of alphanumeric characters, so the end of a word is indicated by whitespace or a non-alphanumeric character. Inside a character range, \b represents the backspace character, for compatibility with Python's string literals. Now reality: Python 2.2.1 (#2, Apr 22 2002, 17:53:10) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> t = re.compile(r'\bbag\b') >>> t.search('test bag') <_sre.SRE_Match object at 0x812aad0> >>> t.search('test+bag') <_sre.SRE_Match object at 0x815d528> >>> t.search('test_bag') >>> [ chr(i) for i in xrange(256) if not t.search('test' + chr(i) + 'bag') ] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '_', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'] >>> So the implementation appears to define a word as a sequence of alphanumeric characters or underscores, which means either the documentation, or the library is wrong. Now it happens that this was found while a friend of mine and I were looking to get the exact behavior that is implemented, so I'd prefer it if the documentation were updated to meet the implementation <.8 wink>. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-06 09:45 Message: Logged In: YES user_id=44345 checked in as libre.tex 1.87 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605436&group_id=5470 From noreply@sourceforge.net Fri Sep 6 19:10:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 11:10:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-605047 ] Tutorial and list comprehension scope Message-ID: Bugs item #605047, was opened at 2002-09-05 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial and list comprehension scope Initial Comment: I just made an expensive mistake with a list comprehension: val = mean(vals) bad_vals = sum([val < 0.0 or val > 1.0 for val in vals]) val gets clobbered by the list comprehension, silently messing up my statistics. Shouldn't there be a mention of this behaviour in the tutorial (section 5.1.4, or in the part of section 9 on scope)? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 13:10 Message: Logged In: YES user_id=80475 Added discussion and example to the tutorial. See tut.tex 1.172 and 1.156.4.1.2.10 Marking bug as fixed and closing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 08:30 Message: Logged In: YES user_id=80475 I'll add a note to the tutorial because this has surprised my than one person. Using xbar as a variable name would've avoided the problem, but I digress. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605047&group_id=5470 From noreply@sourceforge.net Fri Sep 6 19:32:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 11:32:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-605731 ] os.environ does not support __iter__. Message-ID: Bugs item #605731, was opened at 2002-09-06 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ does not support __iter__. Initial Comment: os.environ (on FreeBSD at least) apparently uses UserDict. When bug 448153 was fixed, UserDict lost its __iter__ method, and thus the environ dict became non-iterable. os.environ should either use IterableUserDict or, more likely, dictionary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 From noreply@sourceforge.net Fri Sep 6 19:38:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 11:38:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 13:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 04:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Fri Sep 6 19:41:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 11:41:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 14:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 21:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Fri Sep 6 19:59:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 11:59:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-605731 ] os.environ does not support __iter__. Message-ID: Bugs item #605731, was opened at 2002-09-06 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Raymond Hettinger (rhettinger) Summary: os.environ does not support __iter__. Initial Comment: os.environ (on FreeBSD at least) apparently uses UserDict. When bug 448153 was fixed, UserDict lost its __iter__ method, and thus the environ dict became non-iterable. os.environ should either use IterableUserDict or, more likely, dictionary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 From noreply@sourceforge.net Fri Sep 6 20:10:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 12:10:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-605731 ] os.environ does not support __iter__. Message-ID: Bugs item #605731, was opened at 2002-09-06 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Guido van Rossum (gvanrossum) Summary: os.environ does not support __iter__. Initial Comment: os.environ (on FreeBSD at least) apparently uses UserDict. When bug 448153 was fixed, UserDict lost its __iter__ method, and thus the environ dict became non-iterable. os.environ should either use IterableUserDict or, more likely, dictionary. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:10 Message: Logged In: YES user_id=80475 I can fix this easily enough with a one line change to os.py: - class _Environ(UserDict.UserDict): + class _Environ(UserDict.IterableUserDict): The question is whether the original bug fix, 448153 was the right thing to do. Are more users reasonably relying on UserDict being iterable or are more abusing the non- terable form? Which makes sense for the long run? If you want the simple fix, please re-assign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 From noreply@sourceforge.net Fri Sep 6 20:16:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 12:16:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 13:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 13:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 04:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Fri Sep 6 20:19:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 12:19:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-605731 ] os.environ does not support __iter__. Message-ID: Bugs item #605731, was opened at 2002-09-06 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open >Resolution: Accepted Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Raymond Hettinger (rhettinger) Summary: os.environ does not support __iter__. Initial Comment: os.environ (on FreeBSD at least) apparently uses UserDict. When bug 448153 was fixed, UserDict lost its __iter__ method, and thus the environ dict became non-iterable. os.environ should either use IterableUserDict or, more likely, dictionary. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-06 15:19 Message: Logged In: YES user_id=6380 I don't want to revert the decision on IterableUserDict, it made its way into 2.2 so we're stuck with it anyway. I'm not sure if we can speak about UserDict "lost" its __iter__ method. The __iter__ method was only there in 2.2a1, it was removed in 2.2a2. In 2.1 there were no iterators. So I'm not even sure that this is a bug in os.environ: you never could iterate over os.environ! But I see no harm in making os.environ inherit from IterableUserDict. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 15:10 Message: Logged In: YES user_id=80475 I can fix this easily enough with a one line change to os.py: - class _Environ(UserDict.UserDict): + class _Environ(UserDict.IterableUserDict): The question is whether the original bug fix, 448153 was the right thing to do. Are more users reasonably relying on UserDict being iterable or are more abusing the non- terable form? Which makes sense for the long run? If you want the simple fix, please re-assign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 From noreply@sourceforge.net Fri Sep 6 20:37:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 12:37:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-605731 ] os.environ does not support __iter__. Message-ID: Bugs item #605731, was opened at 2002-09-06 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Raymond Hettinger (rhettinger) Summary: os.environ does not support __iter__. Initial Comment: os.environ (on FreeBSD at least) apparently uses UserDict. When bug 448153 was fixed, UserDict lost its __iter__ method, and thus the environ dict became non-iterable. os.environ should either use IterableUserDict or, more likely, dictionary. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:37 Message: Logged In: YES user_id=80475 Checked in as os.py 1.61 and 1.50.8.5. Marking as fixed and closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-06 14:19 Message: Logged In: YES user_id=6380 I don't want to revert the decision on IterableUserDict, it made its way into 2.2 so we're stuck with it anyway. I'm not sure if we can speak about UserDict "lost" its __iter__ method. The __iter__ method was only there in 2.2a1, it was removed in 2.2a2. In 2.1 there were no iterators. So I'm not even sure that this is a bug in os.environ: you never could iterate over os.environ! But I see no harm in making os.environ inherit from IterableUserDict. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:10 Message: Logged In: YES user_id=80475 I can fix this easily enough with a one line change to os.py: - class _Environ(UserDict.UserDict): + class _Environ(UserDict.IterableUserDict): The question is whether the original bug fix, 448153 was the right thing to do. Are more users reasonably relying on UserDict being iterable or are more abusing the non- terable form? Which makes sense for the long run? If you want the simple fix, please re-assign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605731&group_id=5470 From noreply@sourceforge.net Fri Sep 6 21:45:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 13:45:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-605818 ] python-mode.el replaces function on f1 Message-ID: Bugs item #605818, was opened at 2002-09-06 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Toneby (toneby) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el replaces function on f1 Initial Comment: I've customized my global-keymap to save on F1, but python-mode overrides this and opens help. You should check if F1 is bound to something other than default, if it is you shouldn't touch it. The other keys are OK, since they start with C-c which is the keycombo modespecific keys are "supposed" to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 From noreply@sourceforge.net Fri Sep 6 22:54:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 14:54:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-605818 ] python-mode.el replaces function on f1 Message-ID: Bugs item #605818, was opened at 2002-09-06 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Toneby (toneby) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode.el replaces function on f1 Initial Comment: I've customized my global-keymap to save on F1, but python-mode overrides this and opens help. You should check if F1 is bound to something other than default, if it is you shouldn't touch it. The other keys are OK, since they start with C-c which is the keycombo modespecific keys are "supposed" to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:18:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:18:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-597604 ] import cycle in distutils Message-ID: Bugs item #597604, was opened at 2002-08-20 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470 Category: Distutils >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Jeremy Hylton (jhylton) Summary: import cycle in distutils Initial Comment: There is a import cycle in distutils which causes 4Suite's setup.py to fail. Here's the reproducible, using 2.3a0 from CVS (latest updated on 18 Aug) % python Python 2.3a0 (#3, Aug 19 2002, 01:46:45) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import dist Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/distutils/dist.py", line 19, in ? from distutils.core import DEBUG File "/usr/local/lib/python2.3/distutils/core.py", line 24, in ? from distutils.dist import Distribution ImportError: cannot import name Distribution >>> However, I *can* do the following % python Python 2.3a0 (#3, Aug 19 2002, 01:46:45) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import core >>> from distutils import dist >>> This doesn't exist in Python 2.2. The cycle is obvious -- 'dist' imports 'core' imports DEBUG from 'dist'. I tried replacing things with from distutils import core and using core.DEBUG instead of DEBUG, but that caused a problem with Python's install. Hence, no patch included. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:18 Message: Logged In: YES user_id=33168 Jeremy, it looks like this was introduced with your change on 04-Jun-02. If dist.py:19 (from distutils.core import DEBUG) is moved down after the Distribution class, I think this problem would be fixed. Can also move the import into the 3 methods where it's used. DEBUG is used in 3 Distribution methods: parse_config_files, get_command_obj, and _set_command_options. Jeremy, if this is a reasonable change, assign back to me and let me know how best to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:20:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:20:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-594833 ] python-mode.el disables raw_input() Message-ID: Bugs item #594833, was opened at 2002-08-13 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kow Kuroda (kowk) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode.el disables raw_input() Initial Comment: Hi, I'm not sure if this is a bug. I just wanted to report a problem with my emacs environment using python-mode. With the current version of python-mode.el with Python 2.1, 2.2, 2.2.1, I always get EOFError: EOF when reading a line at the line I call raw_input() function. How to get this work in emacs? By the way, the same code doesn't raise this error with vim. Thanks in advance. Kow ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:23:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:23:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 18:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 15:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 17:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 17:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 12:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 17:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 17:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:29:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:29:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-569668 ] LINKCC incorrectly set Message-ID: Bugs item #569668, was opened at 2002-06-16 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dr Leonid A Timochouk (cardou) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC incorrectly set Initial Comment: I was building Python 2.2.1 on Debian/GNU Linux 3.0 (testing pre-release) with gcc and g++ of version 3.0.4, using --with-cxx=g++ configure option. Then linking of the "python" executable fails due to an unresolved symbol (__gxx_personality_v0) in Modules/ccpython.o, because linking is still done with gcc: LINKCC is set to gcc ($CC) by configure, rather than to g++ ($CXX). The configure script attempts to determine the value of LINKCC and sets it to $CC if the latter can successfully link the simplest program "int main(){return 0;}" which was compiled with $CXX. In this case, linking apparently succeeds, setting LINKCC to $CC. Yet linking of Modules/ccpython.o with $CC fails, probably because Modules/ccpython.c is slightly more complex than the above configuration test, hence an extra unresolved symbol generated by g++. I am not sure how the correct value of LINKCC can be determined at config time without unnecessarily using $CXX all the time when it is available. Maybe the makefile should be modified so it always starts from $CC and falls through to $CXX if the former fails? Sincerely, Dr. Leonid Timochouk Computing Laboratory University of Kent at Canterbury England ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:29 Message: Logged In: YES user_id=33168 I believe there were some changes made which should fix this problem. Can you try the latest CVS for the 2.2 branch or 2.3? cvs update -r release22-maint will get the 2.2.1+ version (what will become 2.2.2). Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:45:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:45:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees Message-ID: Bugs item #534669, was opened at 2002-03-25 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: remember to sync trees Initial Comment: There are various fixes hitting the trunk that I'm not considering for 2.2.1 that should probably be considered for 2.2.2 if that ever happens. Conversely there may be a few things I've fixed in the 22-maint branch that haven't been fixed on the trunk. Don't forget these. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:45 Message: Logged In: YES user_id=33168 Michael, do you still want this kept open? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-05 04:58 Message: Logged In: YES user_id=6656 By looking at CVS logs? I don't think there were very many in fact (making StringIO work in --disable-unicode builds is the only one I can actually remember). I wasn't actually expecting *you* to do it at all -- I was going to do a log scan after 2.2.1 was done with (there's a reason I assigned this to myself). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 12:01 Message: Logged In: YES user_id=6380 How do I know what you fixed on the branch that should be moved to the trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:52:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:52:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex Message-ID: Bugs item #531355, was opened at 2002-03-18 09:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Arthur Siegel (aj_siegel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: surprise overriding __radd__ in subclass of complex Initial Comment: I had presented this on tutor and python-list: class Complex(complex): def __mul__(self,other): other=Complex(other) t = complex.__mul__(self,other) return Complex(t.real,t.imag) __rmul__ = __mul__ def __add__(self,other): other=Complex(other) return Complex(self.real.__add__ (other.real),self.imag.__add__(other.imag)) __radd__ = __add__ Then: print type(Complex(5,4) * 7) >> print type(7 * Complex(5,4)) >> print type(Complex(5,4) + 7) >> But: print type(7 + Complex(5,4)) >> Danny Yoo, after looking into it pretty deeply - and going to the docs and source gace me this advice. "In any case, this is definitely a bug in the documentation. Arthur, bring it up on comp.lang.python and Sourceforge again. Someone should really look at your example, since it does seem serious... if not a little obscure. *grin* " ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:52 Message: Logged In: YES user_id=33168 Guido, Fred, is there anything to be done or should this be closed? ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-25 10:20 Message: Logged In: YES user_id=248775 Knew I'd embarass myself soon enough in this company. Found the __truediv__ answer on the train into work. Came here hoping to catch it, before you caught me. Too late. Thanks again - oops for the false alarm. Art ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-25 10:13 Message: Logged In: YES user_id=6380 If you want to override division in a complex subclass, you should define both __truediv__ and __div__, as well as __rtruediv__ and __rdiv__. You can do this by saying __truediv__ = __div__, of course. ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-24 20:11 Message: Logged In: YES user_id=248775 Have just re-read my submission - and in addition to my usual quota of typos I see I left out something that could confuse what I am trying to bring to your attention. The gist, I am sure you will see, is that type(a/b), where a and b are of a class derived from complex, will change based on whether from __future__ import division is or is not called. And I am assuming that behavior is unanticipated. And I assuming there is no reason to submit this a a bug report separate from this thread. Art ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-24 19:24 Message: Logged In: YES user_id=248775 Guido - Thanks for your attention to my report. Another bit of suprise with operator overriding in a subclass of complex: from __future__ import division class Complex(complex): def __div__(self,other): t=complex.__div__(self,other) return Complex(t.real,t.imag) a=Complex(5,4) b=Complex(1,7) >> But: everything the same *without* calling from __future__ import division print type(a/b) >> Based your analysis of the previous issue(which I follow only in broad outline), I have a sense of what's happening. My general sense, though, is that this issue is in some sense more of a problem than the other. Don't think anyone will expect a change in behavior here based on the from __future__ call. Not that subbing complex is a common pursuit - but couldn't this actually break working code in a very unanticpated way, eventually. Obviously not a big issue if the other changes you see happening with complex coercian kick in first, and in fact those changes - as I suspect - would prevent a different return type based on which way int/int is toggled. Art ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 22:18 Message: Logged In: YES user_id=6380 It seems that * is the exception -- all other operators (+, -, /, **) return the type of the left operand. It gets even weirder if we change the left operand from 7 to 7.0 -- then * is no longer an exception and returns a complex like all other operators! The weirdness is in int_mul. If the right argument is not an int but a sequence that implements the sq_repeat slot, it invokes that. But if you create a class that defines __mul__, that implements the sequence repeat slot! (Python doesn't know if you intend to implement a seqence or a number, when you define a __mul__ method, so it maps both the nb_multiply and the sq_repeat slots to the __mul__ method). So 7 + Complex() takes the path through int_mul that calls the Complex.__mul__ , and that's why you get a Complex value back. Floats can't be used in the sequence repeat operator, so its multiply is "normal". But wait...! There's another mystery. Ints don't know how to add themselves to complex numbers! So why wouldn't 7+Complex() use the normal pattern of (a) try the left operand, (b) if that returns NotImplemented, try the right operand? The answer is that complex numbers implement coercion! And in that case, step (b) is modified to (b) ask either operand to perform a coercion, and if it succeeds, ask the left operand of the resulting coerced pair to perform the operation. So complex coerces the int to a plain complex, and then invokes the plain complex's add/mul/etc. operation. Solution: add the following to your Complex class: def __coerce__(self, other): x = complex.__coerce__(self, other) if x is NotImplemented: return x a, b = x return Complex(a), Complex(b) I don't think I want to do anything to fix this, although I think I'll pass it on to Fred for documentation (not that I expect him to be in a hurry to fix it either, given the subtlety of the issues). In the long run, I think complex should stop using coercion and start behaving like a "new-style" number like all the other numeric types. That should fix the second mystery. Also, in the long run, the sq_repeat and sq_concat slots should be deprecated and instead sequences should implement multiply and add operations. Then the funny business in int_mul could be taken out and the first mystery would disappear. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-18 09:49 Message: Logged In: YES user_id=6380 You're right, something's weird. I'll add this to my list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470 From noreply@sourceforge.net Fri Sep 6 23:54:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 15:54:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash Message-ID: Bugs item #529750, was opened at 2002-03-13 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam M. Fass (afass) Assigned to: Nobody/Anonymous (nobody) Summary: Circular reference makes Py_Init crash Initial Comment: Call Py_Initialize(), create two objects that reference each other, then call Py_Finalize() and then Py_Intialize() again. This crashes Python with the following error message: Fatal Python error: UNREF invalid object The documentation on Py_Finalize() mentions that circular references will cause memory leaks, but it does not mention this behavior. Platform info: * Windows XP * Visual C++ 6.0 * Python 2.2 ------------------------------ #include "Python.h" int main(int argc, char* argv[]) { char *code1 = "class TestClass:\n\ti = 3\nt1 = TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = t1"; Py_Initialize(); PyRun_SimpleString(code1); Py_Finalize(); Py_Initialize(); Py_Finalize(); } ------------------------------ The string "code1" contains this python code: class TestClass: i = 3 t1 = TestClass() t2 = TestClass() t1.t = t2 t2.t = t1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:54 Message: Logged In: YES user_id=33168 Adam, do you still have this problem, with 2.2.1+? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 13:44 Message: Logged In: YES user_id=35752 I can't reproduce this on Linux with the latest CVS code. I tried with and without Py_DEBUG defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 From noreply@sourceforge.net Sat Sep 7 00:03:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 16:03:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-523995 ] PDB single steps list comprehensions Message-ID: Bugs item #523995, was opened at 2002-02-28 13:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Skip Montanaro (montanaro) Summary: PDB single steps list comprehensions Initial Comment: Within PDB you cannot 'n'ext over a list comprehension: instead you step through each iteration. In some cases this is quite painful, since the comprehension may have several hundred elements. For example, def doit(): foo = [ 2 * x for x in range(100) ] print foo requires you to either step through all 100 iterations of the comprehension, or set a temporary breakpoint on the line after the comprehension. My expectation would be that 'n'ext would execute the comprehension and move on to the next line. If this isn't a bug, and is working by design, then I'd like to suggest a command that allows you to fully execute comprehensions. I've seen this with versions 2.0 -- 2.2 on several platforms. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 19:03 Message: Logged In: YES user_id=33168 Skip did you fix this a while back? Or do you know if Michael fixed this with the SET_LINENO changes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 From noreply@sourceforge.net Sat Sep 7 00:10:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 16:10:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 19:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 15:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 14:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 21:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Sat Sep 7 00:15:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 16:15:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-484994 ] bugs in Tix.py ListNoteBook PanedWindow Message-ID: Bugs item #484994, was opened at 2001-11-23 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Nobody/Anonymous (nobody) Summary: bugs in Tix.py ListNoteBook PanedWindow Initial Comment: Python 2.2b2 Tix.py 1) class ListNoteBook, __init__ method calls base class __init__ method with "tixDirList" instead of "tixListNoteBook" 2) class PanedWindow, panes method, does not split the string returned from self.tk.call(self._w, 'panes') patch also adds: access to the paned window in ListNoteBook class dummyPanedWindow to support above paneconfigure methods to PanedWindow pageConfigure methods to NoteBook and ListNoteBook page and pages methods to ListNoteBook I am attaching the pathched file as well as the following diff ################ 1044c1044,1046 < TixWidget.__init__(self, master, 'tixDirList', ['options'], cnf, kw) --- > TixWidget.__init__(self, master, 'tixListNoteBook', ['options'], cnf, kw) > self.subwidget_list['pane'] = _dummyPanedWindow(self, 'pane', > destroy_physically=0) 1048d1049 < 1054a1056,1070 > def page(self, name): > return self.subwidget(name) > > def pages(self): > # Can't call subwidgets_all directly because we don't want .nbframe > names = self.tk.split(self.tk.call (self._w, 'pages')) > ret = [] > for x in names: > ret.append(self.subwidget(x)) > return ret > > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1099a1116,1119 > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1162c1182 < names = self.tk.call(self._w, 'panes') --- > names = self.tk.split(self.tk.call (self._w, 'panes')) 1167a1188,1191 > def paneconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'paneconfigure', name) + self._options(kw)) > 1571a1596,1599 > TixSubWidget.__init__(self, master, name, destroy_physically) > > class _dummyPanedWindow(PanedWindow, TixSubWidget): > def __init__(self, master, name, destroy_physically=1): ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 19:15 Message: Logged In: YES user_id=33168 Bob are you able to provide a patch? Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-29 04:43 Message: Logged In: YES user_id=21627 The current revision of Tix.py is 1.9; it is available from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/python/python/dist/src/Lib/lib-tk/Tix.py?rev=1.9&content-type=text/plain It would be nice if you could regenerate the patch for the current version of Tix.py, so that it could get included into Python 2.3. ---------------------------------------------------------------------- Comment By: Robert Roy (rjroy) Date: 2001-12-09 21:34 Message: Logged In: YES user_id=352797 Thanks for reviewing my submission. I will make sure to do a context diff next time I submit something. The pages method that I added is applied to the listNoteBook class not the tixPanedWindow class. It is inherited from the vstack base class. Where can I find the later version? Do I have to get them from the source tree? Bob Roy. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-12-09 18:36 Message: Logged In: YES user_id=33229 The first part of the patch was a definite bug, but your diffs are against Tix.py 1.5, and the bug is fixed in the current version 1.6. (I've also submitted a new version (1.7?) to the patch queue). You're right about the splitlist, but the next part of the patch is partly wrong: there is no 'pages' method to the tixPanedWindow. The methods of the class in Tcl Tix are: add delete forget manage panecget paneconfigure panes setsize I appreciate your help on getting the PanedWindow implementation complete. Could I ask you to check the Tcl Tix documentation and code carefully and resubmit this patch against 1.7 when it comes out, perhaps with some of the other missing methods as well? To speed things up for Martin, it could be best to use a context diff diff -c and upload the result as a file. Mike Clarkson ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 11:15 Message: Logged In: YES user_id=3066 I've asked Mike Clarkson (Tix.py guru) to take a look at this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 From noreply@sourceforge.net Sat Sep 7 00:35:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 16:35:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex Message-ID: Bugs item #531355, was opened at 2002-03-18 09:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Arthur Siegel (aj_siegel) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: surprise overriding __radd__ in subclass of complex Initial Comment: I had presented this on tutor and python-list: class Complex(complex): def __mul__(self,other): other=Complex(other) t = complex.__mul__(self,other) return Complex(t.real,t.imag) __rmul__ = __mul__ def __add__(self,other): other=Complex(other) return Complex(self.real.__add__ (other.real),self.imag.__add__(other.imag)) __radd__ = __add__ Then: print type(Complex(5,4) * 7) >> print type(7 * Complex(5,4)) >> print type(Complex(5,4) + 7) >> But: print type(7 + Complex(5,4)) >> Danny Yoo, after looking into it pretty deeply - and going to the docs and source gace me this advice. "In any case, this is definitely a bug in the documentation. Arthur, bring it up on comp.lang.python and Sourceforge again. Someone should really look at your example, since it does seem serious... if not a little obscure. *grin* " ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-06 19:35 Message: Logged In: YES user_id=6380 This is fixed in 2.3. Can't remember if it was fixed in 2.2 branch, don't care. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:52 Message: Logged In: YES user_id=33168 Guido, Fred, is there anything to be done or should this be closed? ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-25 10:20 Message: Logged In: YES user_id=248775 Knew I'd embarass myself soon enough in this company. Found the __truediv__ answer on the train into work. Came here hoping to catch it, before you caught me. Too late. Thanks again - oops for the false alarm. Art ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-25 10:13 Message: Logged In: YES user_id=6380 If you want to override division in a complex subclass, you should define both __truediv__ and __div__, as well as __rtruediv__ and __rdiv__. You can do this by saying __truediv__ = __div__, of course. ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-24 20:11 Message: Logged In: YES user_id=248775 Have just re-read my submission - and in addition to my usual quota of typos I see I left out something that could confuse what I am trying to bring to your attention. The gist, I am sure you will see, is that type(a/b), where a and b are of a class derived from complex, will change based on whether from __future__ import division is or is not called. And I am assuming that behavior is unanticipated. And I assuming there is no reason to submit this a a bug report separate from this thread. Art ---------------------------------------------------------------------- Comment By: Arthur Siegel (aj_siegel) Date: 2002-03-24 19:24 Message: Logged In: YES user_id=248775 Guido - Thanks for your attention to my report. Another bit of suprise with operator overriding in a subclass of complex: from __future__ import division class Complex(complex): def __div__(self,other): t=complex.__div__(self,other) return Complex(t.real,t.imag) a=Complex(5,4) b=Complex(1,7) >> But: everything the same *without* calling from __future__ import division print type(a/b) >> Based your analysis of the previous issue(which I follow only in broad outline), I have a sense of what's happening. My general sense, though, is that this issue is in some sense more of a problem than the other. Don't think anyone will expect a change in behavior here based on the from __future__ call. Not that subbing complex is a common pursuit - but couldn't this actually break working code in a very unanticpated way, eventually. Obviously not a big issue if the other changes you see happening with complex coercian kick in first, and in fact those changes - as I suspect - would prevent a different return type based on which way int/int is toggled. Art ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 22:18 Message: Logged In: YES user_id=6380 It seems that * is the exception -- all other operators (+, -, /, **) return the type of the left operand. It gets even weirder if we change the left operand from 7 to 7.0 -- then * is no longer an exception and returns a complex like all other operators! The weirdness is in int_mul. If the right argument is not an int but a sequence that implements the sq_repeat slot, it invokes that. But if you create a class that defines __mul__, that implements the sequence repeat slot! (Python doesn't know if you intend to implement a seqence or a number, when you define a __mul__ method, so it maps both the nb_multiply and the sq_repeat slots to the __mul__ method). So 7 + Complex() takes the path through int_mul that calls the Complex.__mul__ , and that's why you get a Complex value back. Floats can't be used in the sequence repeat operator, so its multiply is "normal". But wait...! There's another mystery. Ints don't know how to add themselves to complex numbers! So why wouldn't 7+Complex() use the normal pattern of (a) try the left operand, (b) if that returns NotImplemented, try the right operand? The answer is that complex numbers implement coercion! And in that case, step (b) is modified to (b) ask either operand to perform a coercion, and if it succeeds, ask the left operand of the resulting coerced pair to perform the operation. So complex coerces the int to a plain complex, and then invokes the plain complex's add/mul/etc. operation. Solution: add the following to your Complex class: def __coerce__(self, other): x = complex.__coerce__(self, other) if x is NotImplemented: return x a, b = x return Complex(a), Complex(b) I don't think I want to do anything to fix this, although I think I'll pass it on to Fred for documentation (not that I expect him to be in a hurry to fix it either, given the subtlety of the issues). In the long run, I think complex should stop using coercion and start behaving like a "new-style" number like all the other numeric types. That should fix the second mystery. Also, in the long run, the sq_repeat and sq_concat slots should be deprecated and instead sequences should implement multiply and add operations. Then the funny business in int_mul could be taken out and the first mystery would disappear. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-18 09:49 Message: Logged In: YES user_id=6380 You're right, something's weird. I'll add this to my list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470 From noreply@sourceforge.net Sat Sep 7 01:20:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 17:20:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 12:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 18:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 16:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 16:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 13:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 15:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 15:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 10:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 15:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 15:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply@sourceforge.net Sat Sep 7 03:37:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 19:37:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-523995 ] PDB single steps list comprehensions Message-ID: Bugs item #523995, was opened at 2002-02-28 12:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Category: Demos and Tools Group: Python 2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Skip Montanaro (montanaro) Summary: PDB single steps list comprehensions Initial Comment: Within PDB you cannot 'n'ext over a list comprehension: instead you step through each iteration. In some cases this is quite painful, since the comprehension may have several hundred elements. For example, def doit(): foo = [ 2 * x for x in range(100) ] print foo requires you to either step through all 100 iterations of the comprehension, or set a temporary breakpoint on the line after the comprehension. My expectation would be that 'n'ext would execute the comprehension and move on to the next line. If this isn't a bug, and is working by design, then I'd like to suggest a command that allows you to fully execute comprehensions. I've seen this with versions 2.0 -- 2.2 on several platforms. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-06 21:37 Message: Logged In: YES user_id=44345 Yes, thanks for reporting it, but it is fixed in CVS. Note no breaks after executing 'n'. >>> import doit >>> import pdb >>> pdb.run("doit.doit()") > (1)?() (Pdb) n [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182, 184, 186, 188, 190, 192, 194, 196, 198] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:03 Message: Logged In: YES user_id=33168 Skip did you fix this a while back? Or do you know if Michael fixed this with the SET_LINENO changes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:09:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:09:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-606216 ] PyObject_AsWriteBuffer prototype is wron Message-ID: Bugs item #606216, was opened at 2002-09-07 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyObject_AsWriteBuffer prototype is wron Initial Comment: http://www.python.org/doc/current/api/abstract-buffer.html says this: int PyObject_AsWriteBuffer(PyObject *obj, const char **buffer, int *buffer_len) but that's mostly a copy of AsReadBuffer. The actual prototype (python 2.2) is this: int PyObject_AsWriteBuffer(PyObject *obj, void **buffer, int *buffer_len) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:10:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:10:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-606216 ] PyObject_AsWriteBuffer prototype is typo Message-ID: Bugs item #606216, was opened at 2002-09-07 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Drew Perttula (drewp) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: PyObject_AsWriteBuffer prototype is typo Initial Comment: http://www.python.org/doc/current/api/abstract-buffer.html says this: int PyObject_AsWriteBuffer(PyObject *obj, const char **buffer, int *buffer_len) but that's mostly a copy of AsReadBuffer. The actual prototype (python 2.2) is this: int PyObject_AsWriteBuffer(PyObject *obj, void **buffer, int *buffer_len) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:43:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:43:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-606216 ] PyObject_AsWriteBuffer prototype is typo Message-ID: Bugs item #606216, was opened at 2002-09-07 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Drew Perttula (drewp) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyObject_AsWriteBuffer prototype is typo Initial Comment: http://www.python.org/doc/current/api/abstract-buffer.html says this: int PyObject_AsWriteBuffer(PyObject *obj, const char **buffer, int *buffer_len) but that's mostly a copy of AsReadBuffer. The actual prototype (python 2.2) is this: int PyObject_AsWriteBuffer(PyObject *obj, void **buffer, int *buffer_len) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:43 Message: Logged In: YES user_id=80475 Fixed docs. See abstract.tex 1.8.6.7 and 1.19 Marking as fixed and closing bug. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606216&group_id=5470 From noreply@sourceforge.net Sun Sep 8 09:21:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 01:21:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-606250 ] python-mode kills arrow in gdb (gud.el) Message-ID: Bugs item #606250, was opened at 2002-09-08 08:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode kills arrow in gdb (gud.el) Initial Comment: [ forwarded from http://bugs.debian.org/159628 ] missing proper category ... Once python-mode.el has been loaded, all GDB buffers stop showing the little arrow that lives in the "fringe" on the left side of an emacs21 frame. To be specific, the arrow appears and then disappears right away, each time a 'step' or 'next' command is run. I traced the problem down to the unconditional hooking of 'comint-output-filter-functions, python-mode.el line 3472 to be exact: (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file) I haven't tested it fully, but I've found that if I take this line out, GDB can show its arrow once more. There is code in python-mode.el to insert this hook in a buffer-local fashion only in the '*Python*' buffer.. maybe that should be reviewed and used instead of this global hook? (took forever to figure out it was python-mode causing the problem..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 From noreply@sourceforge.net Sun Sep 8 09:24:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 01:24:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-606251 ] elisp: doesn't recognize comment-syntax Message-ID: Bugs item #606251, was opened at 2002-09-08 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: elisp: doesn't recognize comment-syntax Initial Comment: [forwarded from http://bugs.debian.org/159630] It would be awfully nice if python-mode.el knew about python comment syntax and told emacs about it, so that the M-q fill-paragraph command that formats comment blocks so nicely in C and Perl modes would do the right thing. As it stands, M-q in the middle of the comment block on something like this:.. def func(): blah = 2 # this is a comment # this is also a comment foo = 3 jams the entire function into one line, statements and comments and all. I'd really like it to identify the comments, set the region around them, do a normal paragraph-fill (with the fill-prefix set to the existing indentation), then restore the region. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 From noreply@sourceforge.net Sun Sep 8 09:39:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 01:39:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-606254 ] py-electric-colon & delete-selection-mod Message-ID: Bugs item #606254, was opened at 2002-09-08 08:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: py-electric-colon & delete-selection-mod Initial Comment: python-elisp: py-electric-colon doesn't honour delete-selection mode [forwarded from http://bugs.debian.org/158811] With emacs 21 in delete-selection mode, typing a character when the region is active is supposed to replace the contents of the region. In python-mode, this doesn't work if the colon character is typed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 From noreply@sourceforge.net Sun Sep 8 10:47:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 02:47:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-21 00:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Invalid Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # 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(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-09-08 09:47 Message: Logged In: YES user_id=60903 Attached is a patch, which changes _tryorder to try the text-based browsers first in absence of the DISPLAY environment. No change for the case where BROWSER is set. Should the module take care of the case, where BROWSER is set to i.e. mozilla and you're running on the console? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 14:37 Message: Logged In: YES user_id=3066 I'll make a note here so I don't forget: I should add galeon and skipstone to the list of known browsers. (Both are based on the Mozilla engine.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 14:28 Message: Logged In: YES user_id=3066 Sounds painful, but I can't look at it right now (though I don't think it will be hard to fix). I've bumped the priority up and set the tracker fields to reasonable values for this report. I'll need to be careful about testing this with & without $BROWSER both on a console and under X. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-09 13:57 Message: Logged In: YES user_id=6380 If your real complaint is that you are not running under X yet it tries to start Mozilla, please say so. If that's the case, we have to figure out where the bug is. reopening and assigning to Fred Drake -- I don't follow the login in the module and the use of the _tryorder and _browsers variable is not documented very well. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-09 10:23 Message: Logged In: NO But it is the other way around. Earlier you have: if os.environ.get("TERM") or os.environ.get("DISPLAY"): _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m") So _tryorder is _full_ of browsers. And then they are all registered, of course only if they are available, but disregarding $TERM and $DISPLAY. So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run. And, surprise, surprise, I run mostly on the virual console, and not in X. If it is supposed to be that way it's very strange for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 22:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Sun Sep 8 21:50:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 13:50:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 15:50 Message: Logged In: YES user_id=80475 Fixed for Py2.3. See shutil.py 1.23 Also, see patch 604600. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 11:22 Message: Logged In: YES user_id=539787 See patch 604600 ---------------------------------------------------------------------- Comment By: Matthias Kirst (mattkirst) Date: 2001-12-10 06:06 Message: Logged In: YES user_id=397984 That's correct when using the command interactively. But when the command is used in an environment where source and destination path come from user interactions over a GUI for instance the programmer won't check for the source and destination path each time the command is called. In my example I had a relative and an absolute path to compare. So I would have had the relative path tracked programmatically. At the end it seemed clearer to me to read the source file out, create an empty destination (open "w+") and write the dump to this file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:42 Message: Logged In: YES user_id=6656 To the OP, if you're paying attention: shutil is pretty useless. You might consider using distutils.file_util instead (though I don't know if that suffers from this "problem"). I wanted to do somthing about this before 2.2, sigh... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 12:17 Message: Logged In: YES user_id=6380 I know the Unix 'cp' command tests for this condition, but shouldn't this fall in the category of "don't do that, then" in the Python world? How stupid do we expect the programmer to be? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Sun Sep 8 22:16:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 14:16:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-577793 ] Docs unclear about cleanup. Message-ID: Bugs item #577793, was opened at 2002-07-05 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577793&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docs unclear about cleanup. Initial Comment: The docs say (in http://www.python.org/dev/doc/devel/ref/customization.ht ml): "Python 1.5 guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the __del__() method is called." It should be made clear whether this is still true for newer python versions (or not). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 16:16 Message: Logged In: YES user_id=80475 Clarified docs. See ref3.tex 1.94. Marking as fixed and closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577793&group_id=5470 From noreply@sourceforge.net Sun Sep 8 22:49:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 14:49:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-606463 ] PyString_AsString underdocumented Message-ID: Bugs item #606463, was opened at 2002-09-08 16:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606463&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_AsString underdocumented Initial Comment: PyString_AsString() lacks a complete semantic description (can be done in terms of PyString_AsStringAndSize) or any description of what happens in case of error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606463&group_id=5470 From noreply@sourceforge.net Sun Sep 8 22:50:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 14:50:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Sun Sep 8 22:55:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 14:55:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: Bugs item #576990, was opened at 2002-07-03 09:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Nobody/Anonymous (nobody) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 16:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 06:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 07:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Sun Sep 8 23:11:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 15:11:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: Bugs item #576990, was opened at 2002-07-03 09:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Nobody/Anonymous (nobody) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 17:11 Message: Logged In: YES user_id=80475 Okay, now I see what you're trying to do. Still, it the strangest use of property that I've seen to-date. Re-opening the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 16:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 06:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 07:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Sun Sep 8 23:47:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 15:47:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-606493 ] defining away __attribute__ is not good Message-ID: Bugs item #606493, was opened at 2002-09-08 17:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606493&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: defining away __attribute__ is not good Initial Comment: In pyport.h, __attribute__ is defined away on compilers that aren't known to support it. In a situation where python is being embedded, this is not very friendly behavior. Some compilers e.g. CodeWarrior support __attribute__, but not with the options that Python uses "(format(printf, m, n))". A better solution would be to define a macro e.g. PyAttribute and to use that in the python code base wherever __attribute__ is currently used. On compilers that support __attribute__((format(printf, m, n))), PyAttribute could be defined, and on compilers that don't, it could define to nothing. That way compilers that partially support __attribute__ would not get it silently defined away - which can be critical especially if you rely upon __attribute__((aligned (n))). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606493&group_id=5470 From noreply@sourceforge.net Sun Sep 8 23:55:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 15:55:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 00:27:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 16:27:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 18:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 00:55:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 16:55:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-08 19:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 01:00:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 17:00:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 18:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 18:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 01:27:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 17:27:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-08 20:27 Message: Logged In: YES user_id=31435 malloc is a standard C function. If you want to use Python in some context that doesn't support standard uses of it, the burden falls on you to make that possible. I suggest the easiest way out may be for you to #define malloc my_allocation_function etc at the top of Python.h. I don't want to obfuscate the Python codebase for this non-standard unique requirement. BTW, note that compile.c currently (CVS) calls PyObject_Malloc instead of malloc. That was done for performance reasons. OTOH, the various threading implementations must call malloc, as it's currently forbidden to them to include a non-system header file. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 20:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 19:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 02:44:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 18:44:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 20:44 Message: Logged In: YES user_id=608086 Ok, that's fair enough....but I was basing the report on the comment in pymem.h: "To make sure the interpreter is user-malloc friendly, all memory APIs are implemented on top of this one." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 19:27 Message: Logged In: YES user_id=31435 malloc is a standard C function. If you want to use Python in some context that doesn't support standard uses of it, the burden falls on you to make that possible. I suggest the easiest way out may be for you to #define malloc my_allocation_function etc at the top of Python.h. I don't want to obfuscate the Python codebase for this non-standard unique requirement. BTW, note that compile.c currently (CVS) calls PyObject_Malloc instead of malloc. That was done for performance reasons. OTOH, the various threading implementations must call malloc, as it's currently forbidden to them to include a non-system header file. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 18:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 18:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 07:23:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 23:23:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-09 00:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 08:23 Message: Logged In: YES user_id=21627 That comment does not longer exist in pymem.h, for Python 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-09 03:44 Message: Logged In: YES user_id=608086 Ok, that's fair enough....but I was basing the report on the comment in pymem.h: "To make sure the interpreter is user-malloc friendly, all memory APIs are implemented on top of this one." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-09 02:27 Message: Logged In: YES user_id=31435 malloc is a standard C function. If you want to use Python in some context that doesn't support standard uses of it, the burden falls on you to make that possible. I suggest the easiest way out may be for you to #define malloc my_allocation_function etc at the top of Python.h. I don't want to obfuscate the Python codebase for this non-standard unique requirement. BTW, note that compile.c currently (CVS) calls PyObject_Malloc instead of malloc. That was done for performance reasons. OTOH, the various threading implementations must call malloc, as it's currently forbidden to them to include a non-system header file. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-09 02:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-09 01:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-09 01:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 07:26:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 23:26:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-606493 ] defining away __attribute__ is not good Message-ID: Bugs item #606493, was opened at 2002-09-09 00:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606493&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Ellmore (stevenellmore) >Assigned to: Neil Schemenauer (nascheme) Summary: defining away __attribute__ is not good Initial Comment: In pyport.h, __attribute__ is defined away on compilers that aren't known to support it. In a situation where python is being embedded, this is not very friendly behavior. Some compilers e.g. CodeWarrior support __attribute__, but not with the options that Python uses "(format(printf, m, n))". A better solution would be to define a macro e.g. PyAttribute and to use that in the python code base wherever __attribute__ is currently used. On compilers that support __attribute__((format(printf, m, n))), PyAttribute could be defined, and on compilers that don't, it could define to nothing. That way compilers that partially support __attribute__ would not get it silently defined away - which can be critical especially if you rely upon __attribute__((aligned (n))). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606493&group_id=5470 From noreply@sourceforge.net Mon Sep 9 11:49:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 03:49:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: Bugs item #576990, was opened at 2002-07-03 14:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: Invalid Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Nobody/Anonymous (nobody) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Roeland Rengelink (rengelink) Date: 2002-09-09 10:49 Message: Logged In: YES user_id=302601 To give a usage example: (because rhettinger thought this was a very strange use of properties, and, for all I know, he may be right) >>> class typed_property(property): ... def __init__(self, tp, doc): ... def getter(inst): ... return inst.__dict__[self] ... def setter(inst, val): ... if not isinstance(val, tp): ... raise TypeError ... inst.__dict__[self] = val ... property.__init__(self, getter, setter, ... None, doc) ... >>> class A(object): ... a = typed_property(int, 'a prop') ... >>> inst = A() >>> inst.a = 1 >>> print inst.a 1 >>> inst.a = 'a' Traceback (most recent call last): File "", line 1, in ? File "", line 7, in setter TypeError >>> A.a.__doc__ 'a prop' The last only works in 2.2, and then only if typed_property itself has no doc string ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 22:11 Message: Logged In: YES user_id=80475 Okay, now I see what you're trying to do. Still, it the strangest use of property that I've seen to-date. Re-opening the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 21:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 11:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 12:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Mon Sep 9 13:36:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 05:36:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-606692 ] xml.sax second time file loading problem Message-ID: Bugs item #606692, was opened at 2002-09-09 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 Category: XML Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam Widera (adamwidera) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax second time file loading problem Initial Comment: Platform: windows 2000 SP2 (Pl) Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 I have noticed strange problem while using the xml.sax module. When I run my application using python.exe everything is working fine, the error occures only when I try to execute my script using pythonw.exe. The problematic code looks approximately like this (It's a PyQT based application btw): parser = xml.sax.make_parser() handler = MyAppDocumentHandler() parser.setContentHandler(handler) try: self.parser.parse(fileName) except IOError: QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nIO error:\n"+str(sys.exc_info()[1])) return FALSE except: print "Unhandled exception:", sys.exc_info()[0] QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nParser error:\n"+str (sys.exc_info()[0])) return FALSE The first time when I open the file everything works ok, the file is parsed, but when I try to open another file I catch the IOError [Errno 9] Bad file descriptor error. (The file location and everything else is ok.) Greetings Adam Widera PS: If You have more questions about the bug or have problems with trigging the bug out get me know. My e- mail: adamwidera@wp.pl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 From noreply@sourceforge.net Mon Sep 9 13:46:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 05:46:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None >Group: Not a Bug >Status: Deleted >Resolution: Wont Fix Priority: 5 Submitted By: Steven Ellmore (stevenellmore) Assigned to: Nobody/Anonymous (nobody) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 01:23 Message: Logged In: YES user_id=21627 That comment does not longer exist in pymem.h, for Python 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 20:44 Message: Logged In: YES user_id=608086 Ok, that's fair enough....but I was basing the report on the comment in pymem.h: "To make sure the interpreter is user-malloc friendly, all memory APIs are implemented on top of this one." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 19:27 Message: Logged In: YES user_id=31435 malloc is a standard C function. If you want to use Python in some context that doesn't support standard uses of it, the burden falls on you to make that possible. I suggest the easiest way out may be for you to #define malloc my_allocation_function etc at the top of Python.h. I don't want to obfuscate the Python codebase for this non-standard unique requirement. BTW, note that compile.c currently (CVS) calls PyObject_Malloc instead of malloc. That was done for performance reasons. OTOH, the various threading implementations must call malloc, as it's currently forbidden to them to include a non-system header file. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 18:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 18:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 14:07:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 06:07:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-606692 ] xml.sax second time file loading problem Message-ID: Bugs item #606692, was opened at 2002-09-09 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 Category: XML Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam Widera (adamwidera) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax second time file loading problem Initial Comment: Platform: windows 2000 SP2 (Pl) Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 I have noticed strange problem while using the xml.sax module. When I run my application using python.exe everything is working fine, the error occures only when I try to execute my script using pythonw.exe. The problematic code looks approximately like this (It's a PyQT based application btw): parser = xml.sax.make_parser() handler = MyAppDocumentHandler() parser.setContentHandler(handler) try: self.parser.parse(fileName) except IOError: QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nIO error:\n"+str(sys.exc_info()[1])) return FALSE except: print "Unhandled exception:", sys.exc_info()[0] QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nParser error:\n"+str (sys.exc_info()[0])) return FALSE The first time when I open the file everything works ok, the file is parsed, but when I try to open another file I catch the IOError [Errno 9] Bad file descriptor error. (The file location and everything else is ok.) Greetings Adam Widera PS: If You have more questions about the bug or have problems with trigging the bug out get me know. My e- mail: adamwidera@wp.pl ---------------------------------------------------------------------- >Comment By: Adam Widera (adamwidera) Date: 2002-09-09 15:07 Message: Logged In: YES user_id=608362 Platform: windows 2000 SP2 (Pl) Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Correction to the previous bug message: the 5'th line of the example should of course look like this: parser.parse(fileName) not self.parser.parse(fileName) The bug is still actual (the literal mistake took place only in the bug report message) Greetings Adam Widera ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 From noreply@sourceforge.net Mon Sep 9 14:58:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 06:58:20 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-606733 ] Docstring formatter. Message-ID: Feature Requests item #606733, was opened at 2002-09-09 13:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=606733&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: Docstring formatter. Initial Comment: I think the code that pydoc uses to format docstrings (which is located in inspect.getdoc) should be exposed, so that you can in some way pass docstrings directly to be formatted, rather than "wrapping" them as a __doc__ attribute on a temporary object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=606733&group_id=5470 From noreply@sourceforge.net Mon Sep 9 15:05:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 07:05:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-546558 ] Windows getpass bug Message-ID: Bugs item #546558, was opened at 2002-04-20 18:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Mark Hammond (mhammond) Summary: Windows getpass bug Initial Comment: I'm currently running Python 2.2.1 on a Windows 98 box, and this is the code I have just run. ------- Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import getpass >>> def x(): ... secret = getpass.getpass('Tell me a secret: ') ... stuff = raw_input ('Tell me something else: ') ... print 'The user told me the secret was "%s" and the other thing was "%s"' % (secret, stuff) ... >>> x() Tell me a secret: Tell me something else: The user told me the secret was "Autechre" and the other thing was "" >>> ------- This may seem normal, but I didn't get the opportunity to enter anything when the raw_input was called. I'm assuming that getpass leaves the newline character in the input buffer, which is then used by raw_input, leaving you unable to enter anything. ---------------------------------------------------------------------- >Comment By: Allan Crooks (amc1) Date: 2002-09-09 14:05 Message: Logged In: YES user_id=39733 The function getpass_hack in the getpassfix module (referenced earlier) is a suitable alternative to the win_getpass function in the getpass module, but it should only be used if the operating system is Windows 95/98/ME (this is based on my observations so far). If we have a nice Pythonic way of determining what operating system that Python is running on (say, by using Marc-Andre Lemburg's platform module: http://www.lemburg.com/files/python/platform.py), we could then provide a straightforward fix. ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2002-06-11 10:01 Message: Logged In: YES user_id=39733 I've currently written a module which attempts to fix this problem, which you can get from here: http://ccec.sf.net/getpassfix.html However, as I've mentioned in the documentation, it is a hack, but the "platform" based solution should become a more suitable candidate as it is tested. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-20 20:10 Message: Logged In: YES user_id=31435 Assigning to MarkH in case he has a bright idea. I don't. The problem is that getpass on Windows is implemented via raw Windows console I/O, and console I/O buffers interact in strange and undocumented ways with C's stdio buffers. I've never found a reliable way to keep them in synch, and MS says you can't mix the two, period. The only workaround I know of is to build your own raw_input() workalike out of the msvcrt module's console I/O routines (getch(), etc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470 From noreply@sourceforge.net Mon Sep 9 15:14:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 07:14:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-606495 ] malloc called directly Message-ID: Bugs item #606495, was opened at 2002-09-08 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 Category: None Group: Not a Bug >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Steven Ellmore (stevenellmore) >Assigned to: Tim Peters (tim_one) Summary: malloc called directly Initial Comment: At least the following files use malloc directly instead of PyCore_MALLOC_FUNC (defined in pymem.h): _sre.c classobject.c compile.c There are many others too, but I'm working from a stripped down codebase. The Mac version is the worst offender. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-09 10:14 Message: Logged In: YES user_id=31435 Basing a report on that comment was fair too . The scheme envisioned there was never completed, nobody used it, nobody showed any interest in completing it , and the multiple layers of indirection macros were a real headache when things went wrong. Rather than try to fix this mess, we got rid of it for 2.3. The Big Hammer of #define'ing malloc etc to something else is much easier and bound to be more reliable than that scheme was ever going to be. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 02:23 Message: Logged In: YES user_id=21627 That comment does not longer exist in pymem.h, for Python 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 21:44 Message: Logged In: YES user_id=608086 Ok, that's fair enough....but I was basing the report on the comment in pymem.h: "To make sure the interpreter is user-malloc friendly, all memory APIs are implemented on top of this one." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 20:27 Message: Logged In: YES user_id=31435 malloc is a standard C function. If you want to use Python in some context that doesn't support standard uses of it, the burden falls on you to make that possible. I suggest the easiest way out may be for you to #define malloc my_allocation_function etc at the top of Python.h. I don't want to obfuscate the Python codebase for this non-standard unique requirement. BTW, note that compile.c currently (CVS) calls PyObject_Malloc instead of malloc. That was done for performance reasons. OTOH, the various threading implementations must call malloc, as it's currently forbidden to them to include a non-system header file. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 20:00 Message: Logged In: YES user_id=608086 It's a bug because it should be possible to embed Python in an application that does its own memory management and have Python play nice with it. In this scenario, the ONLY thing that should be calling malloc directly is the memory manager. Everything else should route through the memory manager so that application specific heap management can take place. At the embedded system scale (think: no virtual memory), the typical operation of a custom memory manager is to malloc all of memory, which means that any subsequent rogue calls to malloc will fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-08 19:55 Message: Logged In: YES user_id=31435 Why do you think this is a bug? There's no rule against calling malloc(), other than if you do, you must call free() instead of one of the PyMem or PyObject free functions. Note that PyCore_MALLOC_FUNC doesn't exist in the current CVS source -- we purged a lot of unused complexity in those macro layers for 2.3. ---------------------------------------------------------------------- Comment By: Steven Ellmore (stevenellmore) Date: 2002-09-08 19:27 Message: Logged In: YES user_id=608086 Followup: Oops...I think the correct solution is to have them use PyMem_MALLOC and NOT PyCore_MALLOC_FUNC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470 From noreply@sourceforge.net Mon Sep 9 15:27:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 07:27:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-604803 ] pre bug Message-ID: Bugs item #604803, was opened at 2002-09-05 01:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604803&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Fredrik Lundh (effbot) Summary: pre bug Initial Comment: Hi there, I have an annoying bug with python 2.2 -- a workaround is also appreciated. Thanks. blauw:~/usr/src/lilypond$ cat q.py import pre print pre.sub ('(@)', r'@\1', r"\key c \minor r8 c16 b c8 g as c16 b c8 d | g,4 ") blauw:~/usr/src/lilypond$ python2 q.py Traceback (most recent call last): File "q.py", line 4, in ? print pre.sub ('(@)', r'@\1', r"\key c \minor r8 c16 b c8 g as c16 b c8 d | g,4 ") File "/usr/lib/python2.2/pre.py", line 179, in sub return pattern.sub(repl, string, count) File "/usr/lib/python2.2/pre.py", line 344, in sub return self.subn(repl, string, count)[0] File "/usr/lib/python2.2/pre.py", line 366, in subn repl = pcre_expand(_Dummy, repl) TypeError: 'NoneType' object is not callable blauw:~/usr/src/lilypond$ rpm -q python2 python2-2.2-16 ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-09-09 16:27 Message: Logged In: YES user_id=38376 this has been fixed in CVS: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Lib/pre.py.diff? r1=1.10&r2=1.10.18.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604803&group_id=5470 From noreply@sourceforge.net Mon Sep 9 16:26:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 08:26:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-606251 ] elisp: doesn't recognize comment-syntax Message-ID: Bugs item #606251, was opened at 2002-09-08 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: elisp: doesn't recognize comment-syntax Initial Comment: [forwarded from http://bugs.debian.org/159630] It would be awfully nice if python-mode.el knew about python comment syntax and told emacs about it, so that the M-q fill-paragraph command that formats comment blocks so nicely in C and Perl modes would do the right thing. As it stands, M-q in the middle of the comment block on something like this:.. def func(): blah = 2 # this is a comment # this is also a comment foo = 3 jams the entire function into one line, statements and comments and all. I'd really like it to identify the comments, set the region around them, do a normal paragraph-fill (with the fill-prefix set to the existing indentation), then restore the region. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 From noreply@sourceforge.net Mon Sep 9 16:26:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 08:26:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-606254 ] py-electric-colon & delete-selection-mod Message-ID: Bugs item #606254, was opened at 2002-09-08 04:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: py-electric-colon & delete-selection-mod Initial Comment: python-elisp: py-electric-colon doesn't honour delete-selection mode [forwarded from http://bugs.debian.org/158811] With emacs 21 in delete-selection mode, typing a character when the region is active is supposed to replace the contents of the region. In python-mode, this doesn't work if the colon character is typed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 From noreply@sourceforge.net Tue Sep 10 03:18:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 19:18:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-607092 ] wrong SET_LINENO w/ multi-line func args Message-ID: Bugs item #607092, was opened at 2002-09-10 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: wrong SET_LINENO w/ multi-line func args Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> def f(): # line 1 ... a = [1, # line 2 ... 2] ... b = (1, # line 4 ... 2) ... c(1, # line 6 ... 2) ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (1) 9 LOAD_CONST 2 (2) 12 BUILD_LIST 2 15 STORE_FAST 0 (a) 18 SET_LINENO 4 21 LOAD_CONST 1 (1) 24 LOAD_CONST 2 (2) 27 BUILD_TUPLE 2 30 STORE_FAST 1 (b) 33 SET_LINENO 6 36 LOAD_GLOBAL 2 (c) 39 LOAD_CONST 1 (1) 42 SET_LINENO 7 <-- Error, should not be here. 45 LOAD_CONST 2 (2) 48 CALL_FUNCTION 2 51 POP_TOP 52 LOAD_CONST 0 (None) 55 RETURN_VALUE >>> python 2.2.1 generates errornous SET_LINENO instruction when function arguments tuple is separated by physical, not logical newline. This results in errornous frame.f_lineno. -Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 From noreply@sourceforge.net Tue Sep 10 06:28:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 22:28:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:28 Message: Logged In: YES user_id=80475 In section 6.1 of the C API manual: """ int PyObject_Print( PyObject *o, FILE *fp, int flags) Print an object o, on file fp. Returns -1 on error. """ Is there another place it should be documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Tue Sep 10 11:53:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 03:53:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-607253 ] header file problems Message-ID: Bugs item #607253, was opened at 2002-09-10 03:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: header file problems Initial Comment: In connection with the Boost.Python library we are having problems due to missing extern "C" in some header files. This has prompted me to systematically look at all header files on the release22-maint branch and on the CVS trunk. The summary is shown below. The most severe problem are the missing extern "C" on the release-22-maint branch. Fortunately, this is fixed already on the CVS trunk. The next important problem is that the include guards are missing in pymactoolbox.h (both trunk and maint branch). I am not clear if there have to be include guards in files that only contain #defines (such as patchlevel.h) but having them would seem safer to me. Finally, the include guards in two files are not prefixed with Py_, Again, it would seem safter to me (reduce the chances of name clashes) if all Python include guards were consistently prefixed with Py_ . Ralf Python release22-maint cvs branch: extern "C" missing in: cStringIO.h descrobject.h iterobject.h include guards missing in: descrobject.h graminit.h iterobject.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h Python cvs head (Sep 9): include guards missing in: graminit.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 From noreply@sourceforge.net Tue Sep 10 12:42:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 04:42:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-522780 ] bsddb keys corruption Message-ID: Bugs item #522780, was opened at 2002-02-26 04:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marc Conley (mconley) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb keys corruption Initial Comment: I'm having a problem with either the keys() function returning invalid information or the database getting corrupted or something along those lines. This is what I keep seeing occasionally during my development: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> db = bsddb.hashopen("test.db") >>> db.keys() ['192.168.0.1799'] >>> db["192.168.0.1799"] Traceback (most recent call last): File "", line 1, in ? KeyError: 192.168.0.1799 >>> The lines of importance are the return value for db.keys() and then the traceback. Note that the db.keys () returns a value that I immediately try to access and get a KeyError in so doing. This happens in a program with multiple threads but for which I am using a threading.Lock acquire() and release() around all database/bsddb accesses. I am also using sync()s after all write operations. The key value, by the way, should be 192.168.0.179. It is consistently, on several different occasions, getting the extra "9" appended to the end of it. This same problem has occurred 3 times during testing. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 14:42 Message: Logged In: YES user_id=539787 What does the following produce as output in the above example? >>> db[db.keys()[0]] If that fails, you most surely have key corruption. If not, then please come back with a standalone script that displays erratic behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 From noreply@sourceforge.net Tue Sep 10 12:44:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 04:44:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 14:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 04:44 Message: Logged In: NO No, that's documentation for a functin called PyObject_Print. Yes, it should be documented here: http://www.python.org/dev/doc/devel/api/type-structs.html#l2h- 824 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 22:28 Message: Logged In: YES user_id=80475 In section 6.1 of the C API manual: """ int PyObject_Print( PyObject *o, FILE *fp, int flags) Print an object o, on file fp. Returns -1 on error. """ Is there another place it should be documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Tue Sep 10 13:34:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 05:34:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-607253 ] header file problems Message-ID: Bugs item #607253, was opened at 2002-09-10 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: header file problems Initial Comment: In connection with the Boost.Python library we are having problems due to missing extern "C" in some header files. This has prompted me to systematically look at all header files on the release22-maint branch and on the CVS trunk. The summary is shown below. The most severe problem are the missing extern "C" on the release-22-maint branch. Fortunately, this is fixed already on the CVS trunk. The next important problem is that the include guards are missing in pymactoolbox.h (both trunk and maint branch). I am not clear if there have to be include guards in files that only contain #defines (such as patchlevel.h) but having them would seem safer to me. Finally, the include guards in two files are not prefixed with Py_, Again, it would seem safter to me (reduce the chances of name clashes) if all Python include guards were consistently prefixed with Py_ . Ralf Python release22-maint cvs branch: extern "C" missing in: cStringIO.h descrobject.h iterobject.h include guards missing in: descrobject.h graminit.h iterobject.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h Python cvs head (Sep 9): include guards missing in: graminit.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-10 14:34 Message: Logged In: YES user_id=45365 I've added the include guard to pymactoolbox.h. I've also added include guards and extern "C" constructs (where needed) to the include files in Mac/Include. The other ones I leave to someone else, esp. because I'm not sure things like graminit.h need them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 From noreply@sourceforge.net Tue Sep 10 13:36:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 05:36:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Raymond Hettinger (rhettinger) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 07:36 Message: Logged In: YES user_id=80475 Does the attached patch fit the bill? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 06:44 Message: Logged In: NO No, that's documentation for a functin called PyObject_Print. Yes, it should be documented here: http://www.python.org/dev/doc/devel/api/type-structs.html#l2h- 824 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:28 Message: Logged In: YES user_id=80475 In section 6.1 of the C API manual: """ int PyObject_Print( PyObject *o, FILE *fp, int flags) Print an object o, on file fp. Returns -1 on error. """ Is there another place it should be documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Tue Sep 10 13:47:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 05:47:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Raymond Hettinger (rhettinger) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2002-09-10 07:47 Message: Logged In: YES user_id=52572 I think it would be much better to follow the example of tp_compare, which says: It should return -1 and set an exception condition when an error occurred during the comparison ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 07:36 Message: Logged In: YES user_id=80475 Does the attached patch fit the bill? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 06:44 Message: Logged In: NO No, that's documentation for a functin called PyObject_Print. Yes, it should be documented here: http://www.python.org/dev/doc/devel/api/type-structs.html#l2h- 824 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:28 Message: Logged In: YES user_id=80475 In section 6.1 of the C API manual: """ int PyObject_Print( PyObject *o, FILE *fp, int flags) Print an object o, on file fp. Returns -1 on error. """ Is there another place it should be documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Tue Sep 10 13:55:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 05:55:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-570003 ] odd index entries Message-ID: Bugs item #570003, was opened at 2002-06-17 15:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570003&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: odd index entries Initial Comment: This is thoroughly wierd, and probably a latex2html bug, but I thought I'd submit it just in case. Some on the entries in most of the generated indices for the documentation don't come out right. For example, go to http://www.python.org/dev/doc/devel/ref/genindex.html and search for "1[". ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 15:55 Message: Logged In: YES user_id=539787 This might not be useful at all, but it seems that for all the failed entries (__builtin__, __main__, array, bsddb, dbm, gdbm, sys) there are no "\label{entry_name}" in the Doc/ref/*.tex files (probably because there aren't any relevant sub/sections?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570003&group_id=5470 From noreply@sourceforge.net Tue Sep 10 14:07:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 06:07:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-607092 ] wrong SET_LINENO w/ multi-line func args Message-ID: Bugs item #607092, was opened at 2002-09-10 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Michael Hudson (mwh) Summary: wrong SET_LINENO w/ multi-line func args Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> def f(): # line 1 ... a = [1, # line 2 ... 2] ... b = (1, # line 4 ... 2) ... c(1, # line 6 ... 2) ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (1) 9 LOAD_CONST 2 (2) 12 BUILD_LIST 2 15 STORE_FAST 0 (a) 18 SET_LINENO 4 21 LOAD_CONST 1 (1) 24 LOAD_CONST 2 (2) 27 BUILD_TUPLE 2 30 STORE_FAST 1 (b) 33 SET_LINENO 6 36 LOAD_GLOBAL 2 (c) 39 LOAD_CONST 1 (1) 42 SET_LINENO 7 <-- Error, should not be here. 45 LOAD_CONST 2 (2) 48 CALL_FUNCTION 2 51 POP_TOP 52 LOAD_CONST 0 (None) 55 RETURN_VALUE >>> python 2.2.1 generates errornous SET_LINENO instruction when function arguments tuple is separated by physical, not logical newline. This results in errornous frame.f_lineno. -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-09-10 13:07 Message: Logged In: YES user_id=6656 Why is this a problem? Execution isn't really on line 6 there. Think about code like: f()(1, # line 1 c()) # line 2 when "c()" is being evaluated, surely frame.f_lineno should be 2? do you think it should go back to 1 when the function f() returns is called? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 From noreply@sourceforge.net Tue Sep 10 14:13:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 06:13:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-607302 ] Missing encoding alias for cp1256 Message-ID: Bugs item #607302, was opened at 2002-09-10 13:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rayed Al-Rashed (rayed) Assigned to: Nobody/Anonymous (nobody) Summary: Missing encoding alias for cp1256 Initial Comment: windows-1256 is a very important alias for cp1256 it is missing from python2.2/encodings/aliases.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 From noreply@sourceforge.net Tue Sep 10 14:49:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 06:49:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-606464 ] tp_print return semantics Message-ID: Bugs item #606464, was opened at 2002-09-08 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Raymond Hettinger (rhettinger) Summary: tp_print return semantics Initial Comment: There's no description of the meaning of the return value from the tp_print field. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 08:49 Message: Logged In: YES user_id=80475 Committed as newtypes.tex 1.16. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-09-10 07:47 Message: Logged In: YES user_id=52572 I think it would be much better to follow the example of tp_compare, which says: It should return -1 and set an exception condition when an error occurred during the comparison ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 07:36 Message: Logged In: YES user_id=80475 Does the attached patch fit the bill? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 06:44 Message: Logged In: NO No, that's documentation for a functin called PyObject_Print. Yes, it should be documented here: http://www.python.org/dev/doc/devel/api/type-structs.html#l2h- 824 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:28 Message: Logged In: YES user_id=80475 In section 6.1 of the C API manual: """ int PyObject_Print( PyObject *o, FILE *fp, int flags) Print an object o, on file fp. Returns -1 on error. """ Is there another place it should be documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606464&group_id=5470 From noreply@sourceforge.net Tue Sep 10 15:57:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 07:57:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-577782 ] resire readonly memory mapped file Message-ID: Bugs item #577782, was opened at 2002-07-05 10:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470 Category: Windows Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Tim Peters (tim_one) Summary: resire readonly memory mapped file Initial Comment: When file is open as readonly and mmf if created as R/O too, then resizing this mapping will change its protection and desired acces to read-write. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-10 10:57 Message: Logged In: YES user_id=31435 If the requested followup info isn't forthcoming, I can only close this as Irreproducible. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-27 16:09 Message: Logged In: YES user_id=31435 Which version of Python are you talking about? Also, please give a concrete example so we don't have to guess at what you mean. Here's mine: """ import mmap f = open('in.txt', 'rb') m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) f.close() print `m[:]` m.resize(5) """ The m.resizes() attempt yields a TypeError, "mmap can't resize a readonly or copy-on-write memory map". I tried this under current CVS, and under 2.2.1, on Win2K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470 From noreply@sourceforge.net Tue Sep 10 16:35:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 08:35:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-607302 ] Missing encoding alias for cp1256 Message-ID: Bugs item #607302, was opened at 2002-09-10 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rayed Al-Rashed (rayed) Assigned to: Nobody/Anonymous (nobody) Summary: Missing encoding alias for cp1256 Initial Comment: windows-1256 is a very important alias for cp1256 it is missing from python2.2/encodings/aliases.py ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 18:35 Message: Logged In: YES user_id=539787 For your use, you can edit aliases.py. It is corrected in current CVS: Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> 'hello'.decode("windows-1256") u'hello' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 From noreply@sourceforge.net Tue Sep 10 16:56:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 08:56:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-601392 ] weird header wrapping in email.Generator Message-ID: Bugs item #601392, was opened at 2002-08-28 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Barry A. Warsaw (bwarsaw) Summary: weird header wrapping in email.Generator Initial Comment: I have discovered a particular header line that email.Generator does not wrap very well. Here it is, mangled by my web browser and SF: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05) id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (Only one line, the first, is particularly long. The other three lines all fit comfortably in 78 columns.) (Oh, I'll try to attach a message consisting solely of this header line along with my test script.) With Python 2.2.1, email.Message.as_string() wraps this header line as: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05) id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (The oddity there is the word "id" alone on a line.) With CVS Python (as of 10 minutes ago), it's wrapped as: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05)id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (Note how "id ..." is jammed right up against "(Exim 4.05)".) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 11:56 Message: Logged In: YES user_id=12800 It looks like a really simple patch to Header.py fixes this, and causes no regressions in the test suite. That's good enough for me, but I have some vague worries that it could cause breakage. This will be committed to Header.py 1.11 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 12:26 Message: Logged In: YES user_id=44345 I believe this is a duplicate of the bug report I filed: http://python.org/sf/594893 One or the other should probably be closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 12:28 Message: Logged In: YES user_id=12800 Verified. Here's a one-file example that illustrates the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470 From noreply@sourceforge.net Tue Sep 10 16:56:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 08:56:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-601392 ] weird header wrapping in email.Generator Message-ID: Bugs item #601392, was opened at 2002-08-28 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Barry A. Warsaw (bwarsaw) Summary: weird header wrapping in email.Generator Initial Comment: I have discovered a particular header line that email.Generator does not wrap very well. Here it is, mangled by my web browser and SF: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05) id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (Only one line, the first, is particularly long. The other three lines all fit comfortably in 78 columns.) (Oh, I'll try to attach a message consisting solely of this header line along with my test script.) With Python 2.2.1, email.Message.as_string() wraps this header line as: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05) id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (The oddity there is the word "id" alone on a line.) With CVS Python (as of 10 minutes ago), it's wrapped as: Received: from modemcable093.139-201-24.que.mc.videotron.ca ([24.201.139.93] helo=cthulhu.gerg.ca) by kronos.mems-exchange.org with esmtp (Exim 4.05)id 17k4h5-00034i-00 for test@mems-exchange.org; Wed, 28 Aug 2002 11:25:20 -0400 (Note how "id ..." is jammed right up against "(Exim 4.05)".) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 11:56 Message: Logged In: YES user_id=12800 It looks like a really simple patch to Header.py fixes this, and causes no regressions in the test suite. That's good enough for me, but I have some vague worries that it could cause breakage. This will be committed to Header.py 1.11 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 12:26 Message: Logged In: YES user_id=44345 I believe this is a duplicate of the bug report I filed: http://python.org/sf/594893 One or the other should probably be closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 12:28 Message: Logged In: YES user_id=12800 Verified. Here's a one-file example that illustrates the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=601392&group_id=5470 From noreply@sourceforge.net Tue Sep 10 17:12:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 09:12:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- Comment By: Quentin Crain (nanotech) Date: 2002-09-10 09:12 Message: Logged In: YES user_id=191231 I am hoping this is a useful comment/code: import re s1=('macro\n'+'a'*200+'\norcam\n')*10 s2=('macro\n'+'a'*20000+'\norcam\n')*10 p=re.compile(r'macro.*?orcam',re.DOTALL) for x in re.findall(p,s1): print x for x in re.findall(p,s2): print x Using re.findall bit the users I support because it could not scale with the data. Thanks for your efforts! Quentin Crain ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:15 Message: Logged In: YES user_id=31435 I'm afraid Guido's rewrite stacks a backtracking point for each character, so it can still die on strings of the length you're looking at. For example, here's a ~16KB string that kills it on Windows: test = '"' + ('a' * 128 + '""') * 128 + '";' The only info I know of on how to write robust regexps is in Friedl's "Mastering Regular Expressions" book, which does an excellent job. Using his "unrolling" pattern leads to the regexp r'"[^"]*(""[^"]*)*"[;\n]' which is an instance of the general normal* (special normal*)* pattern, and reduces the number of stacked backtracking points from the number of characters in the string to the number of special strings within it (given various preconditions that happen to be satisfied here -- you really need to read the book, as it resists a pithy summary). That works fine with the test string above, and even if you change it to test = '"' + ('a' * 5000 + '""') * 5000 + '";' At that point you're matching a 25MB string, which should be big enough for most web use . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 09:00 Message: Logged In: YES user_id=6380 I don't think that would make a difference. I don't understand SRE enough to know where the recursion cascade comes from; maybe Tim or Fredrik can explain? I believe it has something to do with an unexpected behavior of the *? operator. Note that it's a well-known theoretical result that parsing ambiguous languages can be O(n**3), so you might want to rethink this decision. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 08:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Tue Sep 10 17:22:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 09:22:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-577782 ] resize readonly memory mapped file Message-ID: Bugs item #577782, was opened at 2002-07-05 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470 Category: Windows Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Tim Peters (tim_one) >Summary: resize readonly memory mapped file Initial Comment: When file is open as readonly and mmf if created as R/O too, then resizing this mapping will change its protection and desired acces to read-write. ---------------------------------------------------------------------- >Comment By: Grzegorz Makarewicz (makaron) Date: 2002-09-10 18:22 Message: Logged In: YES user_id=115179 Sorry, i was out of internet ;( My python is 2.1 on windows, under 2.2 or cvs MMF works as expected - my fault. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-10 16:57 Message: Logged In: YES user_id=31435 If the requested followup info isn't forthcoming, I can only close this as Irreproducible. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-27 22:09 Message: Logged In: YES user_id=31435 Which version of Python are you talking about? Also, please give a concrete example so we don't have to guess at what you mean. Here's mine: """ import mmap f = open('in.txt', 'rb') m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) f.close() print `m[:]` m.resize(5) """ The m.resizes() attempt yields a TypeError, "mmap can't resize a readonly or copy-on-write memory map". I tried this under current CVS, and under 2.2.1, on Win2K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577782&group_id=5470 From noreply@sourceforge.net Tue Sep 10 18:29:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 10:29:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-14 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 13:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 10:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 19:00:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 11:00:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-607092 ] wrong SET_LINENO w/ multi-line func args Message-ID: Bugs item #607092, was opened at 2002-09-10 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Michael Hudson (mwh) Summary: wrong SET_LINENO w/ multi-line func args Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> def f(): # line 1 ... a = [1, # line 2 ... 2] ... b = (1, # line 4 ... 2) ... c(1, # line 6 ... 2) ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (1) 9 LOAD_CONST 2 (2) 12 BUILD_LIST 2 15 STORE_FAST 0 (a) 18 SET_LINENO 4 21 LOAD_CONST 1 (1) 24 LOAD_CONST 2 (2) 27 BUILD_TUPLE 2 30 STORE_FAST 1 (b) 33 SET_LINENO 6 36 LOAD_GLOBAL 2 (c) 39 LOAD_CONST 1 (1) 42 SET_LINENO 7 <-- Error, should not be here. 45 LOAD_CONST 2 (2) 48 CALL_FUNCTION 2 51 POP_TOP 52 LOAD_CONST 0 (None) 55 RETURN_VALUE >>> python 2.2.1 generates errornous SET_LINENO instruction when function arguments tuple is separated by physical, not logical newline. This results in errornous frame.f_lineno. -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Inyeol Lee (inyeol) Date: 2002-09-10 18:00 Message: Logged In: YES user_id=595280 I'm making a debugging util which parses current source line to get argument names. For easy parsing I need the starting lineno of current statement (line 1 in your example), not the phyical lineno of current instruction (line 2). I tested several multi-line statements with (),{},[],quotes, ... and they all sets f_lineno as their first line, which the statement starts, and do not reset/update f_lineno with following physical line break. The only (as far as I tested ;-) exception is this fucntion args tuple. For example; a = """ # line 1 foo """; b = [f(), g()] Above statement sets f_lineno to 1 and use it thruout the whole statement even though the actual call to f and g occurs at line 3 and 4. Even withe function args tuple, it is strange. f( #line1 a,b) generates one 'SET_LINENO 1' and doesn't update it, but f(a, #line1 b) generates both 'SET_LINENO 1', 'SET_LINENO 2', and changes f_lineno with the soft newline. I hope it fixed. Otherwise, I should scan both ways from current f_lineno to get a statement. -Inyeol Lee ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-09-10 13:07 Message: Logged In: YES user_id=6656 Why is this a problem? Execution isn't really on line 6 there. Think about code like: f()(1, # line 1 c()) # line 2 when "c()" is being evaluated, surely frame.f_lineno should be 2? do you think it should go back to 1 when the function f() returns is called? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 From noreply@sourceforge.net Tue Sep 10 19:32:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 11:32:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash Message-ID: Bugs item #529750, was opened at 2002-03-13 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam M. Fass (afass) Assigned to: Nobody/Anonymous (nobody) Summary: Circular reference makes Py_Init crash Initial Comment: Call Py_Initialize(), create two objects that reference each other, then call Py_Finalize() and then Py_Intialize() again. This crashes Python with the following error message: Fatal Python error: UNREF invalid object The documentation on Py_Finalize() mentions that circular references will cause memory leaks, but it does not mention this behavior. Platform info: * Windows XP * Visual C++ 6.0 * Python 2.2 ------------------------------ #include "Python.h" int main(int argc, char* argv[]) { char *code1 = "class TestClass:\n\ti = 3\nt1 = TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = t1"; Py_Initialize(); PyRun_SimpleString(code1); Py_Finalize(); Py_Initialize(); Py_Finalize(); } ------------------------------ The string "code1" contains this python code: class TestClass: i = 3 t1 = TestClass() t2 = TestClass() t1.t = t2 t2.t = t1 ---------------------------------------------------------------------- >Comment By: Adam M. Fass (afass) Date: 2002-09-10 14:32 Message: Logged In: YES user_id=485533 I just tried my code with 2.2.1 and got the same exact result. My platform is still the same: Windows XP and Visual C++ 6.0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:54 Message: Logged In: YES user_id=33168 Adam, do you still have this problem, with 2.2.1+? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 13:44 Message: Logged In: YES user_id=35752 I can't reproduce this on Linux with the latest CVS code. I tried with and without Py_DEBUG defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 From noreply@sourceforge.net Tue Sep 10 20:51:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 12:51:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-13 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 14:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 12:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 09:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 21:04:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 13:04:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-14 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 13:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 10:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 21:24:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 13:24:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-13 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:24 Message: Logged In: YES user_id=44345 A slightly less wild idea - why not just suppress all folding/reformatting for X-* headers and instead always emit the raw header value that was in the original message? That should solve the problem in the short term and allow you to come up with a suitable API for the longer term. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 15:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 14:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 12:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 09:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 21:32:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 13:32:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-14 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:32 Message: Logged In: YES user_id=12800 Why treat just the X-* header specially? BTW, the reason headers are wrapped in the first place is that RFC 2822 specifies hard and soft limits to header lengths. I think the hard limit is 998 characters, but it is recommended that no header be longer than 78 characters without wrapping. OTOH, a header like the X-VM-... header is for internal use only, so it's probably never used outside of your own applications. Note that you can suppress all wrapping by setting the maxheaderlen argument in the Generator's constructor to some outrageously large value (try 2000). Maybe a negative value should indicate that no wrapping of any headers be done? (Maybe limited to just non-encoded headers?) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 16:24 Message: Logged In: YES user_id=44345 A slightly less wild idea - why not just suppress all folding/reformatting for X-* headers and instead always emit the raw header value that was in the original message? That should solve the problem in the short term and allow you to come up with a suitable API for the longer term. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 13:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 10:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 21:45:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 13:45:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-13 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:45 Message: Logged In: YES user_id=44345 > Why treat just the X-* header specially? Because of all the possible headers they are the ones we know the least about format-wise. From my selfish perspective, they are the ones I am having the most trouble with... ;-) I'd be happy to experiment with the maxheaderlen argument. I wasn't aware it existed. Will that also solve the problem of space getting deleted? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 15:32 Message: Logged In: YES user_id=12800 Why treat just the X-* header specially? BTW, the reason headers are wrapped in the first place is that RFC 2822 specifies hard and soft limits to header lengths. I think the hard limit is 998 characters, but it is recommended that no header be longer than 78 characters without wrapping. OTOH, a header like the X-VM-... header is for internal use only, so it's probably never used outside of your own applications. Note that you can suppress all wrapping by setting the maxheaderlen argument in the Generator's constructor to some outrageously large value (try 2000). Maybe a negative value should indicate that no wrapping of any headers be done? (Maybe limited to just non-encoded headers?) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:24 Message: Logged In: YES user_id=44345 A slightly less wild idea - why not just suppress all folding/reformatting for X-* headers and instead always emit the raw header value that was in the original message? That should solve the problem in the short term and allow you to come up with a suitable API for the longer term. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 15:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 14:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 12:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 09:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Tue Sep 10 21:52:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 13:52:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-14 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:52 Message: Logged In: YES user_id=12800 > Will that also solve the problem of space getting deleted? I'm not sure, give it a try! :) If not, then I think we'll add maxheaderlen=-1 to mean do no wrapping or filling of header values (which *should* take care of the problem). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 16:45 Message: Logged In: YES user_id=44345 > Why treat just the X-* header specially? Because of all the possible headers they are the ones we know the least about format-wise. From my selfish perspective, they are the ones I am having the most trouble with... ;-) I'd be happy to experiment with the maxheaderlen argument. I wasn't aware it existed. Will that also solve the problem of space getting deleted? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:32 Message: Logged In: YES user_id=12800 Why treat just the X-* header specially? BTW, the reason headers are wrapped in the first place is that RFC 2822 specifies hard and soft limits to header lengths. I think the hard limit is 998 characters, but it is recommended that no header be longer than 78 characters without wrapping. OTOH, a header like the X-VM-... header is for internal use only, so it's probably never used outside of your own applications. Note that you can suppress all wrapping by setting the maxheaderlen argument in the Generator's constructor to some outrageously large value (try 2000). Maybe a negative value should indicate that no wrapping of any headers be done? (Maybe limited to just non-encoded headers?) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 16:24 Message: Logged In: YES user_id=44345 A slightly less wild idea - why not just suppress all folding/reformatting for X-* headers and instead always emit the raw header value that was in the original message? That should solve the problem in the short term and allow you to come up with a suitable API for the longer term. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 13:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 10:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Wed Sep 11 07:17:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 23:17:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-607668 ] Warnings can cause application errors Message-ID: Bugs item #607668, was opened at 2002-09-11 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: Warnings can cause application errors Initial Comment: If an application embeds Python while stderr is not valid, warnings can cause unexpected exceptions in the application. This is particularly a problem when it happens *while* the application is attempting to create a valid stderr :) Pythonwin recently started failing to start with the following traceback: File "f:\src\python-cvs\lib\regsub.py", line 15, in ? DeprecationWarning) File "f:\src\python-cvs\lib\warnings.py", line 45, in warn warn_explicit(message, category, filename, lineno, module, registry) File "f:\src\python-cvs\lib\warnings.py", line 104, in warn_explicit showwarning(message, category, filename, lineno) File "f:\src\python-cvs\lib\warnings.py", line 110, in showwarning file.write(formatwarning(message, category, filename, lineno)) exceptions.IOError: (9, 'Bad file descriptor') I propose that the warnings module ignore IOError exceptions when writing the warning. Attaching proposed fix. Assigning to Martin for feedback - assign back for me to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 From noreply@sourceforge.net Wed Sep 11 09:33:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 01:33:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-607668 ] Warnings can cause application errors Message-ID: Bugs item #607668, was opened at 2002-09-11 08:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: Warnings can cause application errors Initial Comment: If an application embeds Python while stderr is not valid, warnings can cause unexpected exceptions in the application. This is particularly a problem when it happens *while* the application is attempting to create a valid stderr :) Pythonwin recently started failing to start with the following traceback: File "f:\src\python-cvs\lib\regsub.py", line 15, in ? DeprecationWarning) File "f:\src\python-cvs\lib\warnings.py", line 45, in warn warn_explicit(message, category, filename, lineno, module, registry) File "f:\src\python-cvs\lib\warnings.py", line 104, in warn_explicit showwarning(message, category, filename, lineno) File "f:\src\python-cvs\lib\warnings.py", line 110, in showwarning file.write(formatwarning(message, category, filename, lineno)) exceptions.IOError: (9, 'Bad file descriptor') I propose that the warnings module ignore IOError exceptions when writing the warning. Attaching proposed fix. Assigning to Martin for feedback - assign back for me to check in. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 10:33 Message: Logged In: YES user_id=21627 Looks good, please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 From noreply@sourceforge.net Wed Sep 11 10:17:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 02:17:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-607092 ] wrong SET_LINENO w/ multi-line func args Message-ID: Bugs item #607092, was opened at 2002-09-10 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Nobody/Anonymous (nobody) Summary: wrong SET_LINENO w/ multi-line func args Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> def f(): # line 1 ... a = [1, # line 2 ... 2] ... b = (1, # line 4 ... 2) ... c(1, # line 6 ... 2) ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (1) 9 LOAD_CONST 2 (2) 12 BUILD_LIST 2 15 STORE_FAST 0 (a) 18 SET_LINENO 4 21 LOAD_CONST 1 (1) 24 LOAD_CONST 2 (2) 27 BUILD_TUPLE 2 30 STORE_FAST 1 (b) 33 SET_LINENO 6 36 LOAD_GLOBAL 2 (c) 39 LOAD_CONST 1 (1) 42 SET_LINENO 7 <-- Error, should not be here. 45 LOAD_CONST 2 (2) 48 CALL_FUNCTION 2 51 POP_TOP 52 LOAD_CONST 0 (None) 55 RETURN_VALUE >>> python 2.2.1 generates errornous SET_LINENO instruction when function arguments tuple is separated by physical, not logical newline. This results in errornous frame.f_lineno. -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-09-11 09:17 Message: Logged In: YES user_id=6656 Hrmm. I find it hard to grant this the status of "bug". Python behaves in a way that's mildly unhelpful for a tool you want to build. If it was up to me, I'd say that it was the code generation for lists, tuples, etc that was at fault. (You should also check out current CVS, seeing as there are no SET_LINENO instructions any more) What I'm working up to saying is that *I'm* not going to work on fixing this. Someone else might, or you can come up with a patch and I'll review it. ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2002-09-10 18:00 Message: Logged In: YES user_id=595280 I'm making a debugging util which parses current source line to get argument names. For easy parsing I need the starting lineno of current statement (line 1 in your example), not the phyical lineno of current instruction (line 2). I tested several multi-line statements with (),{},[],quotes, ... and they all sets f_lineno as their first line, which the statement starts, and do not reset/update f_lineno with following physical line break. The only (as far as I tested ;-) exception is this fucntion args tuple. For example; a = """ # line 1 foo """; b = [f(), g()] Above statement sets f_lineno to 1 and use it thruout the whole statement even though the actual call to f and g occurs at line 3 and 4. Even withe function args tuple, it is strange. f( #line1 a,b) generates one 'SET_LINENO 1' and doesn't update it, but f(a, #line1 b) generates both 'SET_LINENO 1', 'SET_LINENO 2', and changes f_lineno with the soft newline. I hope it fixed. Otherwise, I should scan both ways from current f_lineno to get a statement. -Inyeol Lee ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-09-10 13:07 Message: Logged In: YES user_id=6656 Why is this a problem? Execution isn't really on line 6 there. Think about code like: f()(1, # line 1 c()) # line 2 when "c()" is being evaluated, surely frame.f_lineno should be 2? do you think it should go back to 1 when the function f() returns is called? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 From noreply@sourceforge.net Wed Sep 11 13:15:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 05:15:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-607783 ] xml.dom documentation looks old Message-ID: Bugs item #607783, was opened at 2002-09-11 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607783&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom documentation looks old Initial Comment: The xml.dom section of the library has various sentences of the form "this is not implemented in Python 2.0" and "Some aspects of the API will only become available in Python 2.1", which makes it look outdated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607783&group_id=5470 From noreply@sourceforge.net Wed Sep 11 13:31:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 05:31:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-607789 ] urllib doesn't handle file://localhost Message-ID: Bugs item #607789, was opened at 2002-09-11 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607789&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib doesn't handle file://localhost Initial Comment: Urllib handles "file:/foo" and "file:///foo" locally, but not "file://localhost/foo". The later is passed to the ftp handler, which will fail if there is no ftp server running on the system. All other tools I've inspected handle the file://localhost/foo convention without going through ftp. The fix is easy enough, but I thought I'd give the RFC-police a chance to look at this before I go against one of the more subtle aspects of URL semantics. Feel free to assign back to me to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607789&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:19:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:19:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-607810 ] IDE should have "open recent" menu Message-ID: Bugs item #607810, was opened at 2002-09-11 15:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607810&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE should have "open recent" menu Initial Comment: The IDE needs an "open recent" menu, like most Mac programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607810&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:23:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:23:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-607668 ] Warnings can cause application errors Message-ID: Bugs item #607668, was opened at 2002-09-11 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Warnings can cause application errors Initial Comment: If an application embeds Python while stderr is not valid, warnings can cause unexpected exceptions in the application. This is particularly a problem when it happens *while* the application is attempting to create a valid stderr :) Pythonwin recently started failing to start with the following traceback: File "f:\src\python-cvs\lib\regsub.py", line 15, in ? DeprecationWarning) File "f:\src\python-cvs\lib\warnings.py", line 45, in warn warn_explicit(message, category, filename, lineno, module, registry) File "f:\src\python-cvs\lib\warnings.py", line 104, in warn_explicit showwarning(message, category, filename, lineno) File "f:\src\python-cvs\lib\warnings.py", line 110, in showwarning file.write(formatwarning(message, category, filename, lineno)) exceptions.IOError: (9, 'Bad file descriptor') I propose that the warnings module ignore IOError exceptions when writing the warning. Attaching proposed fix. Assigning to Martin for feedback - assign back for me to check in. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-11 23:23 Message: Logged In: YES user_id=14198 Checking in warnings.py; /cvsroot/python/python/dist/src/Lib/warnings.py,v <-- warnings.py new revision: 1.17; previous revision: 1.16 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:33 Message: Logged In: YES user_id=21627 Looks good, please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607668&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:25:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:25:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-607814 ] IDE look and feel Message-ID: Bugs item #607814, was opened at 2002-09-11 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE look and feel Initial Comment: The IDE needs to get a more MacOSX-like look and feel. I would suggest using the standard fonts for the various UI components (I know how attached you are to Python-Sans, so let's reformulate that as "optionally using the standard fonts"), and making all buttons, scrollbars and other such elements the standard sizes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:28:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:28:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-607816 ] IDE Preferences Message-ID: Bugs item #607816, was opened at 2002-09-11 15:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607816&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE Preferences Initial Comment: The IDe preferences need to go behind a single "Preferences" command, in the application menu. The simplest implementation is probably to have that window show the current settings for the prefs, with buttons leading off to the existing dialogs to change the preferences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607816&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:30:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:30:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-607821 ] IDE output window Message-ID: Bugs item #607821, was opened at 2002-09-11 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE output window Initial Comment: I think the IDE output window should pop to the front if new output appears there. Especially on OSX, where it may be obscured not only by other IDE windows but also by windows from other apps, you often don't realise that the script has produced output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:31:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:31:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-607814 ] IDE look and feel Message-ID: Bugs item #607814, was opened at 2002-09-11 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE look and feel Initial Comment: The IDE needs to get a more MacOSX-like look and feel. I would suggest using the standard fonts for the various UI components (I know how attached you are to Python-Sans, so let's reformulate that as "optionally using the standard fonts"), and making all buttons, scrollbars and other such elements the standard sizes. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2002-09-11 15:31 Message: Logged In: YES user_id=92689 All true, but there's SO much that's not 100% ok on OSX, that I'm considering abandoning the W gui kit altogether. As long as I'm not sure what the best way is (either a better gui kit based on Carbon or going all the way with Cocoa) I don't want to spend all that much time on W and IDE. So how's pyobjc coming along? ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:37:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:37:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-607821 ] IDE output window Message-ID: Bugs item #607821, was opened at 2002-09-11 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE output window Initial Comment: I think the IDE output window should pop to the front if new output appears there. Especially on OSX, where it may be obscured not only by other IDE windows but also by windows from other apps, you often don't realise that the script has produced output. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2002-09-11 15:37 Message: Logged In: YES user_id=92689 I often play with a script interactively, with the output window and the script window side-by-side. For such use it would be awful to have to output window come on top every time. I don't know... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 From noreply@sourceforge.net Wed Sep 11 16:02:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 08:02:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-598981 ] Python not handling cText Message-ID: Bugs item #598981, was opened at 2002-08-22 22:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Robin Siebler (robinsiebler) Assigned to: Jack Jansen (jackjansen) Summary: Python not handling cText Initial Comment: I have the following AppleScript which I have also converted to Python: tell application "CodeWarrior IDE" activate open file file1 disassemble file file2 set xText to (get text of document 1) end tell I had some difficulty converting the last command into Python, but the below should work (or so I have been told): import CodeWarrior, time cw = CodeWarrior.CodeWarrior(start=1) time.sleep(5) cw.activate() cw.open(file1) cw.disassemble_file(file2) time.sleep(5) xtext = app('CodeWarrior IDE').document[1].text However, instead of the text that I expect, xtext is equal to 'app('CodeWarrior IDE').document[1].text.all' Bill Fancher looked at CodeWarrior and said that it is returning cText which is not being handled by Python. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-11 17:02 Message: Logged In: YES user_id=45365 Robin, you have to give a more complete example. I can get neither the applescript nor the Python program to work. I've filled in valid filenames for file1 and file2, but the Applescript keeps giving the error "CodeWarrior IDE 4.2.5 got an error: Bad name for file. some object". Could you maybe create a sample soucre file (plus project?) and the real AppleScript you used, and pack it all up? ---------------------------------------------------------------------- Comment By: Robin Siebler (robinsiebler) Date: 2002-08-22 22:48 Message: Logged In: YES user_id=572605 I made a typo: xtext = app('CodeWarrior IDE').document[1].text should be: xtext = cw.get(CodeWarrior.text(CodeWarrior.document(1))) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470 From noreply@sourceforge.net Wed Sep 11 16:07:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 08:07:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-607821 ] IDE output window Message-ID: Bugs item #607821, was opened at 2002-09-11 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE output window Initial Comment: I think the IDE output window should pop to the front if new output appears there. Especially on OSX, where it may be obscured not only by other IDE windows but also by windows from other apps, you often don't realise that the script has produced output. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-11 17:07 Message: Logged In: YES user_id=45365 Hmm, true. Maybe make it an easy to set option? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-09-11 15:37 Message: Logged In: YES user_id=92689 I often play with a script interactively, with the output window and the script window side-by-side. For such use it would be awful to have to output window come on top every time. I don't know... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607821&group_id=5470 From noreply@sourceforge.net Wed Sep 11 16:08:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 08:08:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-607814 ] IDE look and feel Message-ID: Bugs item #607814, was opened at 2002-09-11 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE look and feel Initial Comment: The IDE needs to get a more MacOSX-like look and feel. I would suggest using the standard fonts for the various UI components (I know how attached you are to Python-Sans, so let's reformulate that as "optionally using the standard fonts"), and making all buttons, scrollbars and other such elements the standard sizes. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-11 17:08 Message: Logged In: YES user_id=45365 What time frame are you thinking? We need something decent for Python 2.3, and I would think that a complete W rewrite may be too much work. Note that I'm perfectly willing to do a bit of tweaking myself, as long as it's ok with you. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-09-11 15:31 Message: Logged In: YES user_id=92689 All true, but there's SO much that's not 100% ok on OSX, that I'm considering abandoning the W gui kit altogether. As long as I'm not sure what the best way is (either a better gui kit based on Carbon or going all the way with Cocoa) I don't want to spend all that much time on W and IDE. So how's pyobjc coming along? ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:06:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:06:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-607789 ] urllib doesn't handle file://localhost Message-ID: Bugs item #607789, was opened at 2002-09-11 08:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607789&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: urllib doesn't handle file://localhost Initial Comment: Urllib handles "file:/foo" and "file:///foo" locally, but not "file://localhost/foo". The later is passed to the ftp handler, which will fail if there is no ftp server running on the system. All other tools I've inspected handle the file://localhost/foo convention without going through ftp. The fix is easy enough, but I thought I'd give the RFC-police a chance to look at this before I go against one of the more subtle aspects of URL semantics. Feel free to assign back to me to fix it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-11 12:06 Message: Logged In: YES user_id=6380 Strange you'd think that I'm the RFC police. :-) I know nothing about what the RFC says about this, or whether the RFC is relevant to best practice. I'd like to see your patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607789&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:26:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:26:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-607783 ] xml.dom documentation looks old Message-ID: Bugs item #607783, was opened at 2002-09-11 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607783&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom documentation looks old Initial Comment: The xml.dom section of the library has various sentences of the form "this is not implemented in Python 2.0" and "Some aspects of the API will only become available in Python 2.1", which makes it look outdated. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:26 Message: Logged In: YES user_id=21627 Fixed in xmldom.tex 1.20. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607783&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:32:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:32:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-597604 ] import cycle in distutils Message-ID: Bugs item #597604, was opened at 2002-08-20 04:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: import cycle in distutils Initial Comment: There is a import cycle in distutils which causes 4Suite's setup.py to fail. Here's the reproducible, using 2.3a0 from CVS (latest updated on 18 Aug) % python Python 2.3a0 (#3, Aug 19 2002, 01:46:45) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import dist Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/distutils/dist.py", line 19, in ? from distutils.core import DEBUG File "/usr/local/lib/python2.3/distutils/core.py", line 24, in ? from distutils.dist import Distribution ImportError: cannot import name Distribution >>> However, I *can* do the following % python Python 2.3a0 (#3, Aug 19 2002, 01:46:45) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import core >>> from distutils import dist >>> This doesn't exist in Python 2.2. The cycle is obvious -- 'dist' imports 'core' imports DEBUG from 'dist'. I tried replacing things with from distutils import core and using core.DEBUG instead of DEBUG, but that caused a problem with Python's install. Hence, no patch included. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-11 16:32 Message: Logged In: YES user_id=31392 Fixed by moving DEBUG definition to separate debug module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 22:18 Message: Logged In: YES user_id=33168 Jeremy, it looks like this was introduced with your change on 04-Jun-02. If dist.py:19 (from distutils.core import DEBUG) is moved down after the Distribution class, I think this problem would be fixed. Can also move the import into the 3 methods where it's used. DEBUG is used in 3 Distribution methods: parse_config_files, get_command_obj, and _set_command_options. Jeremy, if this is a reasonable change, assign back to me and let me know how best to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597604&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:34:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:34:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-607092 ] wrong SET_LINENO w/ multi-line func args Message-ID: Bugs item #607092, was opened at 2002-09-10 04:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: wrong SET_LINENO w/ multi-line func args Initial Comment: Python 2.2.1 (#1, Apr 10 2002, 18:25:16) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import dis >>> def f(): # line 1 ... a = [1, # line 2 ... 2] ... b = (1, # line 4 ... 2) ... c(1, # line 6 ... 2) ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (1) 9 LOAD_CONST 2 (2) 12 BUILD_LIST 2 15 STORE_FAST 0 (a) 18 SET_LINENO 4 21 LOAD_CONST 1 (1) 24 LOAD_CONST 2 (2) 27 BUILD_TUPLE 2 30 STORE_FAST 1 (b) 33 SET_LINENO 6 36 LOAD_GLOBAL 2 (c) 39 LOAD_CONST 1 (1) 42 SET_LINENO 7 <-- Error, should not be here. 45 LOAD_CONST 2 (2) 48 CALL_FUNCTION 2 51 POP_TOP 52 LOAD_CONST 0 (None) 55 RETURN_VALUE >>> python 2.2.1 generates errornous SET_LINENO instruction when function arguments tuple is separated by physical, not logical newline. This results in errornous frame.f_lineno. -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:34 Message: Logged In: YES user_id=21627 I don't think there is a formal guarantee anywhere of how SET_LINENO works; any tool that wants to process bytecode needs to deal with the way a certain release emits SET_LINENO. If we now change this for 2.2.2 (say), somebody may come along and complain that his tool broke (because it took into account the specific way Python 2.2 emits those instructions), so we would need to change it back in 2.2.3. Closing as "won't fix". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-09-11 11:17 Message: Logged In: YES user_id=6656 Hrmm. I find it hard to grant this the status of "bug". Python behaves in a way that's mildly unhelpful for a tool you want to build. If it was up to me, I'd say that it was the code generation for lists, tuples, etc that was at fault. (You should also check out current CVS, seeing as there are no SET_LINENO instructions any more) What I'm working up to saying is that *I'm* not going to work on fixing this. Someone else might, or you can come up with a patch and I'll review it. ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2002-09-10 20:00 Message: Logged In: YES user_id=595280 I'm making a debugging util which parses current source line to get argument names. For easy parsing I need the starting lineno of current statement (line 1 in your example), not the phyical lineno of current instruction (line 2). I tested several multi-line statements with (),{},[],quotes, ... and they all sets f_lineno as their first line, which the statement starts, and do not reset/update f_lineno with following physical line break. The only (as far as I tested ;-) exception is this fucntion args tuple. For example; a = """ # line 1 foo """; b = [f(), g()] Above statement sets f_lineno to 1 and use it thruout the whole statement even though the actual call to f and g occurs at line 3 and 4. Even withe function args tuple, it is strange. f( #line1 a,b) generates one 'SET_LINENO 1' and doesn't update it, but f(a, #line1 b) generates both 'SET_LINENO 1', 'SET_LINENO 2', and changes f_lineno with the soft newline. I hope it fixed. Otherwise, I should scan both ways from current f_lineno to get a statement. -Inyeol Lee ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-09-10 15:07 Message: Logged In: YES user_id=6656 Why is this a problem? Execution isn't really on line 6 there. Think about code like: f()(1, # line 1 c()) # line 2 when "c()" is being evaluated, surely frame.f_lineno should be 2? do you think it should go back to 1 when the function f() returns is called? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607092&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:37:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:37:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-606692 ] xml.sax second time file loading problem Message-ID: Bugs item #606692, was opened at 2002-09-09 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 Category: XML Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam Widera (adamwidera) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax second time file loading problem Initial Comment: Platform: windows 2000 SP2 (Pl) Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 I have noticed strange problem while using the xml.sax module. When I run my application using python.exe everything is working fine, the error occures only when I try to execute my script using pythonw.exe. The problematic code looks approximately like this (It's a PyQT based application btw): parser = xml.sax.make_parser() handler = MyAppDocumentHandler() parser.setContentHandler(handler) try: self.parser.parse(fileName) except IOError: QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nIO error:\n"+str(sys.exc_info()[1])) return FALSE except: print "Unhandled exception:", sys.exc_info()[0] QMessageBox.information(None,"MyApp","Sorry, problems occured while loading:\n"+fileName+"\n\nParser error:\n"+str (sys.exc_info()[0])) return FALSE The first time when I open the file everything works ok, the file is parsed, but when I try to open another file I catch the IOError [Errno 9] Bad file descriptor error. (The file location and everything else is ok.) Greetings Adam Widera PS: If You have more questions about the bug or have problems with trigging the bug out get me know. My e- mail: adamwidera@wp.pl ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:37 Message: Logged In: YES user_id=21627 Is there any chance that when you run the application the second time, that the first instance is still around? Please use the process viewer to find out whether there are any remaining Python processes - this could be a sharing violation. ---------------------------------------------------------------------- Comment By: Adam Widera (adamwidera) Date: 2002-09-09 15:07 Message: Logged In: YES user_id=608362 Platform: windows 2000 SP2 (Pl) Python version: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Correction to the previous bug message: the 5'th line of the example should of course look like this: parser.parse(fileName) not self.parser.parse(fileName) The bug is still actual (the literal mistake took place only in the bug report message) Greetings Adam Widera ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606692&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:43:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:43:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None >Priority: 1 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- Comment By: Quentin Crain (nanotech) Date: 2002-09-10 12:12 Message: Logged In: YES user_id=191231 I am hoping this is a useful comment/code: import re s1=('macro\n'+'a'*200+'\norcam\n')*10 s2=('macro\n'+'a'*20000+'\norcam\n')*10 p=re.compile(r'macro.*?orcam',re.DOTALL) for x in re.findall(p,s1): print x for x in re.findall(p,s2): print x Using re.findall bit the users I support because it could not scale with the data. Thanks for your efforts! Quentin Crain ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 13:15 Message: Logged In: YES user_id=31435 I'm afraid Guido's rewrite stacks a backtracking point for each character, so it can still die on strings of the length you're looking at. For example, here's a ~16KB string that kills it on Windows: test = '"' + ('a' * 128 + '""') * 128 + '";' The only info I know of on how to write robust regexps is in Friedl's "Mastering Regular Expressions" book, which does an excellent job. Using his "unrolling" pattern leads to the regexp r'"[^"]*(""[^"]*)*"[;\n]' which is an instance of the general normal* (special normal*)* pattern, and reduces the number of stacked backtracking points from the number of characters in the string to the number of special strings within it (given various preconditions that happen to be satisfied here -- you really need to read the book, as it resists a pithy summary). That works fine with the test string above, and even if you change it to test = '"' + ('a' * 5000 + '""') * 5000 + '";' At that point you're matching a 25MB string, which should be big enough for most web use . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 12:00 Message: Logged In: YES user_id=6380 I don't think that would make a difference. I don't understand SRE enough to know where the recursion cascade comes from; maybe Tim or Fredrik can explain? I believe it has something to do with an unexpected behavior of the *? operator. Note that it's a well-known theoretical result that parsing ambiguous languages can be O(n**3), so you might want to rethink this decision. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 11:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 09:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 04:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 23:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 20:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 14:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 11:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 08:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 11:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 10:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 08:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:43:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:43:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 22:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:43 Message: Logged In: YES user_id=21627 Please don't invoke clock() twice per iteration. The standard timing procedure is iterations = [None] * niter start = clock() for i in iterations: actions_to_time total = clock() - start That way, you don't measure the time it takes to create the range object. Also, don't trust any measurements that have a total time of less then 10s (running it for a minute is even better). With this algorithm, please re-report the two totals, and the number of iterations. Run it several times in a row, to see how results vary. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-07 01:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 21:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 20:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 20:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-05 03:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:49:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:49:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 18:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:49 Message: Logged In: YES user_id=21627 This is not a bug (IMO). The SyntaxWarning is a step on the way of making None a keyword, at which point " from __builtin__ import None" will become a SyntaxError. Therefore, the compiler must warn about that today, according to PEP 5. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 00:38 Message: Logged In: YES user_id=31392 Right, in this particular case it is safe. The programmer can also use the warnings module to stop the warning about the optimization. The same would happen is someone used "None=None" in an argument list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-04 00:35 Message: Logged In: YES user_id=44345 Granted, perhaps it's not. In this case it is. The programmer was copying None from builtins to the local scope to speed up access to that object. If they had done something like None = 87 I would have expected a warning. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 00:21 Message: Logged In: YES user_id=31392 Maybe it isn't innocuous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:51:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:51:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-604036 ] spurious SyntaxWarning Message-ID: Bugs item #604036, was opened at 2002-09-03 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: spurious SyntaxWarning Initial Comment: The compiler now warns about assignment to None, however it trips up on this innocuous optimization: from __builtin__ import None ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 16:49 Message: Logged In: YES user_id=21627 This is not a bug (IMO). The SyntaxWarning is a step on the way of making None a keyword, at which point " from __builtin__ import None" will become a SyntaxError. Therefore, the compiler must warn about that today, according to PEP 5. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:38 Message: Logged In: YES user_id=31392 Right, in this particular case it is safe. The programmer can also use the warnings module to stop the warning about the optimization. The same would happen is someone used "None=None" in an argument list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 22:35 Message: Logged In: YES user_id=44345 Granted, perhaps it's not. In this case it is. The programmer was copying None from builtins to the local scope to speed up access to that object. If they had done something like None = 87 I would have expected a warning. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:21 Message: Logged In: YES user_id=31392 Maybe it isn't innocuous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604036&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:56:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:56:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-603724 ] setting file buffer size is unreliable Message-ID: Bugs item #603724, was opened at 2002-09-03 00:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: setting file buffer size is unreliable Initial Comment: The description of open() (ie file()) says: "If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size." PyFile_SetBufSize() passes the requested buffer size on to setvbuf(), with NULL as setvbuf()'s second parameter. The C89 standard doesn't guarantee any change to the buffer size when the second parameter is NULL, and some stdio implementations (legitimately) ignore the size parmater in such circumstances. C99's gives more guidelines, but nothing that can be relied upon: "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by the setvbuf function and the argument size specifies the size of the array; otherwise, size may determine the size of buffer allocated by the setvbuf function." (7.19.5.6) (What good is "may" to anyone?) The result of all this is that fd = open('file', 'w', 8) will not have the desired (and documented) effect (flushing the output buffer every 8 characters) on some platforms, so either the documentation of open() or the code (PyFile_SetBufSize()) should be fixed. The same problems exist with setbuf() as well. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:56 Message: Logged In: YES user_id=21627 Can you please report which systems ignore the setvbuf call? Python makes loads of assumptions about systems which are not backed by any standard. On systems which meet Python's expectation, Python behaves as documented. On systems which don't meet the expectations, we have two options a) declare the system as unsupported, or b) fix the implementation for the specific system to meet the documentation. So in the abstract, I don't see a bug here - setting the buffer size *is* reliable on Linux and Windows and many other supported systems. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 00:35 Message: Logged In: YES user_id=31392 The C99 rationale has a helpful comment on the subject of setvbuf(): C90 was not clear about what, if anything, the size argument means when buf is a null pointer. Existing practice is mixed: some implementations ignore it completely, other implementations use it as guidance for determining the size of the buffer allocated by setvbuf. C9X gives warning that size might be ignored in this case, so portable programs must be sure to supply a reasonable value. I'd be mostly inclined to change the documentation to say that the buffer is under control of the C library and that Python does whatever setvbuf() does. Or however we write the C99 weasel words in Python docstring-ease. Thankfully, Linux and Windows both have sane setvbuf() implementations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:30:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:30:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-607302 ] Missing encoding alias for cp1256 Message-ID: Bugs item #607302, was opened at 2002-09-10 15:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rayed Al-Rashed (rayed) Assigned to: Nobody/Anonymous (nobody) Summary: Missing encoding alias for cp1256 Initial Comment: windows-1256 is a very important alias for cp1256 it is missing from python2.2/encodings/aliases.py ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:30 Message: Logged In: YES user_id=21627 In addition to manually editing the file in your installation, you can also add the alias programmatically, to achieve best portability. I have now added this to aliases.py 1.11.6.1 as well, so it will be fixed in Python 2.2.2. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 17:35 Message: Logged In: YES user_id=539787 For your use, you can edit aliases.py. It is corrected in current CVS: Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> 'hello'.decode("windows-1256") u'hello' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607302&group_id=5470 From noreply@sourceforge.net Wed Sep 11 19:01:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 11:01:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-598981 ] Python not handling cText Message-ID: Bugs item #598981, was opened at 2002-08-22 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Robin Siebler (robinsiebler) Assigned to: Jack Jansen (jackjansen) Summary: Python not handling cText Initial Comment: I have the following AppleScript which I have also converted to Python: tell application "CodeWarrior IDE" activate open file file1 disassemble file file2 set xText to (get text of document 1) end tell I had some difficulty converting the last command into Python, but the below should work (or so I have been told): import CodeWarrior, time cw = CodeWarrior.CodeWarrior(start=1) time.sleep(5) cw.activate() cw.open(file1) cw.disassemble_file(file2) time.sleep(5) xtext = app('CodeWarrior IDE').document[1].text However, instead of the text that I expect, xtext is equal to 'app('CodeWarrior IDE').document[1].text.all' Bill Fancher looked at CodeWarrior and said that it is returning cText which is not being handled by Python. ---------------------------------------------------------------------- >Comment By: Robin Siebler (robinsiebler) Date: 2002-09-11 11:01 Message: Logged In: YES user_id=572605 I will create a project and attach it, however, you cannot use CodeWarrior IDE 4.2.5 because there is are bugs in it that have to do with AppleEvents. You have to use v 5.0 of the IDE. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-11 08:02 Message: Logged In: YES user_id=45365 Robin, you have to give a more complete example. I can get neither the applescript nor the Python program to work. I've filled in valid filenames for file1 and file2, but the Applescript keeps giving the error "CodeWarrior IDE 4.2.5 got an error: Bad name for file. some object". Could you maybe create a sample soucre file (plus project?) and the real AppleScript you used, and pack it all up? ---------------------------------------------------------------------- Comment By: Robin Siebler (robinsiebler) Date: 2002-08-22 13:48 Message: Logged In: YES user_id=572605 I made a typo: xtext = app('CodeWarrior IDE').document[1].text should be: xtext = cw.get(CodeWarrior.text(CodeWarrior.document(1))) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598981&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:50:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:50:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-583248 ] ConfigParser spaces in keys not read Message-ID: Bugs item #583248, was opened at 2002-07-18 08:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583248&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Martin Thopmson (martinthompson) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser spaces in keys not read Initial Comment: ConfigParser will write, but not read keys with spaces in, eg key with spaces in = 5 raises a parse exception. My fix, tested a small amount on one file!: Change regexp on Line 390 to OPTCRE = re.compile( r'(?P