From rene@kronos.szabinet.hu Sun Aug 1 21:39:44 1999 From: rene@kronos.szabinet.hu (rene@kronos.szabinet.hu) Date: Sun, 1 Aug 1999 16:39:44 -0400 (EDT) Subject: [Python-bugs-list] Compile error (PR#44) Message-ID: <199908012039.QAA00295@python.org> Full_Name: Rene Scott Version: 1.5.2 OS: Linux Submission from: mars.szabinet.hu (195.184.162.67) Compile error with Python-1.5.2 on Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1 ./configure --prefix=/usr/local --with-threads && make ... ./socketmodule.c: In function `setipaddr': ./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:392: too many arguments to function `gethostbyname_r' ./socketmodule.c:392: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyname_ex': ./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:1471: too many arguments to function `gethostbyname_r' ./socketmodule.c:1471: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyaddr': ./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from incompatible pointer type ./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r' ./socketmodule.c:1534: warning: assignment makes integer from pointer without a cast make[1]: *** [socketmodule.o] Error 1 make: *** [Modules] Error 2 From sjoerd@oratrix.nl Mon Aug 2 13:09:40 1999 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Mon, 02 Aug 1999 14:09:40 +0200 Subject: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39) In-Reply-To: Your message of Fri, 30 Jul 1999 01:34:26 -0400. <199907300534.BAA06418@python.org> References: <199907300534.BAA06418@python.org> Message-ID: <19990802120941.135CB301CFA@bireme.oratrix.nl> On Fri, Jul 30 1999 piers@cs.su.oz.au wrote: > Full_Name: Piers Lauder > Version: 1.5.2 > OS: Solaris > Submission from: metra.ucc.usyd.edu.au (129.78.64.5) > > > The following mail header, when parsed by rfc822, returns an incorrect > address from the method getaddr: > > From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999 > Date: Thu, 29 Jul 1999 00:05:26 -0700 > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary=z > Subject: A Message from Amazon.com Delivers > From: Amazon.com > > >>> import rfc822 > >>> fd=open('mail/amazon.com') > >>> M=rfc822.Message(fd, 1) > >>> M.getaddr('From') > ('', 'Amazon.com') > > Python version is: > Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 It's an incorrect mail header. The period in Amazon.com is not allowed there but the name has to be quoted with double quotes. But I guess rfc822.py could (and should) be lenient and let you get away with this. -- Sjoerd Mullender From sjoerd@oratrix.nl Mon Aug 2 13:10:21 1999 From: sjoerd@oratrix.nl (sjoerd@oratrix.nl) Date: Mon, 2 Aug 1999 08:10:21 -0400 (EDT) Subject: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39) Message-ID: <199908021210.IAA17681@python.org> On Fri, Jul 30 1999 piers@cs.su.oz.au wrote: > Full_Name: Piers Lauder > Version: 1.5.2 > OS: Solaris > Submission from: metra.ucc.usyd.edu.au (129.78.64.5) > > > The following mail header, when parsed by rfc822, returns an incorrect > address from the method getaddr: > > From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999 > Date: Thu, 29 Jul 1999 00:05:26 -0700 > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary=z > Subject: A Message from Amazon.com Delivers > From: Amazon.com > > >>> import rfc822 > >>> fd=open('mail/amazon.com') > >>> M=rfc822.Message(fd, 1) > >>> M.getaddr('From') > ('', 'Amazon.com') > > Python version is: > Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 It's an incorrect mail header. The period in Amazon.com is not allowed there but the name has to be quoted with double quotes. But I guess rfc822.py could (and should) be lenient and let you get away with this. -- Sjoerd Mullender From skip@mojam.com Wed Aug 4 16:55:06 1999 From: skip@mojam.com (skip@mojam.com) Date: Wed, 4 Aug 1999 11:55:06 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Message-ID: <199908041555.LAA19641@python.org> Full_Name: Skip Montanaro Version: 1.5.2 OS: Linux Submission from: uwire5.uwire.nunet.net (199.249.165.174) I just tried using the readline/rlcompleter stuff in my own program for the first time. I noticed that when using the completion key to complete an input from a set of choices it tacks on an extra space to the end of the string. This seems like a bug to me. There's no way for the program to know if the enter typed the space explicitly or if it was appended by raw_input(). Is this perhaps a readline bug? I haven't delved into the source code at this point. Here's a script that demonstrates the problem. Try running it three times, once entering s TAB RET once entering spam RET and once entering spam SPC RET You will see that the first and third cases are indistinguishable. #!/usr/bin/env python import string, readline, rlcompleter, sys class Completer: def __init__(self): self.list = [] def complete(self, text, state): if state == 0: self.matches = self.get_matches(text) try: return self.matches[state] except IndexError: return None def set_choices(self, list): self.list = list def get_matches(self, text): matches = [] for elt in self.list: if string.find(elt, text) == 0: matches.append(elt) return matches completer = Completer() def select_from_list(list): completer.set_choices(list) readline.parse_and_bind("tab: complete") readline.set_completer(completer.complete) sys.stderr.write("Select from [%s]: " % string.join(list, "|")) result = raw_input() return result result = select_from_list(["spam", "ham", "eggs", "juice"]) print `result`, ord(result[-1]) From guido@CNRI.Reston.VA.US Wed Aug 4 17:09:13 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 04 Aug 1999 12:09:13 -0400 Subject: [Python-bugs-list] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) In-Reply-To: Your message of "Wed, 04 Aug 1999 11:55:06 EDT." <199908041555.LAA19641@python.org> References: <199908041555.LAA19641@python.org> Message-ID: <199908041609.MAA23428@eric.cnri.reston.va.us> > I just tried using the readline/rlcompleter stuff in my own > program for the first time. I noticed that when using the > completion key to complete an input from a set of choices it > tacks on an extra space to the end of the string. This seems > like a bug to me. There's no way for the program to know if the > enter typed the space explicitly or if it was appended by > raw_input(). Is this perhaps a readline bug? I haven't delved > into the source code at this point. As far as I know this is a problem with the completion strategy hardcoded in the GNU readline code. I don't know of a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Aug 4 17:09:10 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 4 Aug 1999 12:09:10 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Message-ID: <199908041609.MAA19870@python.org> > I just tried using the readline/rlcompleter stuff in my own > program for the first time. I noticed that when using the > completion key to complete an input from a set of choices it > tacks on an extra space to the end of the string. This seems > like a bug to me. There's no way for the program to know if the > enter typed the space explicitly or if it was appended by > raw_input(). Is this perhaps a readline bug? I haven't delved > into the source code at this point. As far as I know this is a problem with the completion strategy hardcoded in the GNU readline code. I don't know of a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From joelg@dragonsys.com Thu Aug 5 00:13:48 1999 From: joelg@dragonsys.com (joelg@dragonsys.com) Date: Wed, 4 Aug 1999 19:13:48 -0400 (EDT) Subject: [Python-bugs-list] cPickle.loads('hello') GPF's (PR#46) Message-ID: <199908042313.TAA27721@python.org> Full_Name: Joel Gould Version: 1.5.2 OS: Windows 98 Submission from: gould.ne.mediaone.net (24.218.66.250) Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] The following 2-line Python program will cause a GPF (General Protection Fault): from cPickle import loads loads('hello') I expected an exception to be raised instead. From guido@CNRI.Reston.VA.US Thu Aug 5 05:33:35 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 05 Aug 1999 00:33:35 -0400 Subject: [Python-bugs-list] cPickle.loads('hello') GPF's (PR#46) In-Reply-To: Your message of "Wed, 04 Aug 1999 19:13:48 EDT." <199908042313.TAA27721@python.org> References: <199908042313.TAA27721@python.org> Message-ID: <199908050433.AAA24768@eric.cnri.reston.va.us> > Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] > > The following 2-line Python program will cause a GPF (General Protection > Fault): > > from cPickle import loads > loads('hello') > > I expected an exception to be raised instead. Joel, Thanks for your bug report. This has already been fixed in our codebase, see the CVS repository, cPickle.c rev. 2.37. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Aug 5 05:36:29 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 5 Aug 1999 00:36:29 -0400 (EDT) Subject: [Python-bugs-list] cPickle.loads('hello') GPF's (PR#46) Message-ID: <199908050436.AAA02197@python.org> > Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] > > The following 2-line Python program will cause a GPF (General Protection > Fault): > > from cPickle import loads > loads('hello') > > I expected an exception to be raised instead. Joel, Thanks for your bug report. This has already been fixed in our codebase, see the CVS repository, cPickle.c rev. 2.37. --Guido van Rossum (home page: http://www.python.org/~guido/) From nfakh@bom2.vsnl.net.in Sun Aug 8 16:42:15 1999 From: nfakh@bom2.vsnl.net.in (nfakh@bom2.vsnl.net.in) Date: Sun, 8 Aug 1999 11:42:15 -0400 (EDT) Subject: [Python-bugs-list] REs beginning with .* (PR#47) Message-ID: <199908081542.LAA28030@python.org> Full_Name: Najmuddin Fakhruddin Version: 1.5.1, 1.5.2 OS: Linux (RedHat 5.2) Submission from: ppp-203-197-6-233.bom.vsnl.net.in (203.197.6.233) Let p = ".*" + r , where r is a regular expression. Let s be any string such that re.search(r,s).group() does not contain any characters before the first newline character. Then re.search(p,s) seems to fail in all the examples that I've tried. Example: >>> r = "d" >>> s = "abc\nabd" >>> print re.search(".*" + r, s) None I woud have thought that re.search(".*" + r, s) should match 'abd'. From mok@imsb.au.dk Mon Aug 9 15:27:02 1999 From: mok@imsb.au.dk (mok@imsb.au.dk) Date: Mon, 9 Aug 1999 10:27:02 -0400 (EDT) Subject: [Python-bugs-list] Annoyance in ftpmirror.py script (PR#48) Message-ID: <199908091427.KAA23949@python.org> Full_Name: Morten Kjeldgaard Version: 1.5.2 OS: Linux Linux 2.0.36 Submission from: imsb.au.dk (192.38.35.2) The script ftpmirror.py contains some useful (for me) routines, but the file cannot be imported unless the following (trivial) patch is applied 395c395,396 < main() --- > if __name__ == "__main__": > main() From guido@CNRI.Reston.VA.US Mon Aug 9 15:27:04 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 9 Aug 1999 10:27:04 -0400 (EDT) Subject: [Python-bugs-list] REs beginning with .* (PR#47) Message-ID: <199908091427.KAA23959@python.org> I think you're right, especially since re.search("a.*d", "abc\nabd") correctly matches "abd". I've forwarded this to Andrew Kuchling who is maintaining the re module. --Guido van Rossum (home page: http://www.python.org/~guido/) > Let p = ".*" + r , where r is a regular expression. Let s be any string > such that re.search(r,s).group() does not contain any characters before > the first newline character. Then re.search(p,s) seems to fail in all > the examples that I've tried. > > Example: > >>> r = "d" > >>> s = "abc\nabd" > >>> print re.search(".*" + r, s) > None > > I woud have thought that re.search(".*" + r, s) should match 'abd'. From fpadilla@att.com Tue Aug 10 20:58:53 1999 From: fpadilla@att.com (fpadilla@att.com) Date: Tue, 10 Aug 1999 15:58:53 -0400 (EDT) Subject: [Python-bugs-list] test failed: test_popen2 (PR#49) Message-ID: <199908101958.PAA01116@python.org> Full_Name: Fred Padilla Version: Python-1.5.2 OS: Sun Solaris 2.6 Submission from: alpxy4.att.com (192.128.167.83) Ran default options for "configure, make, and make test." Results: 41 tests OK. 1 test failed: test_popen2 19 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt tesest_rgbimg test_sunaudiodev test_thread test_timing test_zlib *** Error code 1 make: Fatal error: Command failed for target `test' Ran ./python ./Lib/test/test_popen2.py testing popen2... testing popen3... Traceback (innermost last): File "./Lib/test/test_popen2.py", line 16, in ? main() File "./Lib/test/test_popen2.py", line 14, in main popen2._test() File "./Lib/popen2.py", line 95, in _test assert not _active AssertionError Please advise. Checked Python Resources and found 3 msgs (Newsgroups) stating problems with Solaris and BeOS. Thanks in advance for your help. FP From guido@CNRI.Reston.VA.US Tue Aug 10 22:44:42 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 10 Aug 1999 17:44:42 -0400 (EDT) Subject: [Python-bugs-list] test failed: test_popen2 (PR#49) Message-ID: <199908102144.RAA03067@python.org> > Ran ./python ./Lib/test/test_popen2.py > testing popen2... > testing popen3... > Traceback (innermost last): > File "./Lib/test/test_popen2.py", line 16, in ? > main() > File "./Lib/test/test_popen2.py", line 14, in main > popen2._test() > File "./Lib/popen2.py", line 95, in _test > assert not _active > AssertionError Thanks for reporting. This was fixed soon after 1.5.2 was released but the fix was only publicized in the CVS tree. Here's the fix: Index: popen2.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/popen2.py,v retrieving revision 1.7 retrieving revision 1.8 diff -c -r1.7 -r1.8 *** popen2.py 1998/03/26 21:12:36 1.7 --- popen2.py 1999/04/20 12:27:31 1.8 *************** *** 91,97 **** w.close() assert r.read() == teststr assert e.read() == "" ! _cleanup() assert not _active print "All OK" --- 91,98 ---- w.close() assert r.read() == teststr assert e.read() == "" ! for inst in _active[:]: ! inst.wait() assert not _active print "All OK" --Guido van Rossum (home page: http://www.python.org/~guido/) From bobalex@uppercase.xerox.com Thu Aug 12 00:19:18 1999 From: bobalex@uppercase.xerox.com (bobalex@uppercase.xerox.com) Date: Wed, 11 Aug 1999 19:19:18 -0400 (EDT) Subject: [Python-bugs-list] Bug in os.environ for Windows (PR#50) Message-ID: <199908112319.TAA02236@python.org> Full_Name: Bob Alexander Version: 1.5.2 OS: WinNT Submission from: cfwww2.epn.eastgw.xerox.com (208.140.33.202) os.environ for Windows appears to be a map-type object that converts its keys to upper case. Retrieval using a mixed case key works in some cases, but some overloaded "operators" don't seem to do the right thing unless I pass an all-upper-case key. E.g.: >>> os.environ["x"] = "y" # Stores pair {"X": "y"} >>> os.environ["x"] # Works, indicates an effort is made 'y' # to retrieve mixed case keys >>> os.environ.get("x", "NOT FOUND") # Doesn't see the key "x" 'NOT FOUND' >>> os.environ.get("X", "NOT FOUND") # Works with all-upper-case key 'y' >>> del os.environ["x"] # Doesn't see the key "x" Traceback (innermost last): File "", line 1, in ? File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__ def __delitem__(self, key): del self.data[key] KeyError: x >>> del os.environ["X"] # Works with all-upper-case key From park6@fas.harvard.edu Sun Aug 15 07:02:31 1999 From: park6@fas.harvard.edu (park6@fas.harvard.edu) Date: Sun, 15 Aug 1999 02:02:31 -0400 (EDT) Subject: [Python-bugs-list] cPickle dumps core (PR#51) Message-ID: <199908150602.CAA23679@python.org> Full_Name: James Park Version: 1.5.2 OS: Redhat Linux 6.0 (2.2.7) Submission from: r82aap001570.nyr.cable.rcn.com (209.122.72.89) #! /usr/bin/env python from cPickle import loads, dumps def _haha(boom, loads=loads): try: return loads(boom) except: return boom zoom = _haha print apply(zoom, ("park6",)) this bit of code works fine. "return loads(boom)" causes an error (cPickle.UnpicklingError: unpickling stack underflow) and I guess the try statement catches it. but when i replace the string "park6" with the string "joetest", the program dumps core with the message cPickle.BadPickleGet zsh:segmentation fault(core dumped) From da@ski.org Sun Aug 15 22:52:21 1999 From: da@ski.org (da@ski.org) Date: Sun, 15 Aug 1999 17:52:21 -0400 (EDT) Subject: [Python-bugs-list] struct.pack not being very picky (PR#52) Message-ID: <199908152152.RAA10619@python.org> Full_Name: David Ascher Version: 1.5.2 OS: NT4SP3 Submission from: (NULL) (209.117.142.20) >>> from struct import * >>> struct.pack('B', -12) '\364' I expected a ValueError, the way: >>> struct.pack('c', 123) Traceback (innermost last): File "", line 1, in ? struct.error: char format require string of length 1 works. From tm@funcom.com Mon Aug 16 14:58:09 1999 From: tm@funcom.com (tm@funcom.com) Date: Mon, 16 Aug 1999 09:58:09 -0400 (EDT) Subject: [Python-bugs-list] popen2 and socket. (PR#53) Message-ID: <199908161358.JAA01434@python.org> Full_Name: Terje Malmedal Version: latest from CVS OS: Linux 2.2.10 libc5.3.12 Submission from: cornavin.funcom.com (193.71.100.140) When doing make test on the latest(as of 16 Aug 1999) python version, the popen2 and socket tests fail. output from test_popen2: testing popen2... Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 84, in _test r, w = popen2('cat') File "../../Lib/popen2.py", line 73, in popen2 inst = Popen3(cmd, 0, bufsize) File "../../Lib/popen2.py", line 24, in __init__ os.close(0) OSError: [Errno 9] Bad file number Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 87, in _test assert r.read() == teststr AssertionError output from test_socket: socket.error Traceback (innermost last): File "test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found From tm@funcom.com Mon Aug 16 15:41:45 1999 From: tm@funcom.com (tm@funcom.com) Date: Mon, 16 Aug 1999 10:41:45 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161441.KAA02275@python.org> [Guido van Rossum] > This is not a Python bug. > Your network environment has not been set up properly. Yes it is. The machine is connected to the internet. Everything else, including Apache and Perl are able to use the network. I forgot to mention that Python 1.5.1 works with no problems. > Don't worry unless you want to use sockets > (in that case you have to figure out how to set > up your Linux networking; Python will automatically follow). -- - Terje tm@funcom.com From guido@CNRI.Reston.VA.US Mon Aug 16 16:36:48 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 16 Aug 1999 11:36:48 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161536.LAA03222@python.org> > [Guido van Rossum] > > This is not a Python bug. > > Your network environment has not been set up properly. > > Yes it is. The machine is connected to the internet. Everything else, > including Apache and Perl are able to use the network. > > I forgot to mention that Python 1.5.1 works with no problems. The specific problem is with the DNS. The failing line in test_socket.py checks that the DNS lookup for the result of gethostname() succeeds. In your case, it fails. There are tons of possible reasons why it would fail: perhaps gethostname() returns a host without a domain, or perhaps your hostname isn't registered in your DNS. You may be able to fix it by editing /etc/hosts. If (as you say) the rest of the network works fine, you don't have to worry about the two failing tests. --Guido van Rossum (home page: http://www.python.org/~guido/) From tm@funcom.com Mon Aug 16 18:17:42 1999 From: tm@funcom.com (tm@funcom.com) Date: Mon, 16 Aug 1999 13:17:42 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161717.NAA05256@python.org> [Guido van Rossum] >> [Guido van Rossum] >> > This is not a Python bug. >> > Your network environment has not been set up properly. >> >> Yes it is. The machine is connected to the internet. Everything else, >> including Apache and Perl are able to use the network. >> >> I forgot to mention that Python 1.5.1 works with no problems. > The specific problem is with the DNS. The failing line in > test_socket.py checks that the DNS lookup for the result of > gethostname() succeeds. In your case, it fails. There are tons of > possible reasons why it would fail: perhaps gethostname() returns a > host without a domain, or perhaps your hostname isn't registered in > your DNS. You may be able to fix it by editing /etc/hosts. Something else is going on, I built python 1.5.1 and 1.5.2 on the exact same machine with exact same configure statements: Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") Traceback (innermost last): File "", line 1, in ? socket.error: host not found >>> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") '207.25.71.12' >>> gethostbyname("localhost") gives the same result, works in 1.5.1, but not in 1.5.2. -- - Terje tm@funcom.com From guido@CNRI.Reston.VA.US Mon Aug 16 18:22:14 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 16 Aug 1999 13:22:14 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161722.NAA05426@python.org> > Something else is going on, I built python 1.5.1 and 1.5.2 on the > exact same machine with exact same configure statements: > > Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > Traceback (innermost last): > File "", line 1, in ? > socket.error: host not found > >>> > > Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > '207.25.71.12' > >>> > > gethostbyname("localhost") gives the same result, works in 1.5.1, but > not in 1.5.2. Hm, all this works fine on any machine I can test it on, and I haven't heard this problem reported before. So I speculate that somehow your Python 1.5.2 build is broken. I don't know how you help you any further; perhaps you can try the newsgroup -- or just download Oliver Andrich's RPMs... --Guido van Rossum (home page: http://www.python.org/~guido/) From tm@funcom.com Mon Aug 16 19:17:21 1999 From: tm@funcom.com (tm@funcom.com) Date: Mon, 16 Aug 1999 14:17:21 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161817.OAA06477@python.org> [Guido van Rossum] >> Something else is going on, I built python 1.5.1 and 1.5.2 on the >> exact same machine with exact same configure statements: >> >> Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> Traceback (innermost last): >> File "", line 1, in ? >> socket.error: host not found >> >>> >> >> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> '207.25.71.12' >> >>> >> >> gethostbyname("localhost") gives the same result, works in 1.5.1, but >> not in 1.5.2. > Hm, all this works fine on any machine I can test it on, and I haven't > heard this problem reported before. So I speculate that somehow your > Python 1.5.2 build is broken. I don't know how you help you any > further; perhaps you can try the newsgroup -- or just download Oliver > Andrich's RPMs... I finally found it, in socketmodule.c O replaced this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_6_ARG #else with this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_5_ARG #else And everything worked. Strange that nobody else has noticed this, maybe it's a libc versus glibc thing or something. Anyway, thanks for your time. -- - Terje tm@funcom.com From guido@CNRI.Reston.VA.US Mon Aug 16 19:23:00 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 16 Aug 1999 14:23:00 -0400 (EDT) Subject: [Python-bugs-list] Re: popen2 and socket. (PR#53) Message-ID: <199908161823.OAA06618@python.org> > I finally found it, in socketmodule.c O replaced this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_6_ARG > #else > > with this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_5_ARG > #else > > And everything worked. Strange that nobody else has noticed this, > maybe it's a libc versus glibc thing or something. > > Anyway, thanks for your time. Ah, thanks! As you say, this is probably dependent on your libc version. A better solution should be found, really... I'll mark the bug report as "open". --Guido van Rossum (home page: http://www.python.org/~guido/) From arcege@shore.net Wed Aug 18 00:53:27 1999 From: arcege@shore.net (arcege@shore.net) Date: Tue, 17 Aug 1999 19:53:27 -0400 (EDT) Subject: [Python-bugs-list] ftplib.FTP.cwd fails when given an empty string (PR#54) Message-ID: <199908172353.TAA10034@python.org> Full_Name: Michael P. Reilly Version: CVS sources as of 19990817 OS: Solaris 2.6, AIX 4.2.1 Submission from: golem.shore.net (198.115.177.38) The cwd method of the ftplib.FTP class raises a IOError exception. "IOError: [Errno ftp error] 500 'CWD ': command not understood." Similarly, the urllib.URLopener.open_ftp method splits the pathname into directories, but it does not correctly "remove" the root pathname, it should instead pass "/". I will email a patch to Guido. From sergio@mnc.md Thu Aug 19 13:50:54 1999 From: sergio@mnc.md (sergio@mnc.md) Date: Thu, 19 Aug 1999 08:50:54 -0400 (EDT) Subject: [Python-bugs-list] string bug in atoi (PR#55) Message-ID: <199908191250.IAA24929@python.org> Full_Name: Sergio Baca Version: 1.52 and JPython last beta OS: Windows NT Submission from: sergio.mnc.md (212.0.192.40) I have found error in string module. This is a test program: --- from string import atoi str1 = "0x8e" print atoi(str1, 16) print atoi(str1) --- As I can read from documentation: --- atoi (s[, base]) Convert string s to an integer in the given base. The string must consist of one or more digits, optionally preceded by a sign ("+" or "-"). The base defaults to 10. If it is 0, a default base is chosen depending on the leading characters of the string (after stripping the sign): "0x" or "0X" means 16, "0" means 8, anything else means 10. If base is 16, a leading "0x" or "0X" is always accepted. Note that when invoked without base or with base set to 10, this behaves identical to the built-in function int() when passed a string. (Also note: for a more flexible interpretation of numeric literals, use the built-in function eval().) --- Both cases should work good, but in both cases I receive error. In first case: --- Traceback (innermost last): File "stringTest.py", line 3, in ? File "D:\WINNT\Profiles\sergio1\JPython-1.1beta2\Lib\string.py", line 228, in atoi TypeError: int$(): expected 1 args; got 2 --- And in second: --- Traceback (innermost last): File "stringTest.py", line 4, in ? File "D:\WINNT\Profiles\sergio1\JPython-1.1beta2\Lib\string.py", line 228, in atoi ValueError: invalid literal for __int__: 0x8e --- Identical error messages I receive in Python 1.52 Please write me if I'm doing something wrong. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Aug 19 17:08:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 19 Aug 1999 12:08:05 -0400 (EDT) Subject: [Python-bugs-list] string bug in atoi (PR#55) References: <199908191250.IAA24929@python.org> Message-ID: <14268.11237.641922.801572@anthem.cnri.reston.va.us> >>>>> "sergio" == writes: | Full_Name: Sergio Baca | Version: 1.52 and JPython last beta | OS: Windows NT | Submission from: sergio.mnc.md (212.0.192.40) | I have found error in string module. This is a test program: | --- | from string import atoi | str1 = "0x8e" | print atoi(str1, 16) | print atoi(str1) | --- This actually works as expected in CPython; the first one prints 142 and the second raises an exception (as expected, since the default base is 10). However, in JPython the first atoi() call does indeed give you a traceback because it doesn't grok the second argument (i.e. the optional base). This has already been reported as PR#153 http://www.python.org/jpython-bugs/incoming?id=153 so there's no need for you to resubmit it. -Barry From bwarsaw@cnri.reston.va.us Thu Aug 19 17:07:55 1999 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Thu, 19 Aug 1999 12:07:55 -0400 (EDT) Subject: [Python-bugs-list] string bug in atoi (PR#55) Message-ID: <199908191607.MAA29757@python.org> >>>>> "sergio" == writes: | Full_Name: Sergio Baca | Version: 1.52 and JPython last beta | OS: Windows NT | Submission from: sergio.mnc.md (212.0.192.40) | I have found error in string module. This is a test program: | --- | from string import atoi | str1 = "0x8e" | print atoi(str1, 16) | print atoi(str1) | --- This actually works as expected in CPython; the first one prints 142 and the second raises an exception (as expected, since the default base is 10). However, in JPython the first atoi() call does indeed give you a traceback because it doesn't grok the second argument (i.e. the optional base). This has already been reported as PR#153 http://www.python.org/jpython-bugs/incoming?id=153 so there's no need for you to resubmit it. -Barry From mso@sense-sea-MegaSub-1-220.oz.net Thu Aug 19 22:47:01 1999 From: mso@sense-sea-MegaSub-1-220.oz.net (mso@sense-sea-MegaSub-1-220.oz.net) Date: Thu, 19 Aug 1999 17:47:01 -0400 (EDT) Subject: [Python-bugs-list] gzip missing feature -- GzipFile.readlines(number) (PR#56) Message-ID: <199908192147.RAA09575@python.org> Full_Name: Mike Orr Version: 1.5.2 OS: Linux Submission from: passenger.ssc.com (216.39.159.17) gzip.GzipFile is supposed to imitate a Python file object, but it does not support calling the readlines method with an integer argument to limit the amount of data read. This makes it difficult to write programs which handle compressed and uncompressed data interchangeably, if they depend on third-party functions which call the readlines(number) method. From guido@CNRI.Reston.VA.US Thu Aug 19 22:50:28 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 19 Aug 1999 17:50:28 -0400 (EDT) Subject: [Python-bugs-list] gzip missing feature -- GzipFile.readlines(number) (PR#56) Message-ID: <199908192150.RAA09709@python.org> > gzip.GzipFile is supposed to imitate a Python file object, but it does not > support calling the readlines method with an integer argument to limit the > amount of data read. > > This makes it difficult to write programs which handle compressed and > uncompressed data interchangeably, if they depend on third-party functions > which call the readlines(number) method. You're right. Would it be okay if the extra argument was just ignored? (That would be a much simpler patch!) --Guido van Rossum (home page: http://www.python.org/~guido/) From jital@knoggin.com Fri Aug 20 09:18:20 1999 From: jital@knoggin.com (jital@knoggin.com) Date: Fri, 20 Aug 1999 04:18:20 -0400 (EDT) Subject: [Python-bugs-list] does not compile under BSDI (PR#57) Message-ID: <199908200818.EAA28024@python.org> Full_Name: John Ital Version: py152 OS: BSDI IServer Submission from: adsl-63-193-244-104.dsl.snfc21.pacbell.net (63.193.244.104) seems to think it is a NeXT arch or something $ ./configure --prefix=/usr/home/knoggin/usr/local/ --exec-prefix=/usr/home/knoggin/usr/local/ creating cache ./config.cache checking MACHDEP... bsdos3 checking CCC... checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E checking for AIX... no checking for minix/config.h... no checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking for long long support... yes checking size of long long... 8 checking size of off_t... 8 checking whether to enable large file support... yes checking for --with-next-framework... no checking for --with-dyld... required for framework build checking SO... .so checking LDSHARED... ld checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for alarm... yes checking for chown... yes checking for clock... yes checking for dlopen... yes checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for ftime... no checking for ftruncate... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pause... yes checking for plock... no checking for pthread_init... yes checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... no checking for strftime... yes checking for strptime... no checking for symlink... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for timegm... no checking for times... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... no checking for ftell64... no checking for ftello... no checking for statvfs... no checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... no checking for gethostbyname... yes checking for __fpu_control in -lieee... no checking for --with-fpectl... checking for --with-libm=STRING... default LIBM="- lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h pcvendor:~/usr/local/src/Python-1.5.2 $ make (cd Modules; make -f Makefile.pre Makefile) cp ./Setup.in Setup echo "# Edit this file for local setup changes" >Setup.local rm -f ../libpython1.5.a /bin/sh ./makesetup Setup.thread Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmo dule.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule. o timemodule.o operator.o fcntlmodule.o pwdmodule.o grpmodule.o selectmodu le.o socketmodule.o errnomodule.o md5module.o md5c.o shamodule.o rotormodul e.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o ge tpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo y es >hassignal; break; fi; done cd Parser ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local /" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o listnode.o node.o parse r.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -ldl -o pgen gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cd Objects ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cd Python ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"bsdos3"' ./getplatform.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c ./importdl.c:269: mach-o/dyld.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. From guido@CNRI.Reston.VA.US Fri Aug 20 12:57:18 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Fri, 20 Aug 1999 07:57:18 -0400 (EDT) Subject: [Python-bugs-list] does not compile under BSDI (PR#57) Message-ID: <199908201157.HAA04388@python.org> > Full_Name: John Ital > Version: py152 > OS: BSDI IServer > > seems to think it is a NeXT arch or something > [...] > gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c > ./importdl.c:269: mach-o/dyld.h: No such file or directory > *** Error code 1 Very strange. I've never seen this before. It appears that somehow USE_DYLD is defined at that point, which can only happen if WITH_DYLD is defined, which can only happen if you specify --with-next-framework or --with-dyld on the configure command line, which you didn't. Perhaps you have a buggy preprocessor that is confused by the tangle of #ifdefs in importdl.c? I don't know how to help you; I know Python has been built successfully on bsdos3 before, so I'm guessing it's something in your setup, not a Python bug. If you need more help, please ask a newsgroup -- either comp.lang.python or a BSD specific one. --Guido van Rossum (home page: http://www.python.org/~guido/) From flight@debian.org Fri Aug 20 18:26:19 1999 From: flight@debian.org (flight@debian.org) Date: Fri, 20 Aug 1999 13:26:19 -0400 (EDT) Subject: [Python-bugs-list] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58) Message-ID: <199908201726.NAA13489@python.org> Full_Name: Gregor Hoffleit Version: 1.5.2 OS: Debian potato Submission from: testserv.mathi.uni-heidelberg.de (129.206.26.30) [Forwarded from the Debian bug tracking system] Sender: Chris Lawrence Package: python-base Version: 1.5.2-4 Severity: normal File: /usr/lib/python1.5/urllib.py urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack From flight@debian.org Fri Aug 20 18:40:05 1999 From: flight@debian.org (flight@debian.org) Date: Fri, 20 Aug 1999 13:40:05 -0400 (EDT) Subject: [Python-bugs-list] Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59) Message-ID: <199908201740.NAA13941@python.org> Full_Name: Gregor Hoffleit Version: 1.5.2 OS: Debian potato Submission from: testserv.mathi.uni-heidelberg.de (129.206.26.30) Summary: Python's urllib expects a fully qualified URL in HTTP_PROXY (like "http://proxy:8080/"). Many applications allow short forms in HTTP_PROXY (like "proxy:8080"). If HTTP_PROXY is set to a short form, urllib.py will fail with an uncomprehensible error message. Long form: Francesco Potorti` says (in the Debian bug report http://www.debian.org/Bugs/db/42/42318.html): "when setting a proxy variable that is not parsed by urllib, urllib does not print a comprehensible error message." An example: Short form HTTP_PROXY: master% HTTP_PROXY="proxy.cnr.it:8081" \ python -c 'import urllib; print urllib.urlretrieve("http://www.olemiss.edu/")' Traceback (innermost last): File "", line 1, in ? File "/usr/lib/python1.5/urllib.py", line 69, in urlretrieve return _urlopener.retrieve(url) File "/usr/lib/python1.5/urllib.py", line 186, in retrieve fp = self.open(url) File "/usr/lib/python1.5/urllib.py", line 154, in open return self.open_unknown(fullurl) File "/usr/lib/python1.5/urllib.py", line 168, in open_unknown raise IOError, ('url error', 'unknown url type', type) IOError: ('url error', 'unknown url type', 'http') Fully qualified URL in HTTP_PROXY: master% HTTP_PROXY="http://proxy.cnr.it:8081" \ python -c 'import urllib; print urllib.urlretrieve("http://www.olemiss.edu/")' ('/tmp/@15884.1', ) From wolfeman@apple.com Sun Aug 22 01:46:33 1999 From: wolfeman@apple.com (wolfeman@apple.com) Date: Sat, 21 Aug 1999 20:46:33 -0400 (EDT) Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) Message-ID: <199908220046.UAA19589@python.org> Full_Name: Dan Wolfe Version: 1.5.2/1.5.2b1 OS: Linux/MacOS Submission from: a17-202-21-249.apple.com (17.202.21.249) I ran into a situation with the try statement which I'm not sure is a bug or a limitation that needs to be documented. When you have an empty except: block in a try statement, both MacPython 1.5.2b1 and Linux Python 1.5.2 report that you have invalid syntax. The simplest form that recreates the error is: try: print "this is a test" raise(error) except: ### do nothing! else: print "pleasent dreams" The easiest way to fix this is by adding a single line to the empty exception block: except: ### do nothing! print "Dammit Spock, this is not logical!" From skip@mojam.com (Skip Montanaro) Sun Aug 22 13:25:25 1999 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 22 Aug 1999 07:25:25 -0500 (CDT) Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: <95790381@toto.iv> Message-ID: <14271.60277.677014.467156@dolphin.mojam.com> Dan> When you have an empty except: block in a try statement, both Dan> MacPython 1.5.2b1 and Linux Python 1.5.2 report that you have Dan> invalid syntax. That's neither a bug nor a feature. It's a syntax error. Blocks can't be empty, hence the pass statement's raison d'etre: try: print "this is a test" raise(error) except: pass else: print "pleasent dreams" Dan> The easiest way to fix this is by adding a single line to the empty Dan> exception block: And Bob's your uncle! ;-) Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098 | Python: Programming the way Guido indented... From Fred L. Drake, Jr." References: <199908201726.NAA13489@python.org> Message-ID: <14273.21696.124802.719651@weyr.cnri.reston.va.us> flight@debian.org writes: > Sender: Chris Lawrence > Package: python-base > Version: 1.5.2-4 > Severity: normal > File: /usr/lib/python1.5/urllib.py ... > (Also: the FTP class's set_pasv() method isn't documented in my > version of python-docs; I haven't checked the new 1.5.2 docs yet set_pasv() is documented in the documentation release 1.5.2p1. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Aug 23 15:03:48 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Mon, 23 Aug 1999 10:03:48 -0400 (EDT) Subject: [Python-bugs-list] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58) Message-ID: <199908231403.KAA04968@python.org> flight@debian.org writes: > Sender: Chris Lawrence > Package: python-base > Version: 1.5.2-4 > Severity: normal > File: /usr/lib/python1.5/urllib.py ... > (Also: the FTP class's set_pasv() method isn't documented in my > version of python-docs; I haven't checked the new 1.5.2 docs yet set_pasv() is documented in the documentation release 1.5.2p1. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From wolfeman@apple.com Mon Aug 23 17:39:15 1999 From: wolfeman@apple.com (Dan Wolfe) Date: Mon, 23 Aug 1999 09:39:15 -0700 Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: <14271.60277.677014.467156@dolphin.mojam.com> References: <14271.60277.677014.467156@dolphin.mojam.com> Message-ID: Hi Skip, Thanks for the answer. Unfortunately, this little nugget is not mentioned in Learning Python or Programming Python, or the online documentation - at least not where I can find it. :-) Now that I know what to look for, it does appear in Programming Python example code pg 853 but doesn't get metioned in the text..... Bottom line, who can I email to make sure that this nugget get's in the documentation? - Dan - just a python newbie with a taste for QA .... At 7:25 AM -0500 8/22/99, Skip Montanaro wrote: > Dan> When you have an empty except: block in a try statement, both > Dan> MacPython 1.5.2b1 and Linux Python 1.5.2 report that you have > Dan> invalid syntax. > >That's neither a bug nor a feature. It's a syntax error. Blocks can't be >empty, hence the pass statement's raison d'etre: > > try: > print "this is a test" > raise(error) > except: > pass > else: > print "pleasent dreams" > > Dan> The easiest way to fix this is by adding a single line to the empty > Dan> exception block: > >And Bob's your uncle! ;-) > >Skip Montanaro | http://www.mojam.com/ >skip@mojam.com | http://www.musi-cal.com/~skip/ >847-971-7098 | Python: Programming the way Guido indented... From Fred L. Drake, Jr." References: <14271.60277.677014.467156@dolphin.mojam.com> Message-ID: <14273.31301.826188.429405@weyr.cnri.reston.va.us> Dan Wolfe writes: > Thanks for the answer. Unfortunately, this little nugget is not > mentioned in Learning Python or Programming Python, or the online > documentation - at least not where I can find it. :-) Now that I > know what to look for, it does appear in Programming Python example > code pg 853 but doesn't get metioned in the text..... > > Bottom line, who can I email to make sure that this nugget get's in > the documentation? Dan, I've noted this conversation; I'll take a look at it when I get a chance to work on the documentation content again. Thanks for raising the issue. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From wolfeman@apple.com Tue Aug 24 01:52:17 1999 From: wolfeman@apple.com (Dan Wolfe) Date: Mon, 23 Aug 1999 17:52:17 -0700 Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: <14273.31301.826188.429405@weyr.cnri.reston.va.us> References: <14271.60277.677014.467156@dolphin.mojam.com> <14273.31301.826188.429405@weyr.cnri.reston.va.us> Message-ID: At 12:43 PM -0400 8/23/99, Fred L. Drake, Jr. wrote: > > I've noted this conversation; I'll take a look at it when I get a >chance to work on the documentation content again. > Thanks for raising the issue. and >At 12:00 PM -0500 8/23/99, Skip Montanaro wrote: >Well, the CC to the bugs list should do the trick for the online docs. If >you can whip up a patch (or even just a suggested piece of replacement text) >for the tutorial and/or reference manuals, Fred Drake (Dr. Doc) will see >that it gets incorporated. You can reach him at fdrake@acm.org. Well, I'll do my part. :-) * Section 8.3 (www.python.org/doc/tut/node10.html) After the paragraph that starts with "The last exception clause may omit the exception name(s), to serve as a wildcard." add the following paragraph: Each exception clause must have at least one line of executable code in the block. Comments are not executable code. If you want the exception clause to do nothing, use the pass command. * In Section 7.4, modify the paragraph starting with "When a matching exception clause is found.." to When a matching exception clause is found, the exception's parameter is assigned to the target specified in that exception clause, if present, and the exception clauses's block is executed. All exceptions must have an executable block. When the end of this block is reached, the execution continues normally after the entire try statement. ...... - Dan From skip@mojam.com (Skip Montanaro) Tue Aug 24 17:45:49 1999 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 24 Aug 1999 11:45:49 -0500 (CDT) Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: References: <14271.60277.677014.467156@dolphin.mojam.com> <14273.31301.826188.429405@weyr.cnri.reston.va.us> Message-ID: <14274.52255.459520.250005@dolphin.mojam.com> Dan> Well, I'll do my part. :-) Dan, Stop it! You're making us old-timers look bad! ;-) Skip From Fred L. Drake, Jr." References: <14271.60277.677014.467156@dolphin.mojam.com> <14273.31301.826188.429405@weyr.cnri.reston.va.us> Message-ID: <14275.6566.137861.906743@weyr.cnri.reston.va.us> Dan Wolfe writes: > Well, I'll do my part. :-) I've integrated your suggestions in the CVS repository; thanks! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue Aug 24 23:16:09 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 24 Aug 1999 18:16:09 -0400 (EDT) Subject: [Python-bugs-list] Blank except block fails in try statement (PR#61) Message-ID: <199908242216.SAA18020@python.org> Dan Wolfe writes: > Well, I'll do my part. :-) I've integrated your suggestions in the CVS repository; thanks! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From wolfeman@apple.com Tue Aug 24 23:22:57 1999 From: wolfeman@apple.com (Dan Wolfe) Date: Tue, 24 Aug 1999 15:22:57 -0700 Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: <14275.6566.137861.906743@weyr.cnri.reston.va.us> References: <14271.60277.677014.467156@dolphin.mojam.com> <14273.31301.826188.429405@weyr.cnri.reston.va.us> <14275.6566.137861.906743@weyr.cnri.reston.va.us> Message-ID: You're welcome. At some point, after talking with Jack, I might ask to get the raw HTML text so that I can create Mac OS Help book based on the Apple's new HTML based Help Technology that was released in 8.5..... Really cool stuff. :-) - Dan At 6:16 PM -0400 8/24/99, Fred L. Drake, Jr. wrote: >Dan Wolfe writes: > > Well, I'll do my part. :-) > > I've integrated your suggestions in the CVS repository; thanks! From wolfeman@apple.com Tue Aug 24 23:25:33 1999 From: wolfeman@apple.com (wolfeman@apple.com) Date: Tue, 24 Aug 1999 18:25:33 -0400 (EDT) Subject: [Python-bugs-list] Blank except block fails in try statement (PR#62) Message-ID: <199908242225.SAA18335@python.org> You're welcome. At some point, after talking with Jack, I might ask to get the raw HTML text so that I can create Mac OS Help book based on the Apple's new HTML based Help Technology that was released in 8.5..... Really cool stuff. :-) - Dan At 6:16 PM -0400 8/24/99, Fred L. Drake, Jr. wrote: >Dan Wolfe writes: > > Well, I'll do my part. :-) > > I've integrated your suggestions in the CVS repository; thanks! From wolfeman@apple.com Tue Aug 24 23:50:06 1999 From: wolfeman@apple.com (Dan Wolfe) Date: Tue, 24 Aug 1999 15:50:06 -0700 Subject: [Python-bugs-list] Blank except block fails in try statement (PR#60) In-Reply-To: <14274.52255.459520.250005@dolphin.mojam.com> References: <14271.60277.677014.467156@dolphin.mojam.com> <14273.31301.826188.429405@weyr.cnri.reston.va.us> <14274.52255.459520.250005@dolphin.mojam.com> Message-ID: Humm, Really, I'd thought you claim the old timers where having to much fun in Montery this last weekend to be working on things like this. ;-) - Dan "still stuck in Silicon Valley" At 11:45 AM -0500 8/24/99, Skip Montanaro wrote: > Dan> Well, I'll do my part. :-) > >Dan, > >Stop it! You're making us old-timers look bad! > >;-) > >Skip From mkes@ra.rockwell.com Wed Aug 25 13:37:50 1999 From: mkes@ra.rockwell.com (mkes@ra.rockwell.com) Date: Wed, 25 Aug 1999 08:37:50 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: xmllib.XMLParser.handle_data() seems to handle ']' incorrectly (PR#63) Message-ID: <199908251237.IAA10901@python.org> Full_Name: Miroslav Kes Version: 1.5.2 OS: FreeBSD 3.2 Submission from: (NULL) (205.175.223.11) Hi! I have experienced following strange behaviour of xmllib.XMLParser.handle_data() method. If I have XML tag whose body contains ']' the handle_data() method considers the ']' as separator (or what ?) and splits the whole text into pieces: the source code: ------------------- import xmllib import sys class MyXMLParser( xmllib.XMLParser ): i = 0 def __init__( self ): xmllib.XMLParser.__init__( self ) self.i = 0 def unknown_starttag( self, tag, attributes ): print 'start tag: ' + tag + str( attributes ) def unknown_endtag( self, tag ): print 'end tag: ' + tag def handle_data( self, data ): print self.i print type( data ) print data self.i = self.i + 1 def run( self, filename ): self.__init__() file = open( filename, 'r' ) self.feed( file.read()) self.close() file.close() ---------------------------------- the XML file sample: ---------------------------------- Conversion from web speed [fpm] to motor speed [rpm] wrong (reference calibration) --------------------------------- runtime: --------------------------------- odysseus:/usr/home/mira/engine> python Python 1.5.2 (#2, May 11 1999, 17:14:37) [GCC 2.7.2.1] on freebsd3 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import xmlparser >>> p = xmlparser.MyXMLParser() >>> p.run("test.xml") 0 start tag: TEST{} 1 start tag: NAME{} 2 Conversion from web speed [fpm 3 ] 4 to motor speed [rpm 5 ] 6 wrong (reference calibration) end tag: NAME 7 end tag: TEST 8 >>> ---------------------------------------- I think this is a bug because the XML specification treats the ']' as valid data character. W3C spec. - [14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) If I parse the example above with other XML parsers (MSXML and one Java based parser) and they read it OK. Mira From Fred L. Drake, Jr." References: <199908251237.IAA10901@python.org> Message-ID: <14276.1366.728439.585844@weyr.cnri.reston.va.us> mkes@ra.rockwell.com writes: > Full_Name: Miroslav Kes > Version: 1.5.2 > OS: FreeBSD 3.2 > Submission from: (NULL) (205.175.223.11) ... > I have experienced following strange behaviour of > xmllib.XMLParser.handle_data() > method. > If I have XML tag whose body contains ']' the handle_data() method considers > the ']' as separator (or what ?) and splits the whole text into pieces: While this may be confusing, this is not a bug. The API does guarantees that handle_data() will be called for all textual data, but not that each call will represent a maximal run of data. This is something that can also happen at arbitrary points in the input stream if feeding the parser object chunks of the input, which is commonly done if the input is large or comes from a network connection. To get the text content of an element, do something like this: class MyXMLParser(xmllib.XMLParser): __saving = 0 def start_ELEMENT(self, attrs): self.__saving = 1 self.__saved_text = '' def end_ELEMENT(self): text = self.__saved_text self.__saving = 0 # do something with text def handle_data(self, data): if self.__saving: self.__saved_text = self.__saved_text + data You may want to look at the implementations of save_bgn() and save_end() in htmllib.HTMLParser; similar utility methods may prove convenient and can be used to avoid a little ugliness and offer the facility to subclasses of your new class. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Wed Aug 25 16:01:49 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Wed, 25 Aug 1999 11:01:49 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: xmllib.XMLParser.handle_data() seems to handle ']' incorrectly (PR#63) Message-ID: <199908251501.LAA14962@python.org> mkes@ra.rockwell.com writes: > Full_Name: Miroslav Kes > Version: 1.5.2 > OS: FreeBSD 3.2 > Submission from: (NULL) (205.175.223.11) ... > I have experienced following strange behaviour of > xmllib.XMLParser.handle_data() > method. > If I have XML tag whose body contains ']' the handle_data() method considers > the ']' as separator (or what ?) and splits the whole text into pieces: While this may be confusing, this is not a bug. The API does guarantees that handle_data() will be called for all textual data, but not that each call will represent a maximal run of data. This is something that can also happen at arbitrary points in the input stream if feeding the parser object chunks of the input, which is commonly done if the input is large or comes from a network connection. To get the text content of an element, do something like this: class MyXMLParser(xmllib.XMLParser): __saving = 0 def start_ELEMENT(self, attrs): self.__saving = 1 self.__saved_text = '' def end_ELEMENT(self): text = self.__saved_text self.__saving = 0 # do something with text def handle_data(self, data): if self.__saving: self.__saved_text = self.__saved_text + data You may want to look at the implementations of save_bgn() and save_end() in htmllib.HTMLParser; similar utility methods may prove convenient and can be used to avoid a little ugliness and offer the facility to subclasses of your new class. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From ddula@atl.mediaone.net Wed Aug 25 19:02:53 1999 From: ddula@atl.mediaone.net (ddula@atl.mediaone.net) Date: Wed, 25 Aug 1999 14:02:53 -0400 (EDT) Subject: [Python-bugs-list] bug in time.sleep (PR#64) Message-ID: <199908251802.OAA19490@python.org> Full_Name: David Dula Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 Submission from: client42207.atl.mediaone.net (24.88.42.207) This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula From ddula@atl.mediaone.net Thu Aug 26 01:19:27 1999 From: ddula@atl.mediaone.net (ddula@atl.mediaone.net) Date: Wed, 25 Aug 1999 20:19:27 -0400 (EDT) Subject: [Python-bugs-list] bug in time.sleep (PR#65) Message-ID: <199908260019.UAA27487@python.org> >>Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) >>From: ddula@atl.mediaone.net >>To: bugs-py@python.org >>Subject: bug in time.sleep >>Full_Name: David Dula >>Version: 152c1 >>OS: Debian Alpha Linux (potato) 2.2.1 >>Submission from: client42207.atl.mediaone.net (24.88.42.207) >>his is a interesting bug that seems to have started after I upgraded to debian >>potato from slink. >>It must be a library related bug but this report might help somebody >>troubleshoot. >>At first I thought it was a bug in threading because it prevented the solaris >>hack sleep from returning >>thus my thread.start() never returned. >>But further digging show that >>import time >>time.sleep(0.1) # will always hang on on this platform >>Work around is to always sleep at least one second - I will do some more looking >>at the time class when I get a chance. This code shows it is the library that is broken. int main() { printf("%f\n",floor(0.100000)); } returns 36028797018963968.000000 So floor is broken. not a python bug sorry. I guess something is up with libm Dave Dula *-------------------------------------------------------------------------- Dave Dula ddula@atl.mediaone.net http://www.darkroom.cx Despite the cost of living, have you noticed how popular it remains? From maas@wanadoo.nl Thu Aug 26 15:09:15 1999 From: maas@wanadoo.nl (maas@wanadoo.nl) Date: Thu, 26 Aug 1999 10:09:15 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: pow(1l, 1l, 0l) seg. faults (PR#66) Message-ID: <199908261409.KAA15763@python.org> Full_Name: Maas-Maarten Zeeman Version: 1.5.1 and 1.5.2 OS: Linux, NT Submission from: vp213-34.worldonline.nl (195.241.213.34) There is no exception handler in the longobject.c module for this case. It is implemented in the intobject.c though. From andrew@fc.hp.com Thu Aug 26 21:20:04 1999 From: andrew@fc.hp.com (andrew@fc.hp.com) Date: Thu, 26 Aug 1999 16:20:04 -0400 (EDT) Subject: [Python-bugs-list] urllib.URLopener does not work with proxies (PR#67) Message-ID: <199908262020.QAA27493@python.org> Full_Name: Andrew Patterson Version: 1.5.1 OS: Submission from: pintoos.fc.hp.com (15.254.49.3) When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and calling urllib.openurl(), you get the following error message: File "./watchdog.py", line 118, in main url.open(urltocheck) File "/usr/lib/python1.5/urllib.py", line 158, in open return getattr(self, name)(url) File "/usr/lib/python1.5/urllib.py", line 258, in open_http return addinfourl(fp, headers, "http:" + url) TypeError: illegal argument type for built-in operation When using explicti proxies, url is a tuple instead of a string. You can't concatanate a tuple to a string, so the operation fails. From bradenja@pa.msu.edu Mon Aug 30 04:25:13 1999 From: bradenja@pa.msu.edu (bradenja@pa.msu.edu) Date: Sun, 29 Aug 1999 23:25:13 -0400 (EDT) Subject: [Python-bugs-list] trouble with _tkinter.c (PR#68) Message-ID: <199908300325.XAA05269@python.org> Full_Name: Jazcek Braden Version: 1.5b2 OS: Digital Unix Submission from: bradenja.user.msu.edu (35.10.24.28) I had install Tcl/Tk version 8.0.5 and when I went to compile python with tcl module support, I kept getting an ld error that Tcl_GetFile info was undefined. I edited the modules/_tkinter.c and changed line 113 from #define MAKEFHANDLE(fd) Tcl_GetFile((ClientData)(fd), FHANDLETYPE) to #define MAKEFHANDLE(fd) Tcl_GetFileInfo((ClientData)(fd), FHANDLETYPE) and this seemed to let it work hopefully this is the context for which it was intended From jlim@natsoft.com.my Mon Aug 30 09:19:59 1999 From: jlim@natsoft.com.my (jlim@natsoft.com.my) Date: Mon, 30 Aug 1999 04:19:59 -0400 (EDT) Subject: [Python-bugs-list] smtplib putcmd space+CRLF bug (PR#69) Message-ID: <199908300819.EAA15776@python.org> Full_Name: John Lim Version: 1.5.2 OS: Win95 and WinNT Submission from: bkj-cache81.jaring.my (161.142.78.81) This bug was first found by Sonny Soh (sonny@natsoft.com.my). We think we have found a bug in "smtplib.py". In this library, every SMTP command has a space and CRLF appended to it. We have connected to the VPOP3 pop server, and it refuses to accept commands sent from smtplib.py. The problem appears to be because of the space between the DATA command and the CRLF.So we did a small modification in smtplib.py, to remove that particular SPACE. Old SMTP command in smtplib.py: DATA \r\n New SMTP command after patch. This is how Netscape Messager and Outlook Express sends commands too: DATA\r\n vpop3 download page : http://www.pscs.co.uk/software/vpop3.html Suggested fix is to add the following line: 234a235 > if str[len(str)-3:] == ' '+ CRLF: str = str[:len(str)-3]+CRLF In context: def putcmd(self, cmd, args=""): """Send a command to the server.""" str = '%s %s%s' % (cmd, args, CRLF) if str[len(str)-3:] == ' '+ CRLF: str = str[:len(str)-3]+CRLF self.send(str) From guido@CNRI.Reston.VA.US Mon Aug 30 16:13:55 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 30 Aug 1999 11:13:55 -0400 Subject: [Python-bugs-list] smtplib putcmd space+CRLF bug (PR#69) In-Reply-To: Your message of "Mon, 30 Aug 1999 04:19:59 EDT." <199908300819.EAA15776@python.org> References: <199908300819.EAA15776@python.org> Message-ID: <199908301513.LAA07204@eric.cnri.reston.va.us> > We think we have found a bug in "smtplib.py". In this library, every > SMTP command has a space and CRLF appended to it. We have connected > to the VPOP3 pop server, and it refuses to accept commands sent from > smtplib.py. The problem appears to be because of the space between > the DATA command and the CRLF. This has already been fixed in the CVS tree (see http://www.python.org/download/cvs.html). This is the patch: Index: smtplib.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/smtplib.py,v retrieving revision 1.17 retrieving revision 1.18 diff -c -r1.17 -r1.18 *** smtplib.py 1999/04/21 16:52:20 1.17 --- smtplib.py 1999/06/09 15:13:10 1.18 *************** *** 231,237 **** def putcmd(self, cmd, args=""): """Send a command to the server.""" ! str = '%s %s%s' % (cmd, args, CRLF) self.send(str) def getreply(self): --- 231,240 ---- def putcmd(self, cmd, args=""): """Send a command to the server.""" ! if args == "": ! str = '%s%s' % (cmd, CRLF) ! else: ! str = '%s %s%s' % (cmd, args, CRLF) self.send(str) def getreply(self): *************** *** 345,352 **** """SMTP 'mail' command -- begins mail xfer session.""" optionlist = '' if options and self.does_esmtp: ! optionlist = string.join(options, ' ') ! self.putcmd("mail", "FROM:%s %s" % (quoteaddr(sender) ,optionlist)) return self.getreply() def rcpt(self,recip,options=[]): --- 348,355 ---- """SMTP 'mail' command -- begins mail xfer session.""" optionlist = '' if options and self.does_esmtp: ! optionlist = ' ' + string.join(options, ' ') ! self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender) ,optionlist)) return self.getreply() def rcpt(self,recip,options=[]): --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Aug 30 16:14:38 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 30 Aug 1999 11:14:38 -0400 (EDT) Subject: [Python-bugs-list] smtplib putcmd space+CRLF bug (PR#69) Message-ID: <199908301514.LAA23849@python.org> > We think we have found a bug in "smtplib.py". In this library, every > SMTP command has a space and CRLF appended to it. We have connected > to the VPOP3 pop server, and it refuses to accept commands sent from > smtplib.py. The problem appears to be because of the space between > the DATA command and the CRLF. This has already been fixed in the CVS tree (see http://www.python.org/download/cvs.html). This is the patch: Index: smtplib.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/smtplib.py,v retrieving revision 1.17 retrieving revision 1.18 diff -c -r1.17 -r1.18 *** smtplib.py 1999/04/21 16:52:20 1.17 --- smtplib.py 1999/06/09 15:13:10 1.18 *************** *** 231,237 **** def putcmd(self, cmd, args=""): """Send a command to the server.""" ! str = '%s %s%s' % (cmd, args, CRLF) self.send(str) def getreply(self): --- 231,240 ---- def putcmd(self, cmd, args=""): """Send a command to the server.""" ! if args == "": ! str = '%s%s' % (cmd, CRLF) ! else: ! str = '%s %s%s' % (cmd, args, CRLF) self.send(str) def getreply(self): *************** *** 345,352 **** """SMTP 'mail' command -- begins mail xfer session.""" optionlist = '' if options and self.does_esmtp: ! optionlist = string.join(options, ' ') ! self.putcmd("mail", "FROM:%s %s" % (quoteaddr(sender) ,optionlist)) return self.getreply() def rcpt(self,recip,options=[]): --- 348,355 ---- """SMTP 'mail' command -- begins mail xfer session.""" optionlist = '' if options and self.does_esmtp: ! optionlist = ' ' + string.join(options, ' ') ! self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender) ,optionlist)) return self.getreply() def rcpt(self,recip,options=[]): --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Aug 30 16:17:10 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 30 Aug 1999 11:17:10 -0400 Subject: [Python-bugs-list] trouble with _tkinter.c (PR#68) In-Reply-To: Your message of "Sun, 29 Aug 1999 23:25:13 EDT." <199908300325.XAA05269@python.org> References: <199908300325.XAA05269@python.org> Message-ID: <199908301517.LAA07216@eric.cnri.reston.va.us> > I had install Tcl/Tk version 8.0.5 and when I went to compile python with tcl > module support, I kept getting an ld error that Tcl_GetFile info was undefined. > I edited the modules/_tkinter.c and changed line 113 from > #define MAKEFHANDLE(fd) Tcl_GetFile((ClientData)(fd), FHANDLETYPE) > to > #define MAKEFHANDLE(fd) Tcl_GetFileInfo((ClientData)(fd), FHANDLETYPE) > > and this seemed to let it work hopefully this is the context for which it was > intended Actually, that line is inside #if TKMAJORMINOR < 8000 ... #else; which means it was not supposed to be triggered when you are using Tk 8.0.5 as you say. The most common cause for this is having an old tk.h header file lying around on your system. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Aug 30 16:17:29 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 30 Aug 1999 11:17:29 -0400 (EDT) Subject: [Python-bugs-list] trouble with _tkinter.c (PR#68) Message-ID: <199908301517.LAA24012@python.org> > I had install Tcl/Tk version 8.0.5 and when I went to compile python with tcl > module support, I kept getting an ld error that Tcl_GetFile info was undefined. > I edited the modules/_tkinter.c and changed line 113 from > #define MAKEFHANDLE(fd) Tcl_GetFile((ClientData)(fd), FHANDLETYPE) > to > #define MAKEFHANDLE(fd) Tcl_GetFileInfo((ClientData)(fd), FHANDLETYPE) > > and this seemed to let it work hopefully this is the context for which it was > intended Actually, that line is inside #if TKMAJORMINOR < 8000 ... #else; which means it was not supposed to be triggered when you are using Tk 8.0.5 as you say. The most common cause for this is having an old tk.h header file lying around on your system. --Guido van Rossum (home page: http://www.python.org/~guido/)