JVM1.3 - Python SimpleHTTPServer Test

From 24Rk@earthlink.net Tue May 2 07:04:13 2000 From: 24Rk@earthlink.net (24Rk@earthlink.net) Date: Tue, 2 May 2000 02:04:13 -0400 (EDT) Subject: [Python-bugs-list] Hello High School Alumni (PR#310) Message-ID: <20000502060413.325491CD46@dinsdale.python.org> Dear High School Alumni, This email is to inform you of a new website that allows you to stay in touch with your high school friends. www.tdyalumni.com Wouldn't it be great to surprise an old friend with an email. Spark up that old friendship, see what the captain of the football team is up to today, find out if the prom queen is still all that. Go to www.tdyalumni.com and contact them now! This is the number one site for contacting high school alumni. The Digital Yearbook allows you to create your own personal page, which mcan include now and then photos, yearbook pages, group/team photos, or your own collage of photos. With over 25,000 schools listed on The Digital Yearbook you are able to not only stay in touch with friends from your high school, but you are also able to rekindle friendships with people you meet from any other high school in the United States. If you would like to be removed from this automated mailing list please CLICK HERE. From weage98@yahoo.com Tue May 2 21:52:02 2000 From: weage98@yahoo.com (weage98@yahoo.com) Date: Tue, 2 May 2000 16:52:02 -0400 (EDT) Subject: [Python-bugs-list] Tkinter & listbox (PR#311) Message-ID: <20000502205202.A780E1CDA3@dinsdale.python.org> Full_Name: Joshua Weage Version: 1.5.2 OS: HP-UX 10.20 & gcc Submission from: hybrid-024-221-068-135.detroit.speedchoice.com (24.221.68.135) This may actually be a bug with Tk, but I'm not absolutely sure. When I place two listboxes in the same window, using selectmode="browse" on each, a selection in the second listbox clears the first, and vice versa. From guido@python.org Tue May 2 22:08:08 2000 From: guido@python.org (guido@python.org) Date: Tue, 2 May 2000 17:08:08 -0400 (EDT) Subject: [Python-bugs-list] Tkinter & listbox (PR#311) Message-ID: <20000502210808.8B2E21CDB9@dinsdale.python.org> > This may actually be a bug with Tk, but I'm not absolutely sure. > > When I place two listboxes in the same window, using selectmode="browse" on > each, a selection in the second listbox clears the first, and vice versa. It's an obscure Tk feature. Turn off the "exportselection" option for both listboxes. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed May 3 16:58:25 2000 From: guido@python.org (guido@python.org) Date: Wed, 3 May 2000 11:58:25 -0400 (EDT) Subject: [Python-bugs-list] time.sleep() and threading (PR#307) Message-ID: <20000503155825.D6EB71CD93@dinsdale.python.org> > python .../test/test_thread.py shows that time.sleep() > does not relinquish the processor. > As one thread goes to sleep, another thread ought > to start processing. That doesn't happen. > > Python was configured with --with-thread > and compiler flags -mt and -D_REENTRANT. > See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g > > EXAMPLE: > > hce* python test_thread.py > creating task 1 > creating task 2 > creating task 3 > creating task 4 > creating task 5 > creating task 6 > creating task 7 > creating task 8 > creating task 9 > creating task 10 > waiting for all tasks to complete > task 1 will run for 9.9 sec # goes to sleep here... > task 1 done # 9.9 seconds later... > task 5 will run for 4.1 sec # This should have started when task 1 slept. > task 5 done > task 7 will run for 9.9 sec > task 7 done > task 4 will run for 9.2 sec > task 4 done > task task 6 will run for 7.7 sec Hm... It works correctly for me on Solaris 7 compiled with gcc, using either Solaris threads or Posix threads. I wonder if this could have something to do with the compiler you are using? (Are you using the SunPro compiler?) There's not much I can do about this right now, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) From aliberi@acutronic.com Thu May 4 14:08:24 2000 From: aliberi@acutronic.com (aliberi@acutronic.com) Date: Thu, 4 May 2000 09:08:24 -0400 (EDT) Subject: [Python-bugs-list] SimpleHTTPServer hangs browser? (PR#312) Message-ID: <20000504130824.131B61CD46@dinsdale.python.org> Full_Name: Armand Liberi Version: 1.5.2 OS: LynxOS, Windows NT4SP6 Submission from: c196.acutronic.nauticom.net (209.195.177.196) This reprot has also been sent to Sun. Running SimpleHTTPServer on either LynxOS or Windows NT4SP6, a. Compile a java class named Test, such as: ---------------------------------------- import java.applet.*; import java.awt.*; import java.awt.event.*; public class Test extends Applet { public void init() { Label label = new Label("Swing!"); add(label, BorderLayout.CENTER); } } ---------------------------------------- b. Create an HTML file that uses the above class: ---------------------------------------- JVM1.3 - Python SimpleHTTPServer Test

---------------------------------------- c. Install the HTML and class files into the Python HTTP web. d. Using Internet Explorer 5.01, address the HTML. The HTML page will load and the browser will hang. Sometimes, it can be exited normally; most times, it will require more drastic measures. e. Using Netscape Navigator 4.72, the browser will hang with the message "Host .. contacted. Waiting for reply" in the status bar. When "Reload" is clicked, the applet will run. f. Java console displays: ---------------------------------------- Java(TM) Plug-in: Version 1.3.0rc2-Y Using JRE version 1.3.0rc2 Java HotSpot(TM) Client VM User home directory = C:\WINNT\Profiles\Armand Proxy Configuration: no proxy JAR cache enabled. ---------------------------------------- From guido@python.org Thu May 4 14:31:32 2000 From: guido@python.org (guido@python.org) Date: Thu, 4 May 2000 09:31:32 -0400 (EDT) Subject: [Python-bugs-list] SimpleHTTPServer hangs browser? (PR#312) Message-ID: <20000504133132.79AE41CD5E@dinsdale.python.org> I haven't run your example, but my guess is that the SimpleHTTPServer class only handles one request at a time. It'c conceivable that the browser tries to send the request for the applet before it is done with the main page. You could try to create a threading or forking subclass of SimpleHTTPServer, like so: import SocketServer, SimpleHTTPServer, BaseHTTPServer class MyServer(SocketServer.ForkingMixIn, BaseHTTPServer.HTTPServer): pass and substitute that for BaseHTTPServer.HTTPServer. --Guido van Rossum (home page: http://www.python.org/~guido/) From loewis@informatik.hu-berlin.de Thu May 4 14:54:14 2000 From: loewis@informatik.hu-berlin.de (loewis@informatik.hu-berlin.de) Date: Thu, 4 May 2000 09:54:14 -0400 (EDT) Subject: [Python-bugs-list] dl.RTLD_GLOBAL missing (PR#313) Message-ID: <20000504135414.D7CFA1CD68@dinsdale.python.org> Full_Name: Martin v. Loewis Version: 1.5.2 OS: Solaris Submission from: pandora.informatik.hu-berlin.de (141.20.23.176) The dl module does not support all flags to dlopen available on a specific system; eg. dl.open("foo.so",dl.RTLD_GLOBAL) does not work. On Solaris, the following constants are defined, in addition RTLD_NOLOAD RTLD_GLOBAL RTLD_LOCAL RTLD_PARENT RTLD_GROUP RTLD_WORLD RTLD_NODELETE From cba@mediaone.net Thu May 4 21:09:39 2000 From: cba@mediaone.net (cba@mediaone.net) Date: Thu, 4 May 2000 16:09:39 -0400 (EDT) Subject: [Python-bugs-list] urllib case sensitivity to proxy settings (PR#314) Message-ID: <20000504200939.69A3B1CDD5@dinsdale.python.org> Full_Name: Craig Allen Version: 1.5.2 OS: Windows NT 4.0 SP5 Submission from: h008019359a34.ne.mediaone.net (24.218.255.199) For urllib, the _case_ of the protocol defined for the proxy makes a difference: set http_proxy=http://http-proxy:6080/ - works! set http_proxy=HTTP://http_proxy:6080/ - does not work! It says (in RFC 1738) Scheme names consist of a sequence of characters. The lower case letters "a"--"z", digits, and the characters plus ("+"), period ("."), and hyphen ("-") are allowed. For resiliency, programs interpreting URLs should treat upper case letters as equivalent to lower case in scheme names (e.g., allow "HTTP" as well as "http"). From tdickenson@geminidataloggers.com Fri May 5 10:50:39 2000 From: tdickenson@geminidataloggers.com (tdickenson@geminidataloggers.com) Date: Fri, 5 May 2000 05:50:39 -0400 (EDT) Subject: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Message-ID: <20000505095039.AB9D31CDB2@dinsdale.python.org> Full_Name: Toby Dickenson Version: 1.5.2 OS: Windows Submission from: mailhost.oriongroup.co.uk (194.200.199.161) There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m From mhammond@skippinet.com.au Fri May 5 14:19:14 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 5 May 2000 23:19:14 +1000 Subject: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) In-Reply-To: <20000505095039.AB9D31CDB2@dinsdale.python.org> Message-ID: > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. From mhammond@skippinet.com.au Fri May 5 14:19:57 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Fri, 5 May 2000 09:19:57 -0400 (EDT) Subject: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Message-ID: <20000505131957.BA0921CE0D@dinsdale.python.org> > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. From sdn@isc.upenn.edu Fri May 5 21:06:16 2000 From: sdn@isc.upenn.edu (sdn@isc.upenn.edu) Date: Fri, 5 May 2000 16:06:16 -0400 (EDT) Subject: [Python-bugs-list] mailbox module not outputting a full rfc822 format message (PR#316) Message-ID: <20000505200616.0E0281CDB6@dinsdale.python.org> Full_Name: Samuel Nicolary Version: 1.5.2 OS: Tru64 4.0F Submission from: obelisk.gse.upenn.edu (165.123.82.104) When the mailbox module passes a message section of an mbox format file to the rfc822 module for instanciation it leaves out line 1 or the "From " line. I don't know if it is supposed to do this but I need that info from my rfc822 instance (m.unixfrom). Otherwise, it is always empty. I made a fix for my install. Changes/additions have arrows. Don't laugh. I am new to python. from the _Mailbox class: def next(self): while 1: self.fp.seek(self.seekp) try: -------> offset = self._search_start() except EOFError: self.seekp = self.fp.tell() return None start = self.fp.tell() self._search_end() self.seekp = stop = self.fp.tell() if start <> stop: break -------> return rfc822.Message(_Subfile(self.fp, start-offset, stop)) from the UnixMailbox class def _search_start(self): while 1: line = self.fp.readline() if not line: raise EOFError if line[:5] == 'From ' and self._isrealfromline(line): -------> return len(line) I tried to do a pos = self.fp.tell() right after the while statement in the _search_start and then upon a success if line[:5] == 'From ' ... condition to do a self.fp.seek(pos) to avoid this clumsy solution but I just got a recursive loop and I couldn't figure out why so left in the clumsy that worked. From guido@python.org Fri May 5 21:29:06 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 05 May 2000 16:29:06 -0400 Subject: [Python-bugs-list] mailbox module not outputting a full rfc822 format message (PR#316) In-Reply-To: Your message of "Fri, 05 May 2000 16:06:16 EDT." <20000505200616.0E0281CDB6@dinsdale.python.org> References: <20000505200616.0E0281CDB6@dinsdale.python.org> Message-ID: <200005052029.QAA14814@eric.cnri.reston.va.us> > When the mailbox module passes a message section of an mbox format file to the > rfc822 module for instanciation it leaves out line 1 or the "From " > line. This was recently fixed in the CVS version, Python 1.6a2 should have the fix too. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri May 5 21:29:10 2000 From: guido@python.org (guido@python.org) Date: Fri, 5 May 2000 16:29:10 -0400 (EDT) Subject: [Python-bugs-list] mailbox module not outputting a full rfc822 format message (PR#316) Message-ID: <20000505202910.EBF171CDAC@dinsdale.python.org> > When the mailbox module passes a message section of an mbox format file to the > rfc822 module for instanciation it leaves out line 1 or the "From " > line. This was recently fixed in the CVS version, Python 1.6a2 should have the fix too. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr@thyrsus.com Fri May 5 21:50:05 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Fri, 5 May 2000 16:50:05 -0400 (EDT) Subject: [Python-bugs-list] Core dump in the read side of cPickle (PR#317) Message-ID: <20000505205005.66CC91CDA6@dinsdale.python.org> Full_Name: Eric S. Raymond Version: 1.5.2 OS: Linux Submission from: snark.tuxedo.org (207.106.50.26) I have generated a pickled object that causes cPickle to core-dump while attempting to load it. The pickle module reads it without trouble. To reproduce, fetch ftp://ftp.ccil.org/pub/esr/cml2-coredump.tar.gz, unpack it, and follow the instructions in BUG-README. From formations@ukdata.com Tue May 9 15:13:14 2000 From: formations@ukdata.com (formations@ukdata.com) Date: Tue, 9 May 2000 10:13:14 -0400 (EDT) Subject: [Python-bugs-list] Instant Financial Data on every UK Business www.ukdata.com (PR#318) Message-ID: <20000509141314.BE4301CEAA@dinsdale.python.org> Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies From charlie@ukdata.com Tue May 9 16:52:53 2000 From: charlie@ukdata.com (charlie@ukdata.com) Date: Tue, 9 May 2000 11:52:53 -0400 (EDT) Subject: [Python-bugs-list] UK Company Formations www.formacompany.co.uk (PR#319) Message-ID: <20000509155253.4CDE71CEB5@dinsdale.python.org> Do you need a company registered in the UK. Please visit www.formacompany.co.uk where you can form your new company on-line for only �98 Thank you Maureen Cavely www.formacompany.co.uk From fdrake@acm.org Tue May 9 19:23:55 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 9 May 2000 14:23:55 -0400 (EDT) Subject: [Python-bugs-list] wording confusion in API doc (PR#285) In-Reply-To: <20000410202126.232891CD7F@dinsdale.python.org> References: <20000410202126.232891CD7F@dinsdale.python.org> Message-ID: <14616.22459.12404.18064@seahag.cnri.reston.va.us> skip@mojam.com writes: > I think it's supposed to be > > Conversely, when a calling function passes it a reference ... Skip, Yes; I've made your correction in my working copy, but won't check it in until I've finished some other things I've started adding to the document. Thanks! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue May 9 19:22:34 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 9 May 2000 14:22:34 -0400 (EDT) Subject: [Python-bugs-list] wording confusion in API doc (PR#285) Message-ID: <20000509182234.AF2461CEEA@dinsdale.python.org> skip@mojam.com writes: > I think it's supposed to be > > Conversely, when a calling function passes it a reference ... Skip, Yes; I've made your correction in my working copy, but won't check it in until I've finished some other things I've started adding to the document. Thanks! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From greg@wildbrain.com Tue May 9 23:35:12 2000 From: greg@wildbrain.com (greg@wildbrain.com) Date: Tue, 9 May 2000 18:35:12 -0400 (EDT) Subject: [Python-bugs-list] "import sys" missing in shutil.py (PR#320) Message-ID: <20000509223512.19BF81CEF7@dinsdale.python.org> Full_Name: Gregory Brauer Version: 1.5.2 OS: IRIX/Linux Submission from: 40320f82.ptr.dia.nextlink.net (64.50.15.130) Problem: Line 111 of shutil.py in the standard distribution references the "sys" module. "sys" is never included in the shutil module, however, and will cause a NameError if this line is executed. Solution: Insert at line 9: import sys From guido@python.org Wed May 10 00:34:52 2000 From: guido@python.org (guido@python.org) Date: Tue, 9 May 2000 19:34:52 -0400 (EDT) Subject: [Python-bugs-list] "import sys" missing in shutil.py (PR#320) Message-ID: <20000509233452.B49EB1CEFB@dinsdale.python.org> > Full_Name: Gregory Brauer > Version: 1.5.2 > OS: IRIX/Linux > Submission from: 40320f82.ptr.dia.nextlink.net (64.50.15.130) > > > Problem: > > Line 111 of shutil.py in the standard distribution references > the "sys" module. "sys" is never included in the shutil module, > however, and will cause a NameError if this line is executed. > > Solution: > Insert at line 9: > > import sys This was fixed before Python 1.5.2 was released. Maybe you're still using a beta version? --Guido van Rossum (home page: http://www.python.org/~guido/) From urracht@home.com Wed May 10 02:46:33 2000 From: urracht@home.com (urracht@home.com) Date: Tue, 9 May 2000 21:46:33 -0400 (EDT) Subject: [Python-bugs-list] time.sleep() interferes with time.clock() (PR#321) Message-ID: <20000510014633.F06CB1CF0A@dinsdale.python.org> Full_Name: Steven Brooks Version: 1.5.2 OS: Linux Submission from: cd834592-a.ctjams1.mb.wave.home.com (24.108.113.70) Test Case: import time for i in range(100000): time.sleep(1) ; print time.clock() Expected Behaviour: clock() should increment by 1 after each call to sleep() Actual Behaviour: clock() does not seem to increment at all! Output: 0.07 0.07 0.07 0.07 0.07 (etc. etc.) This is either a bug, or a documentation error. The library manual does not seem to say or imply that time.sleep() should interfere with time.clock(). Thanks, Steven From guido@python.org Wed May 10 03:30:01 2000 From: guido@python.org (guido@python.org) Date: Tue, 9 May 2000 22:30:01 -0400 (EDT) Subject: [Python-bugs-list] time.sleep() interferes with time.clock() (PR#321) Message-ID: <20000510023001.C897E1CF0D@dinsdale.python.org> > Full_Name: Steven Brooks > Version: 1.5.2 > OS: Linux > Submission from: cd834592-a.ctjams1.mb.wave.home.com (24.108.113.70) > > > Test Case: > import time > for i in range(100000): time.sleep(1) ; print time.clock() > > Expected Behaviour: > clock() should increment by 1 after each call to sleep() > > Actual Behaviour: > clock() does not seem to increment at all! > > Output: > 0.07 > 0.07 > 0.07 > 0.07 > 0.07 > (etc. etc.) > > This is either a bug, or a documentation error. The library manual does > not seem to say or imply that time.sleep() should interfere with time.clock(). It's not a bug. On Unix, clock() counts "CPU time", and a sleep doesn't increment the CPU time (the CPU is given to another process). On Windows, clock() *does* count real time -- there's no sufficiently accurate CPU time available on that platform. The documentation (http://www.python.org/doc/current/lib/module-time.html) does mention CPU-time -- so I'm not sure what you want changed? --Guido van Rossum (home page: http://www.python.org/~guido/) From wora2002@yahoo.com Wed May 10 06:21:28 2000 From: wora2002@yahoo.com (wora2002@yahoo.com) Date: Wed, 10 May 2000 01:21:28 -0400 (EDT) Subject: [Python-bugs-list] linuxthreads lock failed (PR#322) Message-ID: <20000510052128.AB5D01CF26@dinsdale.python.org> Full_Name: Hong Zhang Version: 1.5.2 OS: Linux Submission from: 207-168-83-227.gw.eni.net (207.168.83.227) I am writing a multi-threaded python problem on linux. And the program consistently hang after 24 hours. From the debugger, I can see the linuxthreads pthread condvar waiting list is cyclic, and I believe the specific lock is the "tcl_lock". I guess the bug may related to signal handling or some race condition. hong From andrew@intertrader.com Wed May 10 17:37:45 2000 From: andrew@intertrader.com (andrew@intertrader.com) Date: Wed, 10 May 2000 12:37:45 -0400 (EDT) Subject: [Python-bugs-list] Ctrl-Z confuses readline on NT (PR#323) Message-ID: <20000510163745.5A2ED1CD37@dinsdale.python.org> Full_Name: Andrew Cooke Version: 1.5.2 OS: NT 4 Submission from: (NULL) (212.20.229.254) Hi, This may not be a Python bug, in that it probably reflects ancient MSDOS conventions that live on inside NT, but I would expect (hope?) Python to work round it... When reading a file (a mail spool file in some strange format) via a file object, using readline, Ctrl-Z caused serious problems: - in the midle of a line, the rest of the line was not read - at the start of a line, it was taken as EOF I tried searching on the bugs dbase (as I guess this is already known, but found nothing under "Control Z" etc). Once I realised the problem, it was easy to fix of course - so if there is no work-round for Python, maybe it could be mentioned in the docs? It might save someone else an hour or two... Cheers, Andrew From guido@python.org Wed May 10 17:47:33 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 10 May 2000 12:47:33 -0400 Subject: [Python-bugs-list] Ctrl-Z confuses readline on NT (PR#323) In-Reply-To: Your message of "Wed, 10 May 2000 12:37:45 EDT." <20000510163745.5A2ED1CD37@dinsdale.python.org> References: <20000510163745.5A2ED1CD37@dinsdale.python.org> Message-ID: <200005101647.MAA28883@eric.cnri.reston.va.us> > This may not be a Python bug, in that it probably reflects ancient > MSDOS conventions that live on inside NT, but I would expect (hope?) > Python to work round it... > > When reading a file (a mail spool file in some strange format) via a > file object, using readline, Ctrl-Z caused serious problems: > > - in the midle of a line, the rest of the line was not read > - at the start of a line, it was taken as EOF > > I tried searching on the bugs dbase (as I guess this is already > known, but found nothing under "Control Z" etc). > > Once I realised the problem, it was easy to fix of course - so if there > is no work-round for Python, maybe it could be mentioned in the docs? > It might save someone else an hour or two... The stdandard I/O library is "helping". Use open(filename, "rb") to open the file in binary mode. You will have to deal with CRLF yourself then, but ^Z will be a regular plain data character. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed May 10 17:50:57 2000 From: guido@python.org (guido@python.org) Date: Wed, 10 May 2000 12:50:57 -0400 (EDT) Subject: [Python-bugs-list] Ctrl-Z confuses readline on NT (PR#323) Message-ID: <20000510165057.D7C801CD3D@dinsdale.python.org> > This may not be a Python bug, in that it probably reflects ancient > MSDOS conventions that live on inside NT, but I would expect (hope?) > Python to work round it... > > When reading a file (a mail spool file in some strange format) via a > file object, using readline, Ctrl-Z caused serious problems: > > - in the midle of a line, the rest of the line was not read > - at the start of a line, it was taken as EOF > > I tried searching on the bugs dbase (as I guess this is already > known, but found nothing under "Control Z" etc). > > Once I realised the problem, it was easy to fix of course - so if there > is no work-round for Python, maybe it could be mentioned in the docs? > It might save someone else an hour or two... The stdandard I/O library is "helping". Use open(filename, "rb") to open the file in binary mode. You will have to deal with CRLF yourself then, but ^Z will be a regular plain data character. --Guido van Rossum (home page: http://www.python.org/~guido/) From Thomas.Malik@t-online.de Wed May 10 20:37:30 2000 From: Thomas.Malik@t-online.de (Thomas.Malik@t-online.de) Date: Wed, 10 May 2000 15:37:30 -0400 (EDT) Subject: [Python-bugs-list] bug in PyLong_FromLongLong (PR#324) Message-ID: <20000510193730.E651F1CD11@dinsdale.python.org> Full_Name: Thomas Malik Version: 1.5.2 OS: all Submission from: p3e9ed447.dip.t-dialin.net (62.158.212.71) there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. From kislo@athenium.com Wed May 10 22:08:59 2000 From: kislo@athenium.com (kislo@athenium.com) Date: Wed, 10 May 2000 17:08:59 -0400 (EDT) Subject: [Python-bugs-list] Floating Poiint Integer precision lost (PR#325) Message-ID: <20000510210859.9B3181CD13@dinsdale.python.org> Full_Name: Joe Kislo Version: Python 1.5.2 (#1, Feb 18 2000, 11:28:06) [GCC egcs-2.91.66 19990314/Linux OS: Linux 2.2 and Solaris OS 7 SPARC Submission from: houseatreides.ne.mediaone.net (24.128.32.113) Uhh, this doesn't seem to work on any platform I try it on. Linux or solaris/sparc. If you could email me back at kislo@athenium.com the status of this bug, that would be great. >>> (float("75.02")%1)*100 2.0 >>> i = (float("75.02")%1)*100 >>> int(i) 1 >>> i 2.0 >>> int(2.0) 2 >>> float(int(float(i))) 1.0 >>> int(float(2.0)) 2 >>> int(float(str(i))) 2 From tim_one@email.msn.com Thu May 11 04:03:54 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 10 May 2000 23:03:54 -0400 Subject: [Python-bugs-list] Floating Poiint Integer precision lost (PR#325) In-Reply-To: <20000510210859.9B3181CD13@dinsdale.python.org> Message-ID: <000701bfbaf5$8a9c0da0$2aa0143f@tim> Joe, I'm afraid this isn't a bug: Python floats use binary floating-point, 75.02 is not exactly representable in binary floating-point, so 75.02%1 isn't exactly 0.02 either, so that times 100 isn't exactly 2, etc etc. You'll get the same results using C, C++, Java, Fortran, Perl, ... anything that, like Python, uses native floating-point arithmetic. However, under 1.5.2 the default display format used at the interactive prompt hides the inaccuracy from you, by rounding away the inaccurate bits for (& only for) display purposes. The cause of the problem is clearer under 1.6a2 (the latest alpha release of Python 1.6), which boosts the number of digits displayed: Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam IDLE 0.5 -- press F1 for help>>> (float("75.02")%1)*100 >>> (float("75.02")%1)*100 1.9999999999996021 >>> i = (float("75.02")%1)*100 >>> i 1.9999999999996021 >>> int(2.0) 2 >>> float(int(float(i))) 1.0 >>> int(float(2.0)) 2 >>> int(float(str(i))) 2 >>> int(float(repr(i))) 1 >>> > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > kislo@athenium.com > Sent: Wednesday, May 10, 2000 5:09 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Floating Poiint Integer precision lost > (PR#325) > > > Full_Name: Joe Kislo > Version: Python 1.5.2 (#1, Feb 18 2000, 11:28:06) [GCC > egcs-2.91.66 19990314/Linux > OS: Linux 2.2 and Solaris OS 7 SPARC > Submission from: houseatreides.ne.mediaone.net (24.128.32.113) > > > Uhh, this doesn't seem to work on any platform I try it on. Linux or > solaris/sparc. > > If you could email me back at kislo@athenium.com the status of > this bug, that > would be great. > > >>> (float("75.02")%1)*100 > 2.0 > >>> i = (float("75.02")%1)*100 > >>> int(i) > 1 > >>> i > 2.0 > >>> int(2.0) > 2 > >>> float(int(float(i))) > 1.0 > >>> int(float(2.0)) > 2 > >>> int(float(str(i))) > 2 > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From tim_one@email.msn.com Thu May 11 04:04:13 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 10 May 2000 23:04:13 -0400 (EDT) Subject: [Python-bugs-list] Floating Poiint Integer precision lost (PR#325) Message-ID: <20000511030413.3A4E71CD13@dinsdale.python.org> Joe, I'm afraid this isn't a bug: Python floats use binary floating-point, 75.02 is not exactly representable in binary floating-point, so 75.02%1 isn't exactly 0.02 either, so that times 100 isn't exactly 2, etc etc. You'll get the same results using C, C++, Java, Fortran, Perl, ... anything that, like Python, uses native floating-point arithmetic. However, under 1.5.2 the default display format used at the interactive prompt hides the inaccuracy from you, by rounding away the inaccurate bits for (& only for) display purposes. The cause of the problem is clearer under 1.6a2 (the latest alpha release of Python 1.6), which boosts the number of digits displayed: Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam IDLE 0.5 -- press F1 for help>>> (float("75.02")%1)*100 >>> (float("75.02")%1)*100 1.9999999999996021 >>> i = (float("75.02")%1)*100 >>> i 1.9999999999996021 >>> int(2.0) 2 >>> float(int(float(i))) 1.0 >>> int(float(2.0)) 2 >>> int(float(str(i))) 2 >>> int(float(repr(i))) 1 >>> > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > kislo@athenium.com > Sent: Wednesday, May 10, 2000 5:09 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Floating Poiint Integer precision lost > (PR#325) > > > Full_Name: Joe Kislo > Version: Python 1.5.2 (#1, Feb 18 2000, 11:28:06) [GCC > egcs-2.91.66 19990314/Linux > OS: Linux 2.2 and Solaris OS 7 SPARC > Submission from: houseatreides.ne.mediaone.net (24.128.32.113) > > > Uhh, this doesn't seem to work on any platform I try it on. Linux or > solaris/sparc. > > If you could email me back at kislo@athenium.com the status of > this bug, that > would be great. > > >>> (float("75.02")%1)*100 > 2.0 > >>> i = (float("75.02")%1)*100 > >>> int(i) > 1 > >>> i > 2.0 > >>> int(2.0) > 2 > >>> float(int(float(i))) > 1.0 > >>> int(float(2.0)) > 2 > >>> int(float(str(i))) > 2 > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From dwallace@udel.edu Thu May 11 15:22:14 2000 From: dwallace@udel.edu (dwallace@udel.edu) Date: Thu, 11 May 2000 10:22:14 -0400 (EDT) Subject: [Python-bugs-list] configure fails to detect socklen_t on Linux (PR#326) Message-ID: <20000511142214.A938D1CD3F@dinsdale.python.org> Full_Name: Dave Wallace Version: 1.6 latest CVS as of Thu May 11 10:21:55 EDT 2000 OS: Linux 2.2.14 Submission from: mis119.mis.udel.edu (128.175.60.119) The test for the presence of a definition for "socklen_t" fails on Linux 2.2.14 (this is the only version I have tried it with) apparently the is not included by my . Not that I understand autoconf very well, but the configure.in line: AC_CHECK_TYPE(socklen_t, int) seems to be at fault, or perhaps the problem is with autoconf itself RedHat Linux 2.2.14 Autoconf version 2.13 RPMS: glibc-2.1.3-14 glibc-devel-2.1.3-14 From jon@dstc.edu.au Fri May 12 03:02:09 2000 From: jon@dstc.edu.au (jon@dstc.edu.au) Date: Thu, 11 May 2000 22:02:09 -0400 (EDT) Subject: [Python-bugs-list] Removal of thread.h (PR#327) Message-ID: <20000512020209.BE65A1CD36@dinsdale.python.org> Full_Name: Jonathan Giddy Version: 1.6 OS: Submission from: pitfall.dstc.monash.edu.au (130.194.228.100) I believe the jump in the minor version number for 1.6 is the right time to remove the redundant Include/thread.h, which mainly just includes pythread.h This wasn't done before because of the difficulty identifying micro version increments. A reminder that the problem with thread.h occurs when building Python extensions on Solaris for third-party packages that need to include the Solaris thread.h file. (see DejaNews for more info) From peter@verecomm.com Mon May 15 20:21:34 2000 From: peter@verecomm.com (peter@verecomm.com) Date: Mon, 15 May 2000 15:21:34 -0400 (EDT) Subject: [Python-bugs-list] XMLLIB, JPython and re (PR#328) Message-ID: <20000515192134.D21EC1CD6B@dinsdale.python.org> Full_Name: Peter Kropf Version: 1.52 OS: Linux Submission from: hades.svnetworks.com (209.237.16.146) There's a problem with the xmllib module when used with JPython. Specifically, the JPython re module has trouble with the () characters in strings passed into re.compile. Until the JPython folks fix the re module, I'd like to ask that the xmllib module be modified to escape the () characters. Here's the output from diff: $ diff xmllib.py /usr/lib/python1.5/ 29c29 < '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!_#=~]+))?') --- > '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!()_#=~]+))?') 45,46c45,46 < _PublicLiteral = '(?P<%s>"[-\'+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ < "'[-+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" --- > _PublicLiteral = '(?P<%s>"[-\'()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ > "'[-()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" Thanks! From donn@oz.net Tue May 16 07:47:34 2000 From: donn@oz.net (donn@oz.net) Date: Tue, 16 May 2000 02:47:34 -0400 (EDT) Subject: [Python-bugs-list] compile flags for BeOS in main configure (PR#329) Message-ID: <20000516064734.5C3431CDB6@dinsdale.python.org> Full_Name: Donn Cave Version: 1.6a2 OS: BeOS Submission from: sense-donn-169.oz.net (216.39.151.169) Compile options for Intel BeOS have been "-DUSE_DL_EXPORT -O3 -mpentium pro". This is too much for BeOS version 5.0, where python compiled this way has bugs (first line in structmodule.c:whichtable() comes out wrong.) Please change to "-DUSE_DL_EXPORT -O" Thanks! From donn@oz.net Tue May 16 07:56:46 2000 From: donn@oz.net (donn@oz.net) Date: Tue, 16 May 2000 02:56:46 -0400 (EDT) Subject: [Python-bugs-list] socketmodule.c: netinet/tcp.h, not on BeOS (PR#330) Message-ID: <20000516065646.E8D641CDB6@dinsdale.python.org> Full_Name: Donn Cave Version: 1.6a2 OS: BeOS 5.0 Submission from: sense-donn-169.oz.net (216.39.151.169) BeOS (up to 5.0) lacks . This is a low priority, in my opinion. Be has a major upgrade to their network support in the works presently, and this is just a stop-gap until then. I have no idea how long that's going to be, though! #include #include #include + #ifndef __BEOS__ #include + #endif /* Headers needed for inet_ntoa() and inet_addr() */ #ifdef __BEOS__ From fdrake@acm.org Tue May 16 14:31:58 2000 From: fdrake@acm.org (Fred L. Drake) Date: Tue, 16 May 2000 06:31:58 -0700 (PDT) Subject: [Python-bugs-list] socketmodule.c: netinet/tcp.h, not on BeOS (PR#330) In-Reply-To: <20000516065646.E8D641CDB6@dinsdale.python.org> Message-ID: On Tue, 16 May 2000 donn@oz.net wrote: > BeOS (up to 5.0) lacks . Donn, Thanks! I've checked this in to the CVS repository. (The email alerts aren't working at the moment; we expect to have that fixed shortly.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue May 16 14:33:01 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 16 May 2000 09:33:01 -0400 (EDT) Subject: [Python-bugs-list] socketmodule.c: netinet/tcp.h, not on BeOS (PR#331) Message-ID: <20000516133301.D7F951CD26@dinsdale.python.org> On Tue, 16 May 2000 donn@oz.net wrote: > BeOS (up to 5.0) lacks . Donn, Thanks! I've checked this in to the CVS repository. (The email alerts aren't working at the moment; we expect to have that fixed shortly.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From jack@oratrix.nl Tue May 16 21:35:06 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 16 May 2000 22:35:06 +0200 Subject: [Python-bugs-list] Demo/parser/test_parser.py fails on MacPython Message-ID: <20000516203511.CA983DDDE0@oratrix.oratrix.nl> Yes, I realise it's a bit silly that I report a bug in MacPython, but as I've never used the parser module, nor fully understand what it does and/or how I broke it (I'll assume it's me that broke it for the time being) I could use some pointers. In MacPython 1.6a2 running Demo/parser/test_parser.py fails with the following output, and apparently it has always worked upto now. Could anyone tell me what might be going on? ---- docstring.py o.k. ---- example.py parser module raised exception on input file example.py: Traceback (most recent call last): File "Macintosh HD:SWdev:Jack:Python:Demo:parser:test_parser.py", line 19, in testChunk new = parser.tuple2ast(tup) ParserError: Expected node type 12, got 312. ---- simple.py o.k. ---- source.py o.k. ---- test_parser.py parser module raised exception on input file test_parser.py: Traceback (most recent call last): File "Macintosh HD:SWdev:Jack:Python:Demo:parser:test_parser.py", line 19, in testChunk new = parser.tuple2ast(tup) ParserError: Expected node type 12, got 312. Thanks in advance, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Lucas.Dejonge@awtpl.com.au Tue May 16 22:42:33 2000 From: Lucas.Dejonge@awtpl.com.au (Lucas.Dejonge@awtpl.com.au) Date: Tue, 16 May 2000 17:42:33 -0400 (EDT) Subject: [Python-bugs-list] Bug(?) in imaplib.py - SEARCH function (PR#332) Message-ID: <20000516214233.37A451CD10@dinsdale.python.org> Full_Name: Lucas de Jonge Version: 1.6a2 (and older?) OS: Win32 Submission from: pad-cache1-1.cache.telstra.net (165.228.129.11) When attempting to use the search function in imaplib, I keep getting errors whenever I attempt to use a search requiring a string. Using debug=4 I was able to work out what is going wrong... >>> fred.search(None, 'FROM "LDJ"') 40:32.23 > EPGL17 SEARCH "FROM \"LDJ\"" 40:32.25 < EPGL17 BAD SEARCH 1 Invalid Parameter : FROM \ 40:32.27 BAD response: SEARCH 1 Invalid Parameter : FROM \ Traceback (innermost last): File "", line 1, in ? fred.search(None, 'FROM "LDJ"') File "C:\Python\lib\imaplib.py", line 459, in search typ, dat = apply(self._simple_command, (name, charset) + criteria) File "C:\Python\lib\imaplib.py", line 833, in _simple_command return self._command_complete(name, apply(self._command, (name,) + args)) File "C:\Python\lib\imaplib.py", line 670, in _command_complete raise self.error('%s command error: %s %s' % (name, typ, data)) error: SEARCH command error: BAD ['SEARCH 1 Invalid Parameter : FROM \\'] It seems that the whole string is escaped and put in quotes, which is not what the server is expecting. I am trying to do: xxx SEARCH FROM "LDJ" and it is doing: xxx SEARCH "FROM \"LDJ\"" Thank you again for a great product... From savichev@physik.uni-freiburg.de Sat May 20 22:36:47 2000 From: savichev@physik.uni-freiburg.de (savichev@physik.uni-freiburg.de) Date: Sat, 20 May 2000 17:36:47 -0400 (EDT) Subject: [Python-bugs-list] threads (PR#333) Message-ID: <20000520213647.AB9311CDF0@dinsdale.python.org> Full_Name: Vladimir Savichev Version: 1.6a2 OS: IRIX64 Submission from: tqd4.physik.uni-freiburg.de (132.230.78.183) './configure --with-threads' won't pass test_signal during 'make test'. './regrtest.py -v test_signal' # adds on in Makefile fixes the problem. test_threads goes through and test_signal on the compiled python completes also. './regrtest.py -v' mode shows that script = """ ( set %(x)s sleep 2 kill -5 %(pid)d sleep 2 kill -2 %(pid)d sleep 2 kill -3 %(pid)d ) can't be fully completed. From haase@media.mit.edu Sun May 21 01:08:01 2000 From: haase@media.mit.edu (haase@media.mit.edu) Date: Sat, 20 May 2000 20:08:01 -0400 (EDT) Subject: [Python-bugs-list] Segmentation violation on very long lists (PR#334) Message-ID: <20000521000801.07EE31CD22@dinsdale.python.org> Full_Name: Kenneth Haase Version: Both Python 1.5.2 and 1.6a2 OS: SUSE Linux Submission from: dynamic-5.media.mit.edu (18.85.12.133) Loading a .py file which attempts to define a very long list causes a segmentation violation. An example file can be found at ftp:/pub/haase/todo.py, but I expect that most any long file defining a long list (20K elements) would do. Thanks, Ken Haase From nilsb@bermuda.de Sun May 21 15:12:54 2000 From: nilsb@bermuda.de (nilsb@bermuda.de) Date: Sun, 21 May 2000 10:12:54 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: pty allocating with linux/devpts (PR#335) Message-ID: <20000521141254.A547D1CD98@dinsdale.python.org> Full_Name: Nils Bokermann Version: 1.6 (also 1.5) OS: Linux Submission from: janus.bermuda.de (194.245.92.185) Hi! It's only a small (bad) hack, but it works and should give you a hint of what I mean. ptsmodule.c: (heavily borrowed at sgimodule) /*********************************************************** Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam, The Netherlands. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Stichting Mathematisch Centrum or CWI or Corporation for National Research Initiatives or CNRI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. While CWI is the initial source for this software, a modified version is made available by the Corporation for National Research Initiatives (CNRI) at the Internet address ftp://ftp.python.org. STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM OR CNRI BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ******************************************************************/ /* devpts helps */ #include "Python.h" #include #include #include #include #include #include static PyObject * pts__getpty(self, args) PyObject *self; PyObject *args; { int oflag; int mode; int nofork; char *name; int fildes,slavepty; if (!PyArg_Parse(args, "(iii)", &oflag, &mode, &nofork)) return NULL; errno = 0; /* name = _getpty(&fildes, oflag, (mode_t)mode, nofork); if (name == NULL) { PyErr_SetFromErrno(PyExc_IOError); return NULL; } */ openpty(&fildes, &slavepty, NULL, NULL, NULL); name=ptsname(fildes); return Py_BuildValue("(si)", name, fildes); } static PyMethodDef pts_methods[] = { {"_getpty", pts__getpty}, {NULL, NULL} /* sentinel */ }; void initpts() { Py_InitModule("pts", pts_methods); } and second you need pty.py: --- orig/pty.py Fri Feb 4 16:10:34 2000 +++ pty.py Sun May 21 16:00:39 2000 @@ -29,6 +28,16 @@ except IOError, msg: raise os.error, msg return master_fd, tty_name + try: + import pts + except ImportError: + pass + else: + try: + tty_name, master_fd =pts._getpty(FCNTL.O_RDWR, 0666,0) + except IOError, msg: + raise os.error, msg + return master_fd, tty_name And that's it. HTH, Nils From guido@python.org Sun May 21 20:12:22 2000 From: guido@python.org (Guido van Rossum) Date: Sun, 21 May 2000 12:12:22 -0700 Subject: [Python-bugs-list] Segmentation violation on very long lists (PR#334) In-Reply-To: Your message of "Sat, 20 May 2000 20:08:01 EDT." <20000521000801.07EE31CD22@dinsdale.python.org> References: <20000521000801.07EE31CD22@dinsdale.python.org> Message-ID: <200005211912.MAA04864@cj20424-a.reston1.va.home.com> > Loading a .py file which attempts to define a very long list causes > a segmentation violation. An example file can be found at > ftp:/pub/haase/todo.py, but I expect that most any long file defining a long > list (20K elements) would do. Thanks -- this is a known problem, it probably has to do with bytecode field overflow (offsets are signed shorts). --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Sun May 21 17:11:39 2000 From: guido@python.org (guido@python.org) Date: Sun, 21 May 2000 12:11:39 -0400 (EDT) Subject: [Python-bugs-list] Segmentation violation on very long lists (PR#334) Message-ID: <20000521161139.A6A961CD6D@dinsdale.python.org> > Loading a .py file which attempts to define a very long list causes > a segmentation violation. An example file can be found at > ftp:/pub/haase/todo.py, but I expect that most any long file defining a long > list (20K elements) would do. Thanks -- this is a known problem, it probably has to do with bytecode field overflow (offsets are signed shorts). --Guido van Rossum (home page: http://www.python.org/~guido/) From alian@trakus.com Sun May 21 20:42:24 2000 From: alian@trakus.com (alian@trakus.com) Date: Sun, 21 May 2000 15:42:24 -0400 (EDT) Subject: [Python-bugs-list] imaplib select function string handling (PR#336) Message-ID: <20000521194224.8C6EF1CD1D@dinsdale.python.org> Full_Name: Alexander Lian Version: 1.5.2 OS: NT Submission from: (NULL) (208.176.231.196) I'm sure this bug is due to my odd usage. I've been using the imaplib to access a Notes server (4.6.6a) and noticed a string handling oddity with the select function. In Lotus Notes, mailbox hierarchy utilizes a '\' as their string delimiter. Thus, a sub folder 'bar' of folder 'foo' will list as 'foo\bar'. The bug manifests itself if there is a space in any mailbox name regardless of hierarchy. Normally, in such a case of 'a\\b\\c', the select function works fine. However, if the mailbox lists from the list function as: 'a\\b c' then the select function fails with that exact string. Instead, it functions correctly by replacing the '\\' with '\\\\' (of course, when actually adding that it's eight slashes) So it seems the name is getting string mangled twice to go from '\\\\' down to the IMAP specified single character, in this case '\'. I'm guessing this bug may manifest in other functions, but I have not determined that as of yet. From bwarsaw@python.org Tue May 23 06:39:22 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 23 May 2000 01:39:22 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) References: <20000402212224.38C5B1CDB2@dinsdale.python.org> <14568.48578.579998.389218@beluga.mojam.com> Message-ID: <14634.6538.584674.685043@localhost.localdomain> >>>>> writes: >> My suggestion is that `C-c |' be made clever enough to discover >> the left margin of the region under consideration, and that it >> removes that margin while transmitting the region to the Python >> interpreter. That would allow for using that command in a much >> wider variety of (smaller :-) contexts. >>>>> "SM" =3D=3D Skip Montanaro writes: SM> Wouldn't it be easier to have python-mode simply insert SM> if 1: SM> in front of any indented block of code being sent to the SM> interpreter? Just goes to show you that if Guido sends me noodges me enough, I finally respond. :) Anyway to recap: Fran=E7ois posted a patch which fixed an annoying behavior in python-mode when using C-c | on an indented region. Skip countered with a proposal to just insert "if 1:" if the executing region is indented. I think Guido liked this approach better because it preserves stuff like triple quoted strings. I also like it better because of TQSs and commented out regions (which may have a comment character in column zero, but for all intents and purposes is still indented). In any event, here's the patch I plan to check in. -Barry -------------------- snip snip -------------------- Index: python-mode.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Misc/python-mode.el,v retrieving revision 3.105 diff -c -r3.105 python-mode.el *** python-mode.el=091999/08/10 21:49:00=093.105 --- python-mode.el=092000/05/23 05:38:07 *************** *** 1278,1288 **** =09=09=09 (format "python-%d-%d" sn pid) =09=09 (format "python-%d" sn))) =09=09 (make-temp-name "python-"))) ! =09 (file (expand-file-name temp py-temp-directory))) ! (write-region start end file nil 'nomsg) (cond ;; always run the code in its own asynchronous subprocess (async (let* ((buf (generate-new-buffer-name py-output-buffer)) =09 ;; TBD: a horrible hack, but why create new Custom variables?= =09 (arg (if (string-equal py-which-bufname "Python") --- 1278,1300 ---- =09=09=09 (format "python-%d-%d" sn pid) =09=09 (format "python-%d" sn))) =09=09 (make-temp-name "python-"))) ! =09 (file (expand-file-name temp py-temp-directory)) ! =09 (cur (current-buffer)) ! =09 (buf (get-buffer-create file))) ! ;; Write the contents of the buffer, watching out for indented re= gions. ! (save-excursion ! (goto-char start) ! (when (/=3D (py-point 'bol) (py-point 'boi)) ! =09(set-buffer buf) ! =09(insert "if 1:\n")) ! (insert-buffer-substring cur start end)) (cond ;; always run the code in its own asynchronous subprocess (async + ;; User explicitly wants this to run in its own async subproces= s + (save-excursion + =09(set-buffer buf) + =09(write-region (point-min) (point-max) file nil 'nomsg)) (let* ((buf (generate-new-buffer-name py-output-buffer)) =09 ;; TBD: a horrible hack, but why create new Custom variables?= =09 (arg (if (string-equal py-which-bufname "Python") *************** *** 1290,1300 **** --- 1302,1316 ---- =09(start-process py-which-bufname buf py-which-shell arg file) =09(pop-to-buffer buf) =09(py-postprocess-output-buffer buf) + =09;; TBD: clean up the temporary file! =09)) ;; if the Python interpreter shell is running, queue it up for ;; execution there. (proc ;; use the existing python shell + (save-excursion + =09(set-buffer buf) + =09(write-region (point-min) (point-max) file nil 'nomsg)) (if (not py-file-queue) =09 (py-execute-file proc file) =09(message "File %s queued for execution" file)) *************** *** 1306,1312 **** =09=09=09 (if (string-equal py-which-bufname "JPython") =09=09=09 " -" "")))) =09;; otherwise either run it synchronously in a subprocess ! =09(shell-command-on-region start end cmd py-output-buffer) =09;; shell-command-on-region kills the output buffer if it never =09;; existed and there's no output from the command =09(if (not (get-buffer py-output-buffer)) --- 1322,1331 ---- =09=09=09 (if (string-equal py-which-bufname "JPython") =09=09=09 " -" "")))) =09;; otherwise either run it synchronously in a subprocess ! =09(save-excursion ! =09 (set-buffer buf) ! =09 (shell-command-on-region (point-min) (point-max) ! =09=09=09=09 cmd py-output-buffer)) =09;; shell-command-on-region kills the output buffer if it never =09;; existed and there's no output from the command =09(if (not (get-buffer py-output-buffer)) *************** *** 1316,1322 **** =09 (pop-to-buffer py-output-buffer) =09 (if err-p =09=09(pop-to-buffer py-exception-buffer))) ! =09 ))) ))) =20 =0C --- 1335,1343 ---- =09 (pop-to-buffer py-output-buffer) =09 (if err-p =09=09(pop-to-buffer py-exception-buffer))) ! =09 )) ! ;; TBD: delete the buffer ! ) ))) =20 =0C From bwarsaw@python.org Tue May 23 06:39:26 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Tue, 23 May 2000 01:39:26 -0400 (EDT) Subject: [Python-bugs-list] Python 1.6a1 - Misc/python-mode.el not updated? (PR#264) Message-ID: <20000523053926.0A5051CD61@dinsdale.python.org> >>>>> writes: >> My suggestion is that `C-c |' be made clever enough to discover >> the left margin of the region under consideration, and that it >> removes that margin while transmitting the region to the Python >> interpreter. That would allow for using that command in a much >> wider variety of (smaller :-) contexts. >>>>> "SM" =3D=3D Skip Montanaro writes: SM> Wouldn't it be easier to have python-mode simply insert SM> if 1: SM> in front of any indented block of code being sent to the SM> interpreter? Just goes to show you that if Guido sends me noodges me enough, I finally respond. :) Anyway to recap: Fran=E7ois posted a patch which fixed an annoying behavior in python-mode when using C-c | on an indented region. Skip countered with a proposal to just insert "if 1:" if the executing region is indented. I think Guido liked this approach better because it preserves stuff like triple quoted strings. I also like it better because of TQSs and commented out regions (which may have a comment character in column zero, but for all intents and purposes is still indented). In any event, here's the patch I plan to check in. -Barry -------------------- snip snip -------------------- Index: python-mode.el =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/python/dist/src/Misc/python-mode.el,v retrieving revision 3.105 diff -c -r3.105 python-mode.el *** python-mode.el=091999/08/10 21:49:00=093.105 --- python-mode.el=092000/05/23 05:38:07 *************** *** 1278,1288 **** =09=09=09 (format "python-%d-%d" sn pid) =09=09 (format "python-%d" sn))) =09=09 (make-temp-name "python-"))) ! =09 (file (expand-file-name temp py-temp-directory))) ! (write-region start end file nil 'nomsg) (cond ;; always run the code in its own asynchronous subprocess (async (let* ((buf (generate-new-buffer-name py-output-buffer)) =09 ;; TBD: a horrible hack, but why create new Custom variables?= =09 (arg (if (string-equal py-which-bufname "Python") --- 1278,1300 ---- =09=09=09 (format "python-%d-%d" sn pid) =09=09 (format "python-%d" sn))) =09=09 (make-temp-name "python-"))) ! =09 (file (expand-file-name temp py-temp-directory)) ! =09 (cur (current-buffer)) ! =09 (buf (get-buffer-create file))) ! ;; Write the contents of the buffer, watching out for indented re= gions. ! (save-excursion ! (goto-char start) ! (when (/=3D (py-point 'bol) (py-point 'boi)) ! =09(set-buffer buf) ! =09(insert "if 1:\n")) ! (insert-buffer-substring cur start end)) (cond ;; always run the code in its own asynchronous subprocess (async + ;; User explicitly wants this to run in its own async subproces= s + (save-excursion + =09(set-buffer buf) + =09(write-region (point-min) (point-max) file nil 'nomsg)) (let* ((buf (generate-new-buffer-name py-output-buffer)) =09 ;; TBD: a horrible hack, but why create new Custom variables?= =09 (arg (if (string-equal py-which-bufname "Python") *************** *** 1290,1300 **** --- 1302,1316 ---- =09(start-process py-which-bufname buf py-which-shell arg file) =09(pop-to-buffer buf) =09(py-postprocess-output-buffer buf) + =09;; TBD: clean up the temporary file! =09)) ;; if the Python interpreter shell is running, queue it up for ;; execution there. (proc ;; use the existing python shell + (save-excursion + =09(set-buffer buf) + =09(write-region (point-min) (point-max) file nil 'nomsg)) (if (not py-file-queue) =09 (py-execute-file proc file) =09(message "File %s queued for execution" file)) *************** *** 1306,1312 **** =09=09=09 (if (string-equal py-which-bufname "JPython") =09=09=09 " -" "")))) =09;; otherwise either run it synchronously in a subprocess ! =09(shell-command-on-region start end cmd py-output-buffer) =09;; shell-command-on-region kills the output buffer if it never =09;; existed and there's no output from the command =09(if (not (get-buffer py-output-buffer)) --- 1322,1331 ---- =09=09=09 (if (string-equal py-which-bufname "JPython") =09=09=09 " -" "")))) =09;; otherwise either run it synchronously in a subprocess ! =09(save-excursion ! =09 (set-buffer buf) ! =09 (shell-command-on-region (point-min) (point-max) ! =09=09=09=09 cmd py-output-buffer)) =09;; shell-command-on-region kills the output buffer if it never =09;; existed and there's no output from the command =09(if (not (get-buffer py-output-buffer)) *************** *** 1316,1322 **** =09 (pop-to-buffer py-output-buffer) =09 (if err-p =09=09(pop-to-buffer py-exception-buffer))) ! =09 ))) ))) =20 =0C --- 1335,1343 ---- =09 (pop-to-buffer py-output-buffer) =09 (if err-p =09=09(pop-to-buffer py-exception-buffer))) ! =09 )) ! ;; TBD: delete the buffer ! ) ))) =20 =0C From slupi@iol.it Tue May 23 10:09:38 2000 From: slupi@iol.it (slupi@iol.it) Date: Tue, 23 May 2000 05:09:38 -0400 (EDT) Subject: [Python-bugs-list] floating point ??? (PR#337) Message-ID: <20000523090938.093641CD76@dinsdale.python.org> Full_Name: Sergio Lupi Version: 1.52 OS: Linux Suse 6.4 Submission from: (NULL) (195.78.220.33) very simple: try this: >>> 0.14-0.13 == 0.13-0.12 1 so far so good, but >>> 0.13-0.12 == 0.12-0.11 0 There are some combinations of numbers (they are many indeed) that mess things up. This has been tested on several PCs under Linux and NT From tim_one@email.msn.com Wed May 24 04:27:25 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 23 May 2000 23:27:25 -0400 Subject: [Python-bugs-list] floating point ??? (PR#337) In-Reply-To: <20000523090938.093641CD76@dinsdale.python.org> Message-ID: <000001bfc52f$fb9bf4e0$fa2d153f@tim> [slupi@iol.it] > Full_Name: Sergio Lupi > Version: 1.52 > OS: Linux Suse 6.4 > Submission from: (NULL) (195.78.220.33) > > > very simple: Actually not -- it's very complicated, and while it may be surprising it isn't a bug. > try this: > > >>> 0.14-0.13 == 0.13-0.12 > 1 > so far so good, but > > >>> 0.13-0.12 == 0.12-0.11 > 0 > > There are some combinations of numbers (they are many indeed) > that mess things up. And not just in Python: you'll get very similar results whether you try this in Python, Perl, C, C++, Java, Fortran, or anything else that uses binary floating-point arithmetic. None of those numbers (.11, .12, .13, .14) is exactly representable in binary fp, much as 1/3 isn't exactly representable as a decimal expansion either: 0.3333..... So, for example, .14-.13 is NOT .01 -- it's a binary fraction that's simply close to .01. Ditto for .12-.11: it's some other binary fraction that's also close to .01. If you print your results to more precision, you'll see a better approximation to the value the computer truly computes: >>> print "%.17g" % (.12-.11) 0.009999999999999995 >>> print "%.17g" % (.13-.12) 0.010000000000000009 >>> And, indeed, those clearly aren't equal. > This has been tested on several PCs under Linux and NT Yes, that's expected. It doesn't really matter whose hardware, whose operating system, or even whose programming language you're using: this is what binary floating-point hardware *does*. If you need exact decimal arithmetic, you can't use binary floating-point. There are classes available for Python that support (at least the illusion of) decimal arithmetic instead, but they're very much slower. From tim_one@email.msn.com Wed May 24 04:27:38 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 23 May 2000 23:27:38 -0400 (EDT) Subject: [Python-bugs-list] floating point ??? (PR#337) Message-ID: <20000524032738.C614F1CD5B@dinsdale.python.org> [slupi@iol.it] > Full_Name: Sergio Lupi > Version: 1.52 > OS: Linux Suse 6.4 > Submission from: (NULL) (195.78.220.33) > > > very simple: Actually not -- it's very complicated, and while it may be surprising it isn't a bug. > try this: > > >>> 0.14-0.13 == 0.13-0.12 > 1 > so far so good, but > > >>> 0.13-0.12 == 0.12-0.11 > 0 > > There are some combinations of numbers (they are many indeed) > that mess things up. And not just in Python: you'll get very similar results whether you try this in Python, Perl, C, C++, Java, Fortran, or anything else that uses binary floating-point arithmetic. None of those numbers (.11, .12, .13, .14) is exactly representable in binary fp, much as 1/3 isn't exactly representable as a decimal expansion either: 0.3333..... So, for example, .14-.13 is NOT .01 -- it's a binary fraction that's simply close to .01. Ditto for .12-.11: it's some other binary fraction that's also close to .01. If you print your results to more precision, you'll see a better approximation to the value the computer truly computes: >>> print "%.17g" % (.12-.11) 0.009999999999999995 >>> print "%.17g" % (.13-.12) 0.010000000000000009 >>> And, indeed, those clearly aren't equal. > This has been tested on several PCs under Linux and NT Yes, that's expected. It doesn't really matter whose hardware, whose operating system, or even whose programming language you're using: this is what binary floating-point hardware *does*. If you need exact decimal arithmetic, you can't use binary floating-point. There are classes available for Python that support (at least the illusion of) decimal arithmetic instead, but they're very much slower. From gpk@bell-labs.com Wed May 24 15:24:33 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Wed, 24 May 2000 10:24:33 -0400 (EDT) Subject: [Python-bugs-list] Reference counting problem? (PR#338) Message-ID: <20000524142433.45F131CDAA@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.6 as of 5/21/2000 OS: Solaris 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) Python 1.6 seems to have some kind of reference counting problem. The following function (in the midst of a large program) will crash with a nonsensical exception if I comment out the print statement. def _pull_types(d, nc): """Finds all the column definitions in the data file, that is, attributes in the form 'TTYPE#'. These attributes tell you what kind of data is in a specific column. It then builds an output dictionary that tells you what column contains any desired type of data.""" ts = type('') kl = d.keys() o = {} for k in kl: assert type(k)==ts, 'Key must be string' # comment out next line to crash: print "PULLTYPES(", k, ")", 'type(k)=', type(k) if len(k)>5 and k[:5] == 'TTYPE': col = string.atoi(k[5:]) if col>0 and col<=nc: o[d[k]] = col-1 return o Output with print statement in: ... PULLTYPES( HISTORY ) type(k)= PULLTYPES( _FILETYPE ) type(k)= PULLTYPES( I_NOISE ) type(k)= PULLTYPES( NAXIS2 ) type(k)= PULLTYPES( CDELT2 ) type(k)= PULLTYPES( CDELT1 ) type(k)= ... Output with print statement commented out: ... Traceback (most recent call last): File "/u/gpk/f0cls/bin/get_3_f0.sh", line 101, in ? pegg = get_f0(t + '/pegg.sd', pfile+'.pegg', t + '/pegg'); File "/u/gpk/f0cls/bin/get_3_f0.sh", line 83, in get_f0 return gpkimgclass.read(ttn + '.f0.dat') File "/home/gpk/lib/gpkimgclass.py", line 41, in read return gpk_img(hdr, data) File "/home/gpk/lib/gpkimgclass.py", line 69, in __init__ self.types = _pull_types(self.hdr, self.n[1]) File "/home/gpk/lib/gpkimgclass.py", line 23, in _pull_types if len(k)>5 and k[:5] == 'TTYPE': IndexError: list index out of range ... From guido@python.org Thu May 25 21:48:29 2000 From: guido@python.org (guido@python.org) Date: Thu, 25 May 2000 16:48:29 -0400 (EDT) Subject: [Python-bugs-list] Reference counting problem? (PR#338) Message-ID: <20000525204829.EEAC61CD7A@dinsdale.python.org> > Python 1.6 seems to have some kind of reference counting problem. > > The following function (in the midst of a large program) > will crash with a nonsensical exception if I comment out the > print statement. Without the whole program and its input data it's hard to debug this. Does your program use any nonstandard extension modules? That's where I'd start looking... A bug in core Python, while not impossible, is pretty unlikely. --Guido van Rossum (home page: http://www.python.org/~guido/) From Lucas.DeJonge@awtpl.com.au Thu May 25 22:39:37 2000 From: Lucas.DeJonge@awtpl.com.au (Lucas.DeJonge@awtpl.com.au) Date: Thu, 25 May 2000 17:39:37 -0400 (EDT) Subject: [Python-bugs-list] Re: Bug(?) in imaplib.py - SEARCH function (PR#332) Message-ID: <20000525213937.F2FC61CE15@dinsdale.python.org> This first works well, Thank you. It is not at all clear in the doco though. Perhaps this could be put in the example? >>> Guido van Rossum 26/05/00 0:16:26 >>> According to Piers Lauder, you should do either: fred.search(None, 'FROM', '"LDJ"') or fred.search(None, '(FROM "LDJ")') (the doublequotes can be omitted in both examples.) --Guido From fdrake@acm.org Fri May 26 04:42:13 2000 From: fdrake@acm.org (Fred L. Drake) Date: Thu, 25 May 2000 20:42:13 -0700 (PDT) Subject: [Python-bugs-list] Re: Bug(?) in imaplib.py - SEARCH function (PR#332) In-Reply-To: <20000525213937.F2FC61CE15@dinsdale.python.org> Message-ID: [CC to Piers since this is his module...] On Thu, 25 May 2000 Lucas.DeJonge@awtpl.com.au wrote: > It is not at all clear in the doco though. Perhaps this could be put in the example? > > >>> Guido van Rossum 26/05/00 0:16:26 >>> > According to Piers Lauder, you should do either: > fred.search(None, 'FROM', '"LDJ"') > or > fred.search(None, '(FROM "LDJ")') > > (the doublequotes can be omitted in both examples.) How about this for a revised description of the search() method: \begin{methoddesc}{search}{charset, criterium\optional{, ...}} Search mailbox for matching messages. Returned data contains a space separated list of matching message numbers. \var{charset} may be \code{None}, in which case no \samp{CHARSET} will be specified in the request to the server. The IMAP protocol requires that at least one criterium be specified; an exception will be raised when the server returns an error. Example: \begin{verbatim} # M is a connected IMAP4 instance... msgnums = M.search(None, 'FROM', '"LDJ"') # or: msgnums = M.search(None, '(FROM "LDJ")') \end{verbatim} \end{methoddesc} -Fred -- Fred L. Drake, Jr. From fdrake@acm.org Fri May 26 04:42:11 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Thu, 25 May 2000 23:42:11 -0400 (EDT) Subject: [Python-bugs-list] Re: Bug(?) in imaplib.py - SEARCH function (PR#339) Message-ID: <20000526034211.7F1081CD3A@dinsdale.python.org> [CC to Piers since this is his module...] On Thu, 25 May 2000 Lucas.DeJonge@awtpl.com.au wrote: > It is not at all clear in the doco though. Perhaps this could be put in the example? > > >>> Guido van Rossum 26/05/00 0:16:26 >>> > According to Piers Lauder, you should do either: > fred.search(None, 'FROM', '"LDJ"') > or > fred.search(None, '(FROM "LDJ")') > > (the doublequotes can be omitted in both examples.) How about this for a revised description of the search() method: \begin{methoddesc}{search}{charset, criterium\optional{, ...}} Search mailbox for matching messages. Returned data contains a space separated list of matching message numbers. \var{charset} may be \code{None}, in which case no \samp{CHARSET} will be specified in the request to the server. The IMAP protocol requires that at least one criterium be specified; an exception will be raised when the server returns an error. Example: \begin{verbatim} # M is a connected IMAP4 instance... msgnums = M.search(None, 'FROM', '"LDJ"') # or: msgnums = M.search(None, '(FROM "LDJ")') \end{verbatim} \end{methoddesc} -Fred -- Fred L. Drake, Jr. From ragnark@vestdata.no Fri May 26 15:52:00 2000 From: ragnark@vestdata.no (ragnark@vestdata.no) Date: Fri, 26 May 2000 10:52:00 -0400 (EDT) Subject: [Python-bugs-list] performance-problem decoding quoted-printable (PR#340) Message-ID: <20000526145200.73BBC1CD76@dinsdale.python.org> --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Problem on python 1.5.1 on linux 2.2.14aa6. Decoding quoted-printable files using mimetools.decode is really slow. The really strange thing is, that it appers to work a lot faster on smaller files! I put together a little test-program that reads blocks from a file, and decodes them individually. (The output will not be 100% correct. The point was just to test the performance). Results show the time it took to decode a 300k file with the diferent block-sizes: 1k: 6.28 s 3k: 6.59 s 10k: 8.57 s 30k: 30.45 s 100k: 127.82 s 300k: 221.67 s I looked in quopri.decode for clues about the problem, but could not find any. Is there something _very_ wrong with my reasoning, or is something wrong here? -- Ragnar Kj�rstad --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test.py" #!/usr/bin/python from mimetools import decode from StringIO import StringIO from sys import stdout, argv from string import atoi bsize=atoi(argv[1]) output=StringIO() f=open("mail-test") s=f.read(bsize) while s: input=StringIO(s) decode(input, output, 'quoted-printable') s=f.read(bsize) stdout.write('.') stdout.flush() stdout.write('done\n') --7JfCtLOvnd9MIVvH-- From gpk@bell-labs.com Fri May 26 16:38:03 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Fri, 26 May 2000 11:38:03 -0400 (EDT) Subject: [Python-bugs-list] Reference counting problem? (PR#338) Message-ID: <20000526153803.7108B1CD7F@dinsdale.python.org> Guido van Rossum wrote: > > > Python 1.6 seems to have some kind of reference counting problem. > > Without the whole program and its input data it's hard to debug this. > Does your program use any nonstandard extension modules? That's where > I'd start looking... It does. Some of the input data is a copy of a directory the nonstandard module produces. I'll look at the nonstandard module, and also see if I can isolate the problem to a reasonable-size chunk of code. From scut@nb.in-berlin.de Sat May 27 14:41:24 2000 From: scut@nb.in-berlin.de (scut@nb.in-berlin.de) Date: Sat, 27 May 2000 09:41:24 -0400 (EDT) Subject: [Python-bugs-list] %.1200d will make Python segfault (PR#341) Message-ID: <20000527134124.7C1571CE0F@dinsdale.python.org> Full_Name: - Version: 1.5.2 OS: Linux Submission from: elch.in-berlin.de (192.109.42.5) To reproduce just start python and enter something like: "%.1200d" % 1 It is constructed in a local buffer on the stack which is about 1000 characters or so long, so you overwrite the framepointer and the retaddr, may be exploitable to attackers under some conditions. Though this bug appears in GNU libc also, this one is within the Python code. Thanks for developing such a great programming language as Python is :-) ciao, scut / teso http://teso.scene.at/ From mal@lemburg.com Sat May 27 16:47:47 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 27 May 2000 17:47:47 +0200 Subject: [Python-bugs-list] %.1200d will make Python segfault (PR#341) References: <20000527134124.7C1571CE0F@dinsdale.python.org> Message-ID: <392FEE23.D57AF034@lemburg.com> scut@nb.in-berlin.de wrote: > > Full_Name: - > Version: 1.5.2 > OS: Linux > Submission from: elch.in-berlin.de (192.109.42.5) > > To reproduce just start python and enter something like: > > "%.1200d" % 1 > > It is constructed in a local buffer on the stack which is about 1000 characters > or so long, so you overwrite the framepointer and the retaddr, may be > exploitable > to attackers under some conditions. It's a bug in the format code in stringobject.c and unicodeobject.c. Note that the buffer in only 120 chars in size, so "%.130d" % 1 already does the trick. Strange that noone has noticed this one before... Python should really provide the n-variants of printf() et al. on those platforms which do not have them to make it more buffer overflow safe. FYI, I've posted a fix to the patches list. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat May 27 16:51:54 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Sat, 27 May 2000 11:51:54 -0400 (EDT) Subject: [Python-bugs-list] %.1200d will make Python segfault (PR#341) Message-ID: <20000527155154.4437E1CD80@dinsdale.python.org> scut@nb.in-berlin.de wrote: > > Full_Name: - > Version: 1.5.2 > OS: Linux > Submission from: elch.in-berlin.de (192.109.42.5) > > To reproduce just start python and enter something like: > > "%.1200d" % 1 > > It is constructed in a local buffer on the stack which is about 1000 characters > or so long, so you overwrite the framepointer and the retaddr, may be > exploitable > to attackers under some conditions. It's a bug in the format code in stringobject.c and unicodeobject.c. Note that the buffer in only 120 chars in size, so "%.130d" % 1 already does the trick. Strange that noone has noticed this one before... Python should really provide the n-variants of printf() et al. on those platforms which do not have them to make it more buffer overflow safe. FYI, I've posted a fix to the patches list. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From michael.exner@mrz.uni-magdeburg.de Wed May 31 14:43:39 2000 From: michael.exner@mrz.uni-magdeburg.de (michael.exner@mrz.uni-magdeburg.de) Date: Wed, 31 May 2000 09:43:39 -0400 (EDT) Subject: [Python-bugs-list] python with-threads core-dumps (PR#342) Message-ID: <20000531134339.A8BC61CD41@dinsdale.python.org> Full_Name: Michael Exner Version: 1.5.2 OS: hpux-11.00 Submission from: pan.med.uni-magdeburg.de (149.203.102.1) When I compile python with threads python core-dumps: $ ./python pthread_mutex_init: Invalid argument Memory fault(coredump) without thread-support everything works fine I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result From atkins@gweep.net Wed May 31 22:37:16 2000 From: atkins@gweep.net (atkins@gweep.net) Date: Wed, 31 May 2000 17:37:16 -0400 (EDT) Subject: [Python-bugs-list] Python SIGSEGV with re.compile (PR#343) Message-ID: <20000531213716.6ECA01CD4B@dinsdale.python.org> Full_Name: Aron Atkins Version: 1.5.2 OS: Linux - RH6.1 Submission from: invid.hq.iphrase.com (63.94.206.213) The following causes a SIGSEGV: import re re.compile ( '[\\200-\\400]' ) Yes, the '\\400' improperly flows into the next byte. Unfortunately, the SIGSEGV isn't very helpful to the average developer. An error-check during the compilation of the RE should have produced an exception. The intent was: import re re.compile ( '[\\200-\\377]' )