From pai@tiac.net Fri Jun 2 19:19:59 2000 From: pai@tiac.net (pai@tiac.net) Date: Fri, 2 Jun 2000 14:19:59 -0400 (EDT) Subject: [Python-bugs-list] input() in IDLE (PR#344) Message-ID: <20000602181959.4FEEB1CE9F@dinsdale.python.org> Full_Name: Lloyd R. Prentice Version: 1.5.2 OS: NT Submission from: ip8.bedford3.ma.pub-ip.psi.net (38.32.11.8) I entered and saved an area calculation problem presented in one of the tutorials. When I run it, it gets to the input statement, then gets stuck -- it accepts the input, but gives me a new line and continues to look for input when press the return key. Here's the program: # Area Calculation Program print "Welcome to the Area Calculation Program" print "_______________________________________" print # Print out the menu: print "Please select a shape:" print "1 Rectangle" print "2 Circle" # Get the user's choice: shape = input ("> ") # Calculate the area: if shape == 1: height = input("Please enter the height: ") width = input("Please enter the width: ") area = height * width print "The area is",area else: radius = input("Please enter the radius: ") area = 3.14*(radius**2) print "The area is",area print "done" From db3l@fitlinxx.com Fri Jun 2 23:43:51 2000 From: db3l@fitlinxx.com (db3l@fitlinxx.com) Date: Fri, 2 Jun 2000 18:43:51 -0400 (EDT) Subject: [Python-bugs-list] Bug (typo) in ntpath.getatime (PR#345) Message-ID: <20000602224351.630A61CE5D@dinsdale.python.org> Full_Name: David Bolen Version: 1.5.2 OS: Windows NT 4.0 SP4 Submission from: (NULL) (208.247.212.11) Line 186 in file Lib/ntpath.py in the Python 1.5.2 distribution (part of the getatime() function): return st[stat.ST_MTIME] incorrect indexes the stat structure by ST_MTIME rather than ST_ATIME. There is a similar bug (marked resolved) for posixpath.py for the same typo, but I wasn't sure that the common issue with ntpath.py had been noticed. From jparkey@rapidbs.com Mon Jun 5 17:06:36 2000 From: jparkey@rapidbs.com (jparkey@rapidbs.com) Date: Mon, 5 Jun 2000 12:06:36 -0400 (EDT) Subject: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) Message-ID: <20000605160636.D55E61CE43@dinsdale.python.org> Full_Name: John Parkey Version: 1.5.2 OS: NT (build 132) Submission from: mail.rapidbs.com (195.92.50.66) Assigning a function object to an instance variable leaks memory. Run the programme below with the Windows task manager up to see the effect. class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": for x in xrange(1000): test() From fvdp@decis.be Mon Jun 5 18:12:36 2000 From: fvdp@decis.be (fvdp@decis.be) Date: Mon, 5 Jun 2000 13:12:36 -0400 (EDT) Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) Message-ID: <20000605171236.992FD1CE23@dinsdale.python.org> Full_Name: Frédéric van der Plancke Version: 1.5.1 OS: Windows NT 4 Submission from: i0913.bfp-s.euronet.be (212.65.51.151) There is a bug in the test for non-nullity of a complex number. e.g. not (1j), not (4+0j) both return 1. (they should return 0, like (not n) for any non-null number n.) correction in : '||' instead of '&&' in complex_nonzero(v): static int complex_nonzero(v) PyComplexObject *v; { return v->cval.real != 0.0 || v->cval.imag != 0.0; } (Warning: I did not test my correction ;-) LEGALESE: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From tim_one@email.msn.com Mon Jun 5 18:54:04 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 5 Jun 2000 13:54:04 -0400 Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) In-Reply-To: <20000605171236.992FD1CE23@dinsdale.python.org> Message-ID: <000a01bfcf17$09b4bb20$92a0143f@tim> Frédéric, you should upgrade to Python 1.5.2! This was fixed a long time ago (1.5.2 was released more than a year ago). > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of fvdp@decis.be > Sent: Monday, June 05, 2000 1:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) > > > Full_Name: Frédéric van der Plancke > Version: 1.5.1 > OS: Windows NT 4 > Submission from: i0913.bfp-s.euronet.be (212.65.51.151) > > > There is a bug in the test for non-nullity of a complex number. > e.g. not (1j), not (4+0j) both return 1. > (they should return 0, like (not n) for any non-null number n.) > > correction in : > '||' instead of '&&' in complex_nonzero(v): > > static int > complex_nonzero(v) > PyComplexObject *v; > { > return v->cval.real != 0.0 || v->cval.imag != 0.0; > } > > (Warning: I did not test my correction ;-) > > LEGALESE: > I confirm that, to the best of my knowledge and belief, this > contribution is free of any claims of third parties under > copyright, patent or other rights or interests ("claims"). To > the extent that I have any such claims, I hereby grant to CNRI a > nonexclusive, irrevocable, royalty-free, worldwide license to > reproduce, distribute, perform and/or display publicly, prepare > derivative versions, and otherwise use this contribution as part > of the Python software and its related documentation, or any > derivative versions thereof, at no cost to CNRI or its licensed > users, and to authorize others to do so. > > I acknowledge that CNRI may, at its sole discretion, decide > whether or not to incorporate this contribution in the Python > software and its related documentation. I further grant CNRI > permission to use my name and other identifying information > provided to CNRI by me for use in connection with the Python > software and its related documentation. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From tim_one@email.msn.com Mon Jun 5 18:55:12 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Mon, 5 Jun 2000 13:55:12 -0400 (EDT) Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) Message-ID: <20000605175512.147DD1CE2A@dinsdale.python.org> Frédéric, you should upgrade to Python 1.5.2! This was fixed a long time ago (1.5.2 was released more than a year ago). > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of fvdp@decis.be > Sent: Monday, June 05, 2000 1:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) > > > Full_Name: Frédéric van der Plancke > Version: 1.5.1 > OS: Windows NT 4 > Submission from: i0913.bfp-s.euronet.be (212.65.51.151) > > > There is a bug in the test for non-nullity of a complex number. > e.g. not (1j), not (4+0j) both return 1. > (they should return 0, like (not n) for any non-null number n.) > > correction in : > '||' instead of '&&' in complex_nonzero(v): > > static int > complex_nonzero(v) > PyComplexObject *v; > { > return v->cval.real != 0.0 || v->cval.imag != 0.0; > } > > (Warning: I did not test my correction ;-) > > LEGALESE: > I confirm that, to the best of my knowledge and belief, this > contribution is free of any claims of third parties under > copyright, patent or other rights or interests ("claims"). To > the extent that I have any such claims, I hereby grant to CNRI a > nonexclusive, irrevocable, royalty-free, worldwide license to > reproduce, distribute, perform and/or display publicly, prepare > derivative versions, and otherwise use this contribution as part > of the Python software and its related documentation, or any > derivative versions thereof, at no cost to CNRI or its licensed > users, and to authorize others to do so. > > I acknowledge that CNRI may, at its sole discretion, decide > whether or not to incorporate this contribution in the Python > software and its related documentation. I further grant CNRI > permission to use my name and other identifying information > provided to CNRI by me for use in connection with the Python > software and its related documentation. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From mhammond@skippinet.com.au Tue Jun 6 00:54:29 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 09:54:29 +1000 Subject: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) In-Reply-To: <20000605160636.D55E61CE43@dinsdale.python.org> Message-ID: John also mailed me this personally. I have already responded that this is not a bug, but a known circular reference, and outlined a few ways aound it. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Tuesday, 6 June 2000 2:07 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks > memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Tue Jun 6 00:54:59 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Mon, 5 Jun 2000 19:54:59 -0400 (EDT) Subject: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) Message-ID: <20000605235459.A559A1CE6A@dinsdale.python.org> John also mailed me this personally. I have already responded that this is not a bug, but a known circular reference, and outlined a few ways aound it. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Tuesday, 6 June 2000 2:07 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks > memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From tim_one@email.msn.com Tue Jun 6 02:30:40 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 5 Jun 2000 21:30:40 -0400 Subject: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) In-Reply-To: <20000605160636.D55E61CE43@dinsdale.python.org> Message-ID: <001201bfcf56$d2f87aa0$0ca0143f@tim> Assigning a function object is actually harmless. The problem here is that you have an instance I, create a bound method object bound to I, then store the latter as an attribute of I: this creates a cycle (I.indirectFunc points to the bound method object, which in turn points back to I). This is a well-known case of cyclic trash that CPython's reference counting cannot reclaim (that is, it's not a bug, in that it's functioning as designed). Your only hopes for avoiding this behavior-- short of changing your code not to do this --are to use JPython, or wait for CPython to grow another flavor of storage reclamation. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Monday, June 05, 2000 12:07 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From tim_one@email.msn.com Tue Jun 6 02:30:56 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Mon, 5 Jun 2000 21:30:56 -0400 (EDT) Subject: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) Message-ID: <20000606013056.10C9A1CE70@dinsdale.python.org> Assigning a function object is actually harmless. The problem here is that you have an instance I, create a bound method object bound to I, then store the latter as an attribute of I: this creates a cycle (I.indirectFunc points to the bound method object, which in turn points back to I). This is a well-known case of cyclic trash that CPython's reference counting cannot reclaim (that is, it's not a bug, in that it's functioning as designed). Your only hopes for avoiding this behavior-- short of changing your code not to do this --are to use JPython, or wait for CPython to grow another flavor of storage reclamation. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Monday, June 05, 2000 12:07 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From gerry@certif.com Wed Jun 7 23:25:00 2000 From: gerry@certif.com (gerry@certif.com) Date: Wed, 7 Jun 2000 18:25:00 -0400 (EDT) Subject: [Python-bugs-list] Py_Initialize()/Py_Finalize() seg fault (PR#348) Message-ID: <20000607222500.D2EFE1CD18@dinsdale.python.org> Full_Name: Gerry Swislow Version: Python-1.6a2 OS: Linux RH 6.x Submission from: certified.ne.mediaone.net (24.147.233.100) When embedding python, the following program will have a segmentation fault during the second Py_Finalize(): main() { Py_Initialize(); Py_Finalize(); Py_Initialize(); Py_Finalize(); } The fault occurs in _PyUnicode_Fini() and should be easy to reproduce. It's not a problem in Python 1.5. From mal@lemburg.com Thu Jun 8 16:51:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:51:46 +0200 Subject: [Python-bugs-list] Py_Initialize()/Py_Finalize() seg fault (PR#348) References: <20000607222500.D2EFE1CD18@dinsdale.python.org> Message-ID: <393FC112.78AC15DC@lemburg.com> gerry@certif.com wrote: > > Full_Name: Gerry Swislow > Version: Python-1.6a2 > OS: Linux RH 6.x > Submission from: certified.ne.mediaone.net (24.147.233.100) > > When embedding python, the following program will have > a segmentation fault during the second Py_Finalize(): > > main() { > Py_Initialize(); > Py_Finalize(); > Py_Initialize(); > Py_Finalize(); > } > > The fault occurs in _PyUnicode_Fini() and should be easy > to reproduce. It's not a problem in Python 1.5. It's a problem with the Unicode free list. I'll fix it later today. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jun 8 16:59:58 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Thu, 8 Jun 2000 11:59:58 -0400 (EDT) Subject: [Python-bugs-list] Py_Initialize()/Py_Finalize() seg fault (PR#348) Message-ID: <20000608155958.BDF971CDD5@dinsdale.python.org> gerry@certif.com wrote: > > Full_Name: Gerry Swislow > Version: Python-1.6a2 > OS: Linux RH 6.x > Submission from: certified.ne.mediaone.net (24.147.233.100) > > When embedding python, the following program will have > a segmentation fault during the second Py_Finalize(): > > main() { > Py_Initialize(); > Py_Finalize(); > Py_Initialize(); > Py_Finalize(); > } > > The fault occurs in _PyUnicode_Fini() and should be easy > to reproduce. It's not a problem in Python 1.5. It's a problem with the Unicode free list. I'll fix it later today. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ctalley@caci.com Thu Jun 8 20:52:20 2000 From: ctalley@caci.com (ctalley@caci.com) Date: Thu, 8 Jun 2000 15:52:20 -0400 (EDT) Subject: [Python-bugs-list] getpass.getpass (PR#349) Message-ID: <20000608195220.B31EA1CF4C@dinsdale.python.org> Full_Name: Carl Talley Version: 1.5.2 OS: W95 Submission from: (NULL) (199.249.193.112) When using this code, the third line is skipped. That is, the prompt appears, but the program doesn't pause to accept input data. It goes right to the fourth line and pauses there. I end up with a null string for "fromaddr". username=raw_input('Enter FTP server account username: ') password=getpass.getpass('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') When using this code, everything works (although echo of the password isn't suppressed.) username=raw_input('Enter FTP server account username: ') password=raw_input('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') The difference between the two code segments is that the first uses the getpass method on the second line and the second uses raw_input. What I think is happening is that getpass is leaving some garbage in a buffer somewhere which is seen by raw_input as data. raw_input happily accepts the data and goes to the next line. I've devised several workarounds including "flush_input_buffer=raw_input('')" immediately following the call to getpass. It's ugly, but it works. Thanks, Carl Talley From ashar@vpharm.com Thu Jun 8 22:53:14 2000 From: ashar@vpharm.com (ashar@vpharm.com) Date: Thu, 8 Jun 2000 17:53:14 -0400 (EDT) Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal places (PR#350) Message-ID: <20000608215314.6C24A1CD9C@dinsdale.python.org> Full_Name: Raj Ashar Version: 1.5.2 OS: Windows NT 4.0 Submission from: fringe.vpharm.com (208.48.225.2) Hello. K. Sandretto and I believe we found the "<=" operator functions like a "<" when incrementing loop variables with numbers smaller than 0.1. For example, in her program, she writes: LoopVariable = 0 Increment = 0.05 while LoopVariable <= 1: print y From ashar@vpharm.com Thu Jun 8 23:01:44 2000 From: ashar@vpharm.com (ashar@vpharm.com) Date: Thu, 8 Jun 2000 18:01:44 -0400 (EDT) Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal places (PR#351) Message-ID: <20000608220144.98C411CD8E@dinsdale.python.org> Full_Name: Raj Ashar Version: 1.5.2 OS: Windows NT 4.0 Submission from: fringe.vpharm.com (208.48.225.2) Hello. K. Sandretto and I believe we found the "<=" operator functions like a "<" when incrementing loop variables with numbers smaller than 0.1. For example: LoopVariable = 0 Increment = 0.05 while LoopVariable <= 1: print LoopVariable LoopVariable = LoopVariable + Increment prints out 0.95 as the highest value, as the "<" operator would, rather than printing out 1.0 as well. When only the Increment was changed to 0.1 in this loop, the value 1.0 did get printed onscreen. Using the value 0.125 also printed out 1.0, but neither 0.025 nor 0.01 allowed 1.0 to appear onscreen. We have been able to also reproduce this result in Python 1.5 on an SGI running IRIX 6.4, and we appreciate any ideas on this matter. Raj From skip@mojam.com (Skip Montanaro) Fri Jun 9 17:13:24 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 9 Jun 2000 11:13:24 -0500 (CDT) Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal places (PR#351) In-Reply-To: <20000608220144.98C411CD8E@dinsdale.python.org> References: <20000608220144.98C411CD8E@dinsdale.python.org> Message-ID: <14657.6052.797803.807669@beluga.mojam.com> Raj> Hello. K. Sandretto and I believe we found the "<=" operator Raj> functions like a "<" when incrementing loop variables with numbers Raj> smaller than 0.1. No, you're just experiencing the inexactness of floating point arithmetic. You'd get the same results if you wrote your code in C. To avoid this particular case try the following code instead, which avoids the comparison of floating point numbers and only computes the interesting value when it's needed: LoopVariable = 0 Increment = 5 while LoopVariable <= 100: print LoopVariable / 100.0 LoopVariable = LoopVariable + Increment -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K: http://www.cararuns.org/raceinfo/otherevents.html http://www.chicagoaa.com/calendar/running.html#anchorjunerun From gpk@bell-labs.com Sat Jun 10 03:45:07 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Fri, 9 Jun 2000 22:45:07 -0400 (EDT) Subject: [Python-bugs-list] IDLE goto file/line (PR#352) Message-ID: <20000610024507.3F9881CF5B@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.6 CVS today OS: Solaris 2.6 Submission from: (NULL) (135.104.50.27) When using IDLE's shell window Debug->Go to file/line, you have to be overly careful what you select. Specifically, if you select a region that contains a newline, IDLE won't be able to find a file and line number. For example, if you select v-- from there File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in __str__ ^-- to there (i.e. 2 characters in, on the following line), you will get the following error message: "No special line: X the line you point to doesn't look like a file name followed by a line number." That is unfortunate, as it's really convenient to make a quick flick down from one line to the next, to select a complete line. By the way, the error box requires you to click "OK". That's a bug. It isn't OK. It's a crime against the King's English, committed by the minions of Bill Gates. You should not be following their lead. From tim_one@email.msn.com Sun Jun 11 19:24:45 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 11 Jun 2000 14:24:45 -0400 Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal places (PR#351) In-Reply-To: <20000608220144.98C411CD8E@dinsdale.python.org> Message-ID: <000201bfd3d2$51c32680$27a2143f@tim> As Skip said, this is a property of binary floating-point arithmetic regardless of language. Your basic problem is that 0.05 is not exactly representable in binary floating-point, and that's a bit hidden from you because Python doesn't print floating-point values to full precision by default. Try replacing print LoopVariable with print "%.17g" % LoopVariable to see more of what's really happening. On my box, that prints 0.050000000000000003 0.10000000000000001 0.15000000000000002 0.20000000000000001 0.25 0.29999999999999999 0.34999999999999998 0.39999999999999997 0.44999999999999996 0.49999999999999994 0.54999999999999993 0.59999999999999998 0.65000000000000002 0.70000000000000007 0.75000000000000011 0.80000000000000016 0.8500000000000002 0.90000000000000024 0.95000000000000029 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of ashar@vpharm.com > Sent: Thursday, June 08, 2000 6:02 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal > places (PR#351) > > > Full_Name: Raj Ashar > Version: 1.5.2 > OS: Windows NT 4.0 > Submission from: fringe.vpharm.com (208.48.225.2) > > > Hello. K. Sandretto and I believe we found the "<=" operator functions > like a "<" when incrementing loop variables with numbers smaller than 0.1. > > For example: > LoopVariable = 0 > Increment = 0.05 > > while LoopVariable <= 1: > print LoopVariable > LoopVariable = LoopVariable + Increment > > prints out 0.95 as the highest value, as the "<" operator would, > rather than printing out 1.0 as well. > > When only the Increment was changed to 0.1 in this loop, > the value 1.0 did get printed onscreen. Using the value 0.125 > also printed out 1.0, but neither 0.025 nor 0.01 allowed 1.0 to appear > onscreen. > > We have been able to also reproduce this result in Python 1.5 on an SGI > running IRIX 6.4, and we appreciate any ideas on this matter. > > > Raj > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From tim_one@email.msn.com Sun Jun 11 19:25:03 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Sun, 11 Jun 2000 14:25:03 -0400 (EDT) Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal places (PR#351) Message-ID: <20000611182503.3A0751CE31@dinsdale.python.org> As Skip said, this is a property of binary floating-point arithmetic regardless of language. Your basic problem is that 0.05 is not exactly representable in binary floating-point, and that's a bit hidden from you because Python doesn't print floating-point values to full precision by default. Try replacing print LoopVariable with print "%.17g" % LoopVariable to see more of what's really happening. On my box, that prints 0.050000000000000003 0.10000000000000001 0.15000000000000002 0.20000000000000001 0.25 0.29999999999999999 0.34999999999999998 0.39999999999999997 0.44999999999999996 0.49999999999999994 0.54999999999999993 0.59999999999999998 0.65000000000000002 0.70000000000000007 0.75000000000000011 0.80000000000000016 0.8500000000000002 0.90000000000000024 0.95000000000000029 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of ashar@vpharm.com > Sent: Thursday, June 08, 2000 6:02 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Inaccuracy of <= to two or more decimal > places (PR#351) > > > Full_Name: Raj Ashar > Version: 1.5.2 > OS: Windows NT 4.0 > Submission from: fringe.vpharm.com (208.48.225.2) > > > Hello. K. Sandretto and I believe we found the "<=" operator functions > like a "<" when incrementing loop variables with numbers smaller than 0.1. > > For example: > LoopVariable = 0 > Increment = 0.05 > > while LoopVariable <= 1: > print LoopVariable > LoopVariable = LoopVariable + Increment > > prints out 0.95 as the highest value, as the "<" operator would, > rather than printing out 1.0 as well. > > When only the Increment was changed to 0.1 in this loop, > the value 1.0 did get printed onscreen. Using the value 0.125 > also printed out 1.0, but neither 0.025 nor 0.01 allowed 1.0 to appear > onscreen. > > We have been able to also reproduce this result in Python 1.5 on an SGI > running IRIX 6.4, and we appreciate any ideas on this matter. > > > Raj > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From giusedia@libero.it Sun Jun 11 23:19:34 2000 From: giusedia@libero.it (giusedia@libero.it) Date: Sun, 11 Jun 2000 18:19:34 -0400 (EDT) Subject: [Python-bugs-list] W2k and pyton 1.5 (PR#353) Message-ID: <20000611221934.F1B591CE55@dinsdale.python.org> Full_Name: Giuseppe Doa Version: 1.5 OS: W2k Submission from: (NULL) (212.141.79.133) When installing pyton 1.5 in my w2k, i noticed an error message when starting IDLE(Pyton gui)as admin.The error was some dll not found, tk80.dll and tcl80.dll, in the c:\programmi\python\dlls dir. The program then continued normally. I fixed it copying them there and now starts normally. But IDLE(Pyton gui)keeps not starting at all while in user mode.Bye From gpk@bell-labs.com Tue Jun 13 15:05:37 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Tue, 13 Jun 2000 10:05:37 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 copy command (PR#354) Message-ID: <20000613140537.334DF1CE16@dinsdale.python.org> Full_Name: Greg Kochanski Version: 1.6a2+ OS: Solaris sparc 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) Alt-w is advertised to copy the selected text. It doesn't. It pops up the 'window' menu. However, even if you are in the 'edit' menu, alt-w apparently does nothing. I can select text, do alt-E alt-W, move the pointer, then do ctrl-Y, and nothing pops up. By the way, 'ctl-U ctl-U ctl-S' is an absurdly long sequence for something as common as searching for text. From gpk@bell-labs.com Tue Jun 13 16:30:15 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Tue, 13 Jun 2000 11:30:15 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <20000613153015.86BEA1CE46@dinsdale.python.org> Full_Name: Greg Kochanski Version: yesterday's CVS OS: Solaris 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) If you type ctrl-f5 to run a script twice in sucession, IDLE will incorrectly pop up a window saying "Not Saved. Please Save First." If you save (even though you haven't changed anything, and even though there are no asterisks around the window title), then ctrl-f5 will work again. This *doesn't* happen if you run the script twice in succession from the menu. From tim_one@email.msn.com Tue Jun 13 16:55:09 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 13 Jun 2000 11:55:09 -0400 Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) In-Reply-To: <20000613153015.86BEA1CE46@dinsdale.python.org> Message-ID: <000a01bfd54f$c0fb71a0$582d153f@tim> Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under Windows, but darned hard to see why that would matter. Can anyone else try this under Solaris 2.6? May have something to do with the specific script you're running, Greg; e.g., does it happen if the script file contains just print "Hi!" ? > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > Sent: Tuesday, June 13, 2000 11:30 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > Full_Name: Greg Kochanski > Version: yesterday's CVS > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > If you type ctrl-f5 to run a script twice in sucession, > IDLE will incorrectly pop up a window saying > "Not Saved. Please Save First." > > If you save (even though you haven't changed anything, > and even though there are no asterisks around the window > title), then ctrl-f5 will work again. > > This *doesn't* happen if you run the script twice in > succession from the menu. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From tim_one@email.msn.com Tue Jun 13 16:55:30 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 13 Jun 2000 11:55:30 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <20000613155530.A019F1CD5C@dinsdale.python.org> Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under Windows, but darned hard to see why that would matter. Can anyone else try this under Solaris 2.6? May have something to do with the specific script you're running, Greg; e.g., does it happen if the script file contains just print "Hi!" ? > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > Sent: Tuesday, June 13, 2000 11:30 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > Full_Name: Greg Kochanski > Version: yesterday's CVS > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > If you type ctrl-f5 to run a script twice in sucession, > IDLE will incorrectly pop up a window saying > "Not Saved. Please Save First." > > If you save (even though you haven't changed anything, > and even though there are no asterisks around the window > title), then ctrl-f5 will work again. > > This *doesn't* happen if you run the script twice in > succession from the menu. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mredar@yahoo.com Tue Jun 13 21:06:00 2000 From: mredar@yahoo.com (mredar@yahoo.com) Date: Tue, 13 Jun 2000 16:06:00 -0400 (EDT) Subject: [Python-bugs-list] cgi parsing of query strings (PR#356) Message-ID: <20000613200600.B2CB31CEEE@dinsdale.python.org> Full_Name: Mark Redar Version: 1.5.2 OS: linux Submission from: pat-global.digital-integrity.com (64.1.242.30) I am currently starting to use the cgi module for python. In general it's quite nice, I love the builtin "test" function--very handy. I do have a quibble with the handling of query strings by the parser. In the HTML 4 specification, appendix B it is stated: B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written or . We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. The recommended handling of ';' as field delimiters is not implemented in this module. Do you have any plans to implement this feature? My current company is going to use the ';' separator and it works with other cgi packages (perl & java servlets). I'd love to use python, but this is a stumbling block. Thanks, Mark From snajdr@firma.seznam.cz Thu Jun 15 14:51:52 2000 From: snajdr@firma.seznam.cz (snajdr@firma.seznam.cz) Date: Thu, 15 Jun 2000 09:51:52 -0400 (EDT) Subject: [Python-bugs-list] smtplib - some bugs in code and documentation too(?!) (PR#357) Message-ID: <20000615135152.7A1EC1CF6A@dinsdale.python.org> --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/plain Content-Transfer-Encoding: 8bit Hello, I need library for communication with SMTP server last week. I looked for smtplib from Python distribution, but I think that there are a number of bugs: 1. SMTP object work different then you wrote in documentation See:http://www.python.org/doc/current/lib/module-smtplib.html http://www.python.org/doc/current/lib/SMTP-example.html 2. default port is 0 (SMTP() constructor) I think that 25 is better number. 3.default hostname in constructor is ''. I think that 'localhost' is better choice 4. def connect(self, host='localhost', port = 0). You replace parameters from constructor! ( def __init__(self, host = '', port = 0)!) Is it good idea? Example from Python Library Reference: [...] server = smtplib.SMTP('localhost') server.set_debuglevel(1) server.connect() server.sendmail(fromaddr, toaddrs, msg) server.quit() [...] It can't work ! > server = smtplib.SMTP('localhost') OK, you want connect to localhost and port 0? No. :-( > server.set_debuglevel(1) > server.connect() You connect to localhost to port 0. It is not good idea. ;-) > server.sendmail(fromaddr, toaddrs, msg) > server.quit() I have Python 1.5.2 (#21, Aug 31 1999, 17:23:40) [GCC 2.7.2.3] on linux2 (Debian Linux) -- Best regards Petr Snajdr --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/english; name="smtplib.py.patch" Content-Transfer-Encoding: base64 Content-Description: My patch of smtplib Content-Disposition: attachment; filename="smtplib.py.patch" KioqIHNtdHBsaWIucHkJVGh1IEp1biAxNSAxMzowMDo1MCAyMDAwCi0tLSBzbXRwbGliMi5weQlU aHUgSnVuIDE1IDE1OjA5OjM3IDIwMDAKKioqKioqKioqKioqKioqCioqKiAxNjgsMTc0ICoqKioK ICAgICAgZWhsb19yZXNwID0gTm9uZQogICAgICBkb2VzX2VzbXRwID0gMAogIAohICAgICBkZWYg X19pbml0X18oc2VsZiwgaG9zdCA9ICcnLCBwb3J0ID0gMCk6CiAgICAgICAgICAiIiJJbml0aWFs aXplIGEgbmV3IGluc3RhbmNlLgogIAogICAgICAgICAgSWYgc3BlY2lmaWVkLCBgaG9zdCcgaXMg dGhlIG5hbWUgb2YgdGhlIHJlbW90ZSBob3N0IHRvIHdoaWNoIHRvCi0tLSAxNjgsMTc0IC0tLS0K ICAgICAgZWhsb19yZXNwID0gTm9uZQogICAgICBkb2VzX2VzbXRwID0gMAogIAohICAgICBkZWYg X19pbml0X18oc2VsZiwgaG9zdCA9ICdsb2NhbGhvc3QnLCBwb3J0ID0gMjUpOgogICAgICAgICAg IiIiSW5pdGlhbGl6ZSBhIG5ldyBpbnN0YW5jZS4KICAKICAgICAgICAgIElmIHNwZWNpZmllZCwg YGhvc3QnIGlzIHRoZSBuYW1lIG9mIHRoZSByZW1vdGUgaG9zdCB0byB3aGljaCB0bwoqKioqKioq KioqKioqKioKKioqIDE3NywxODIgKioqKgotLS0gMTc3LDE4NSAtLS0tCiAgICAgICAgICByYWlz ZWQgaWYgdGhlIHNwZWNpZmllZCBgaG9zdCcgZG9lc24ndCByZXNwb25kIGNvcnJlY3RseS4KICAK ICAgICAgICAgICIiIgorICAgICAgICAgc2VsZi5fX2hvc3Q9aG9zdAorICAgICAgICAgc2VsZi5f X3BvcnQ9cG9ydAorICAgICAgICAgCiAgICAgICAgICBzZWxmLmVzbXRwX2ZlYXR1cmVzID0ge30K ICAgICAgICAgIGlmIGhvc3Q6CiAgICAgICAgICAgICAgKGNvZGUsIG1zZykgPSBzZWxmLmNvbm5l Y3QoaG9zdCwgcG9ydCkKKioqKioqKioqKioqKioqCioqKiAxOTIsMTk4ICoqKioKICAgICAgICAg ICIiIgogICAgICAgICAgc2VsZi5kZWJ1Z2xldmVsID0gZGVidWdsZXZlbAogIAohICAgICBkZWYg Y29ubmVjdChzZWxmLCBob3N0PSdsb2NhbGhvc3QnLCBwb3J0ID0gMCk6CiAgICAgICAgICAiIiJD b25uZWN0IHRvIGEgaG9zdCBvbiBhIGdpdmVuIHBvcnQuCiAgCiAgICAgICAgICBJZiB0aGUgaG9z dG5hbWUgZW5kcyB3aXRoIGEgY29sb24gKGA6JykgZm9sbG93ZWQgYnkgYSBudW1iZXIsIGFuZAot LS0gMTk1LDIwMSAtLS0tCiAgICAgICAgICAiIiIKICAgICAgICAgIHNlbGYuZGVidWdsZXZlbCA9 IGRlYnVnbGV2ZWwKICAKISAgICAgZGVmIGNvbm5lY3Qoc2VsZiwgaG9zdD1Ob25lLCBwb3J0PU5v bmUpOgogICAgICAgICAgIiIiQ29ubmVjdCB0byBhIGhvc3Qgb24gYSBnaXZlbiBwb3J0LgogIAog ICAgICAgICAgSWYgdGhlIGhvc3RuYW1lIGVuZHMgd2l0aCBhIGNvbG9uIChgOicpIGZvbGxvd2Vk IGJ5IGEgbnVtYmVyLCBhbmQKKioqKioqKioqKioqKioqCioqKiAyMDMsMjA4ICoqKioKLS0tIDIw NiwyMTYgLS0tLQogICAgICAgICAgc3BlY2lmaWVkIGR1cmluZyBpbnN0YW50aWF0aW9uLgogIAog ICAgICAgICAgIiIiCisgICAgICAgICBpZiBob3N0PT1Ob25lOgorICAgICAgICAgICAgIGhvc3Q9 c2VsZi5fX2hvc3QKKyAgICAgICAgIGlmIHBvcnQ9PU5vbmU6CisgICAgICAgICAgICAgcG9ydD1z ZWxmLl9fcG9ydAorICAgICAgICAgICAgIAogICAgICAgICAgaWYgbm90IHBvcnQ6CiAgICAgICAg ICAgICAgaSA9IHN0cmluZy5maW5kKGhvc3QsICc6JykKICAgICAgICAgICAgICBpZiBpID49IDA6 CioqKioqKioqKioqKioqKgoqKiogMjUxLDI1NyAqKioqCiAgICAgICAgICBpZiBzZWxmLmZpbGUg aXMgTm9uZToKICAgICAgICAgICAgICBzZWxmLmZpbGUgPSBzZWxmLnNvY2subWFrZWZpbGUoJ3Ji JykKICAgICAgICAgIHdoaWxlIDE6Ci0gICAgICAgICAgICAgcHJpbnQgIk9LIgogICAgICAgICAg ICAgIGxpbmUgPSBzZWxmLmZpbGUucmVhZGxpbmUoKQogICAgICAgICAgICAgIHByaW50IGxpbmUg CiAgICAgICAgICAgICAgaWYgbGluZSA9PSAnJzoKLS0tIDI1OSwyNjQgLS0tLQo= --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD-- From fdrake@beopen.com Thu Jun 15 15:25:18 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 10:25:18 -0400 (EDT) Subject: [Python-bugs-list] smtplib - some bugs in code and documentation too(?!) (PR#357) In-Reply-To: <20000615135152.7A1EC1CF6A@dinsdale.python.org> References: <20000615135152.7A1EC1CF6A@dinsdale.python.org> Message-ID: <14664.59214.807372.629875@cj42289-a.reston1.va.home.com> snajdr@firma.seznam.cz writes: > 1. SMTP object work different then you wrote in documentation > See:http://www.python.org/doc/current/lib/module-smtplib.html > http://www.python.org/doc/current/lib/SMTP-example.html The example in the documentation has been corrected in the sources; this will be released with the Python 1.6 documentation. If you find other errors in the documentation, I'd like to know about them in a new bug report. > 2. default port is 0 (SMTP() constructor) I think that 25 is > better number. If a false value is used, the value of smtplib.SMTP_PORT is used instead. The use of a false value replaced with the real value is fairly conventional throughout Python libraries, and is a matter of programming style. > 3.default hostname in constructor is ''. I think that > 'localhost' is better choice The use of '' in the constructor is used to determine whether the connection should be built automatically or delayed until the user calls the connect() method. Calling connect() without specifying the host does use 'localhost'. > 4. def connect(self, host='localhost', port = 0). You replace > parameters from constructor! ( def __init__(self, > host = '', port = 0)!) Is it good idea? These default values are only used when the constructor does not call connect(); the constructor provides all parameters when it does call connect(). > OK, you want connect to localhost and port 0? > No. :-( See my comment to issue 2 above; the proper port number is used. > > server.set_debuglevel(1) > > server.connect() > > You connect to localhost to port 0. It is not good > idea. ;-) Connecting twice doesn't work either; this bug in the example has been corrected in the sources by removing the unnecessary call to connect(). I'm going to reclassify this bug report as "resolved" (since there really was a documentation bug that's been fixed); if you feel this is not correct, please submit a new bug report. Thanks for your attention to detail! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jun 15 15:25:58 2000 From: fdrake@beopen.com (fdrake@beopen.com) Date: Thu, 15 Jun 2000 10:25:58 -0400 (EDT) Subject: [Python-bugs-list] smtplib - some bugs in code and documentation too(?!) (PR#357) Message-ID: <20000615142558.47CB11CF7A@dinsdale.python.org> snajdr@firma.seznam.cz writes: > 1. SMTP object work different then you wrote in documentation > See:http://www.python.org/doc/current/lib/module-smtplib.html > http://www.python.org/doc/current/lib/SMTP-example.html The example in the documentation has been corrected in the sources; this will be released with the Python 1.6 documentation. If you find other errors in the documentation, I'd like to know about them in a new bug report. > 2. default port is 0 (SMTP() constructor) I think that 25 is > better number. If a false value is used, the value of smtplib.SMTP_PORT is used instead. The use of a false value replaced with the real value is fairly conventional throughout Python libraries, and is a matter of programming style. > 3.default hostname in constructor is ''. I think that > 'localhost' is better choice The use of '' in the constructor is used to determine whether the connection should be built automatically or delayed until the user calls the connect() method. Calling connect() without specifying the host does use 'localhost'. > 4. def connect(self, host='localhost', port = 0). You replace > parameters from constructor! ( def __init__(self, > host = '', port = 0)!) Is it good idea? These default values are only used when the constructor does not call connect(); the constructor provides all parameters when it does call connect(). > OK, you want connect to localhost and port 0? > No. :-( See my comment to issue 2 above; the proper port number is used. > > server.set_debuglevel(1) > > server.connect() > > You connect to localhost to port 0. It is not good > idea. ;-) Connecting twice doesn't work either; this bug in the example has been corrected in the sources by removing the unnecessary call to connect(). I'm going to reclassify this bug report as "resolved" (since there really was a documentation bug that's been fixed); if you feel this is not correct, please submit a new bug report. Thanks for your attention to detail! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From snajdr@firma.seznam.cz Thu Jun 15 15:30:22 2000 From: snajdr@firma.seznam.cz (snajdr@firma.seznam.cz) Date: Thu, 15 Jun 2000 10:30:22 -0400 (EDT) Subject: [Python-bugs-list] Undelivered Mail Returned to Sender (PR#357) Message-ID: <20000615143022.3CCC81CF81@dinsdale.python.org> This is a MIME-encapsulated message. --267041CF81.961079419/dinsdale.python.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host dinsdale.python.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please contact If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : unknown user: "already" : unknown user: "fixed" --267041CF81.961079419/dinsdale.python.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from localhost (parrot.python.org [132.151.1.90]) by dinsdale.python.org (Postfix) with ESMTP id 267041CF81; Thu, 15 Jun 2000 10:30:16 -0400 (EDT) From: bugs-py@python.org To: already@python.org, fixed@python.org Subject: Notification: PR#357 X-Notification: bugs-py@python.org Message-Id: <20000615143016.267041CF81@dinsdale.python.org> Date: Thu, 15 Jun 2000 10:30:16 -0400 (EDT) Python Bugs notification fdrake moved PR#357 from incoming to resolved Message summary for PR#357 From: Petr Snajdr Subject: smtplib - some bugs in code and documentation too(?!) Date: Thu, 15 Jun 2000 15:11:10 0200 0 replies 1 followups URL: http://www.python.org/python-bugs?findid=357 Notes: Documentation bug had already been fixed. Other issues in this report were non-bugs and are explained in the email. ====> ORIGINAL MESSAGE FOLLOWS <==== From snajdr@firma.seznam.cz Thu Jun 15 14:11:10 2000 From: snajdr@firma.seznam.cz (Petr Snajdr) Date: Thu, 15 Jun 2000 15:11:10 +0200 Subject: smtplib - some bugs in code and documentation too(?!) Message-ID: <00061515515000.02842@petr> --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/plain Content-Transfer-Encoding: 8bit Hello, I need library for communication with SMTP server last week. I looked for smtplib from Python distribution, but I think that there are a number of bugs: 1. SMTP object work different then you wrote in documentation See:http://www.python.org/doc/current/lib/module-smtplib.html http://www.python.org/doc/current/lib/SMTP-example.html 2. default port is 0 (SMTP() constructor) I think that 25 is better number. 3.default hostname in constructor is ''. I think that 'localhost' is better choice 4. def connect(self, host='localhost', port = 0). You replace parameters from constructor! ( def __init__(self, host = '', port = 0)!) Is it good idea? Example from Python Library Reference: [...] server = smtplib.SMTP('localhost') server.set_debuglevel(1) server.connect() server.sendmail(fromaddr, toaddrs, msg) server.quit() [...] It can't work ! > server = smtplib.SMTP('localhost') OK, you want connect to localhost and port 0? No. :-( > server.set_debuglevel(1) > server.connect() You connect to localhost to port 0. It is not good idea. ;-) > server.sendmail(fromaddr, toaddrs, msg) > server.quit() I have Python 1.5.2 (#21, Aug 31 1999, 17:23:40) [GCC 2.7.2.3] on linux2 (Debian Linux) -- Best regards Petr Snajdr --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/english; name="smtplib.py.patch" Content-Transfer-Encoding: base64 Content-Description: My patch of smtplib Content-Disposition: attachment; filename="smtplib.py.patch" KioqIHNtdHBsaWIucHkJVGh1IEp1biAxNSAxMzowMDo1MCAyMDAwCi0tLSBzbXRwbGliMi5weQlU aHUgSnVuIDE1IDE1OjA5OjM3IDIwMDAKKioqKioqKioqKioqKioqCioqKiAxNjgsMTc0ICoqKioK ICAgICAgZWhsb19yZXNwID0gTm9uZQogICAgICBkb2VzX2VzbXRwID0gMAogIAohICAgICBkZWYg X19pbml0X18oc2VsZiwgaG9zdCA9ICcnLCBwb3J0ID0gMCk6CiAgICAgICAgICAiIiJJbml0aWFs aXplIGEgbmV3IGluc3RhbmNlLgogIAogICAgICAgICAgSWYgc3BlY2lmaWVkLCBgaG9zdCcgaXMg dGhlIG5hbWUgb2YgdGhlIHJlbW90ZSBob3N0IHRvIHdoaWNoIHRvCi0tLSAxNjgsMTc0IC0tLS0K ICAgICAgZWhsb19yZXNwID0gTm9uZQogICAgICBkb2VzX2VzbXRwID0gMAogIAohICAgICBkZWYg X19pbml0X18oc2VsZiwgaG9zdCA9ICdsb2NhbGhvc3QnLCBwb3J0ID0gMjUpOgogICAgICAgICAg IiIiSW5pdGlhbGl6ZSBhIG5ldyBpbnN0YW5jZS4KICAKICAgICAgICAgIElmIHNwZWNpZmllZCwg YGhvc3QnIGlzIHRoZSBuYW1lIG9mIHRoZSByZW1vdGUgaG9zdCB0byB3aGljaCB0bwoqKioqKioq KioqKioqKioKKioqIDE3NywxODIgKioqKgotLS0gMTc3LDE4NSAtLS0tCiAgICAgICAgICByYWlz ZWQgaWYgdGhlIHNwZWNpZmllZCBgaG9zdCcgZG9lc24ndCByZXNwb25kIGNvcnJlY3RseS4KICAK ICAgICAgICAgICIiIgorICAgICAgICAgc2VsZi5fX2hvc3Q9aG9zdAorICAgICAgICAgc2VsZi5f X3BvcnQ9cG9ydAorICAgICAgICAgCiAgICAgICAgICBzZWxmLmVzbXRwX2ZlYXR1cmVzID0ge30K ICAgICAgICAgIGlmIGhvc3Q6CiAgICAgICAgICAgICAgKGNvZGUsIG1zZykgPSBzZWxmLmNvbm5l Y3QoaG9zdCwgcG9ydCkKKioqKioqKioqKioqKioqCioqKiAxOTIsMTk4ICoqKioKICAgICAgICAg ICIiIgogICAgICAgICAgc2VsZi5kZWJ1Z2xldmVsID0gZGVidWdsZXZlbAogIAohICAgICBkZWYg Y29ubmVjdChzZWxmLCBob3N0PSdsb2NhbGhvc3QnLCBwb3J0ID0gMCk6CiAgICAgICAgICAiIiJD b25uZWN0IHRvIGEgaG9zdCBvbiBhIGdpdmVuIHBvcnQuCiAgCiAgICAgICAgICBJZiB0aGUgaG9z dG5hbWUgZW5kcyB3aXRoIGEgY29sb24gKGA6JykgZm9sbG93ZWQgYnkgYSBudW1iZXIsIGFuZAot LS0gMTk1LDIwMSAtLS0tCiAgICAgICAgICAiIiIKICAgICAgICAgIHNlbGYuZGVidWdsZXZlbCA9 IGRlYnVnbGV2ZWwKICAKISAgICAgZGVmIGNvbm5lY3Qoc2VsZiwgaG9zdD1Ob25lLCBwb3J0PU5v bmUpOgogICAgICAgICAgIiIiQ29ubmVjdCB0byBhIGhvc3Qgb24gYSBnaXZlbiBwb3J0LgogIAog ICAgICAgICAgSWYgdGhlIGhvc3RuYW1lIGVuZHMgd2l0aCBhIGNvbG9uIChgOicpIGZvbGxvd2Vk IGJ5IGEgbnVtYmVyLCBhbmQKKioqKioqKioqKioqKioqCioqKiAyMDMsMjA4ICoqKioKLS0tIDIw NiwyMTYgLS0tLQogICAgICAgICAgc3BlY2lmaWVkIGR1cmluZyBpbnN0YW50aWF0aW9uLgogIAog ICAgICAgICAgIiIiCisgICAgICAgICBpZiBob3N0PT1Ob25lOgorICAgICAgICAgICAgIGhvc3Q9 c2VsZi5fX2hvc3QKKyAgICAgICAgIGlmIHBvcnQ9PU5vbmU6CisgICAgICAgICAgICAgcG9ydD1z ZWxmLl9fcG9ydAorICAgICAgICAgICAgIAogICAgICAgICAgaWYgbm90IHBvcnQ6CiAgICAgICAg ICAgICAgaSA9IHN0cmluZy5maW5kKGhvc3QsICc6JykKICAgICAgICAgICAgICBpZiBpID49IDA6 CioqKioqKioqKioqKioqKgoqKiogMjUxLDI1NyAqKioqCiAgICAgICAgICBpZiBzZWxmLmZpbGUg aXMgTm9uZToKICAgICAgICAgICAgICBzZWxmLmZpbGUgPSBzZWxmLnNvY2subWFrZWZpbGUoJ3Ji JykKICAgICAgICAgIHdoaWxlIDE6Ci0gICAgICAgICAgICAgcHJpbnQgIk9LIgogICAgICAgICAg ICAgIGxpbmUgPSBzZWxmLmZpbGUucmVhZGxpbmUoKQogICAgICAgICAgICAgIHByaW50IGxpbmUg CiAgICAgICAgICAgICAgaWYgbGluZSA9PSAnJzoKLS0tIDI1OSwyNjQgLS0tLQo= --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD-- --267041CF81.961079419/dinsdale.python.org-- From jbearce@copeland.com Fri Jun 16 00:37:02 2000 From: jbearce@copeland.com (jbearce@copeland.com) Date: Thu, 15 Jun 2000 19:37:02 -0400 (EDT) Subject: [Python-bugs-list] rfc822 (PR#358) Message-ID: <20000615233702.095B91D017@dinsdale.python.org> Full_Name: Jim Bearce Version: 1.5.2 OS: RedHat Linux 6.2 Submission from: corporate.copeland.com (209.191.12.130) For very long headers returned from a web server rfc822.readheaders does not correctly build the header. The following patch fixes it in my situation but I don't know if I broke anything else: Example Header: Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004 This ends up as https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLA and the rest of the header (along with any headers following this one) get returned as part of the message. --- /usr/lib/python1.5/rfc822.py.orig Thu Jun 15 19:35:42 2000 +++ /usr/lib/python1.5/rfc822.py Thu Jun 15 19:36:00 2000 @@ -125,6 +125,7 @@ self.status = '' headerseen = "" firstline = 1 + lastheader = '' startofline = unread = tell = None if hasattr(self.fp, 'unread'): unread = self.fp.unread @@ -150,16 +151,22 @@ continue elif self.iscomment(line): # It's a comment. Ignore it. + lastheader = '' continue elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten. + lastheader = '' break headerseen = self.isheader(line) if headerseen: # It's a legal header line, save it. list.append(line) self.dict[headerseen] = string.strip(line[len(headerseen)+2:]) + lastheader = headerseen continue + elif lastheader: + list.append(line) + self.dict[lastheader] = self.dict[lastheader] + string.strip(line) else: # It's not a header line; throw it back and stop here. if not self.dict: From harishbk@inf.com Fri Jun 16 08:46:59 2000 From: harishbk@inf.com (harishbk@inf.com) Date: Fri, 16 Jun 2000 03:46:59 -0400 (EDT) Subject: [Python-bugs-list] getpass() echo password input (PR#359) Message-ID: <20000616074659.E7E1B1CEAD@dinsdale.python.org> Full_Name: harish Version: 1.5.2 OS: OSF1 version 4.0f Submission from: (NULL) (202.54.39.82) code: #! /usr/local/bin/python import getpass pas=getpass.getpass() when it is run password : harish it is echoing password input. How can we avoid echoing it. From mal@lemburg.com Fri Jun 16 09:03:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 10:03:55 +0200 Subject: [Python-bugs-list] getpass() echo password input (PR#359) References: <20000616074659.E7E1B1CEAD@dinsdale.python.org> Message-ID: <3949DF6B.8F4C848B@lemburg.com> harishbk@inf.com wrote: > > Full_Name: harish > Version: 1.5.2 > OS: OSF1 version 4.0f > Submission from: (NULL) (202.54.39.82) > > code: > > #! /usr/local/bin/python > > import getpass > pas=getpass.getpass() > > when it is run > password : harish > > it is echoing password input. How can we avoid echoing it. You will need to compile Python with termios support enabled to have getpass() turn off echoing. (Edit Modules/Setup and rerun 'make install'.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jun 16 09:04:40 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Fri, 16 Jun 2000 04:04:40 -0400 (EDT) Subject: [Python-bugs-list] getpass() echo password input (PR#359) Message-ID: <20000616080440.874B21CED2@dinsdale.python.org> harishbk@inf.com wrote: > > Full_Name: harish > Version: 1.5.2 > OS: OSF1 version 4.0f > Submission from: (NULL) (202.54.39.82) > > code: > > #! /usr/local/bin/python > > import getpass > pas=getpass.getpass() > > when it is run > password : harish > > it is echoing password input. How can we avoid echoing it. You will need to compile Python with termios support enabled to have getpass() turn off echoing. (Edit Modules/Setup and rerun 'make install'.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From philipp.jocham@salomon.at Fri Jun 16 13:47:08 2000 From: philipp.jocham@salomon.at (philipp.jocham@salomon.at) Date: Fri, 16 Jun 2000 08:47:08 -0400 (EDT) Subject: [Python-bugs-list] Compiling python on hpux 11.00 with threads (PR#360) Message-ID: <20000616124708.55B141D066@dinsdale.python.org> Full_Name: Philipp Jocham Version: 1.5.2 OS: HP-UX 11.00 Submission from: mailhost.salomon.at (192.64.28.5) There are two missing details in the configure process to make this work out of the box. First: The function pthread_create isn't found in library libpthread.a but in libcma.a, because pthread_create is just a macro in sys/pthread.h pointing to __pthread_create_system After patching ./configure directly and running ./configure --with-thread (now detecting the correct library /usr/lib/libpthread.a) I also added -lcl to Modules/Makefile at LIBS= -lnet -lnsl -ldld -lpthread -lcl otherwise importing of modules with threads didn't work (in this case oci_.sl from DCOracle). I'm not sure about the correct syntax or wether it's the correct place and method, but I would suggest a solution like the following code snippet. [...] AC_MSG_CHECKING(for --with-thread) [...] AC_DEFINE(_POSIX_THREADS) LIBS="$LIBS -lpthread -lcl" LIBOBJS="$LIBOBJS thread.o"], [ AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD) [...] I hope this helps to make installation process smoother. Fell free to contact me, if there are further questions. Philipp -- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From cfandrich@8cs.com Sat Jun 17 01:08:34 2000 From: cfandrich@8cs.com (cfandrich@8cs.com) Date: Fri, 16 Jun 2000 20:08:34 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) Message-ID: <20000617000834.C29B41CF4A@dinsdale.python.org> Full_Name: Christopher Fandrich Version: 1.5.2 OS: Windows Submission from: (NULL) (208.41.174.4) I'm embedding Python in an application. For now, all I'm doing is initializing and finalizing Python. When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed by dictresize() which is called by PyDict_SetItem() which is called by PyString_InternInPlace(). For now, I've added PyDict_Clear(interned); interned = NULL; to PyString_Fini(). So far it works fine, but I don't know if it's safe to do in the grand scheme of things. -Chris From mal@lemburg.com Sat Jun 17 09:53:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:53:20 +0200 Subject: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) References: <20000617000834.C29B41CF4A@dinsdale.python.org> Message-ID: <394B3C80.248B4CB1@lemburg.com> cfandrich@8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jun 17 09:54:00 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Sat, 17 Jun 2000 04:54:00 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) Message-ID: <20000617085400.57B941CDDF@dinsdale.python.org> cfandrich@8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From lorenzo@sancho.ccd.uniroma2.it Sat Jun 17 15:47:51 2000 From: lorenzo@sancho.ccd.uniroma2.it (lorenzo@sancho.ccd.uniroma2.it) Date: Sat, 17 Jun 2000 10:47:51 -0400 (EDT) Subject: [Python-bugs-list] struct module inconsistency (PR#362) Message-ID: <20000617144751.EAC4D1CD52@dinsdale.python.org> Full_Name: Lorenzo M. Catucci Version: 1.5.2, 1.6a2 OS: Linux-i386 Submission from: ip022.pool-300.cyb.it (195.191.58.86) I don't know if this is a module or a documentation, but in struct module's documentation, i read "Alternatively, the first character of the format string can be used to indicate the byte order, size and alignment of the packed data, according to the following table:[...]". Now, I'm trying to wrap some video IOCTLS for linux/python use, and I have a struct like: audio_fmt='iHHHI16sHHH'; the compiler (at least for the i386 arch) puts in pad-bytes after those ushort; therefore, when I saw I and the kernel were using different struct sizes, I tried putting the magic `@' sign, but no padding came in, and I still had a py struct different than the C one. The stopgap solution has been putting in 0i alignment points like in audio_fmt='ihhh0ii16shhh0i', but it sounds like such stuff should be done by the @, especially since the module knows the system it was compiled on, while I don't know if a pure python module I manually aligned for i386 would work on a PowerPC or an Alpha system! So stop and thank you all. Yours, lorenzo m catucci From cfandrich@8cs.com Tue Jun 20 01:14:38 2000 From: cfandrich@8cs.com (cfandrich@8cs.com) Date: Mon, 19 Jun 2000 20:14:38 -0400 (EDT) Subject: [Python-bugs-list] _PyBuiltin_Init memory leak (PR#363) Message-ID: <20000620001438.8FEBC1CD0A@dinsdale.python.org> Full_Name: Christopher Fandrich Version: 1.5.2 OS: Windows Submission from: (NULL) (208.41.174.4) I think there's a memory leak in _PyBuiltin_Init on the following line: if (PyDict_SetItemString(dict, "__debug__", PyInt_FromLong(Py_OptimizeFlag == 0)) < 0) If I understand this correctly, PyInt_FromLong incref's its return value once, and PyDict_SetItemString incref's it a second time. I think this is preventing the "__debug__" value from being deleted. If this is so, the following patch should fix it. Index: ./1.5.2a/Python/bltinmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v retrieving revision 2.161 diff -c -r2.161 bltinmodule.c *** ./1.5.2a/Python/bltinmodule.c 2000/05/25 23:15:05 2.161 --- ./1.5.2a/Python/bltinmodule.c 2000/06/20 00:03:20 *************** *** 2364,2370 **** PyObject * _PyBuiltin_Init() { ! PyObject *mod, *dict; mod = Py_InitModule4("__builtin__", builtin_methods, builtin_doc, (PyObject *)NULL, PYTHON_API_VERSION); --- 2364,2370 ---- PyObject * _PyBuiltin_Init() { ! PyObject *mod, *dict, *debug; mod = Py_InitModule4("__builtin__", builtin_methods, builtin_doc, (PyObject *)NULL, PYTHON_API_VERSION); *************** *** 2375,2383 **** return NULL; if (PyDict_SetItemString(dict, "Ellipsis", Py_Ellipsis) < 0) return NULL; ! if (PyDict_SetItemString(dict, "__debug__", ! PyInt_FromLong(Py_OptimizeFlag == 0)) < 0) return NULL; return mod; } --- 2375,2387 ---- return NULL; if (PyDict_SetItemString(dict, "Ellipsis", Py_Ellipsis) < 0) return NULL; ! debug = PyInt_FromLong(Py_OptimizeFlag == 0); ! if (PyDict_SetItemString(dict, "__debug__",debug) < 0) ! { ! Py_XDECREF(debug); return NULL; + } + Py_XDECREF(debug); return mod; } ----------------------------------------------------------------- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. -chris From fdrake@beopen.com Tue Jun 20 05:56:51 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 00:56:51 -0400 (EDT) Subject: [Python-bugs-list] _PyBuiltin_Init memory leak (PR#363) In-Reply-To: <20000620001438.8FEBC1CD0A@dinsdale.python.org> References: <20000620001438.8FEBC1CD0A@dinsdale.python.org> Message-ID: <14670.63891.996188.561527@cj42289-a.reston1.va.home.com> cfandrich@8cs.com writes: > I think there's a memory leak in _PyBuiltin_Init on the following line: You're right! I've accepted your patch and flagged the bug report as resolved. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Tue Jun 20 05:57:50 2000 From: fdrake@beopen.com (fdrake@beopen.com) Date: Tue, 20 Jun 2000 00:57:50 -0400 (EDT) Subject: [Python-bugs-list] _PyBuiltin_Init memory leak (PR#363) Message-ID: <20000620045750.108661CE29@dinsdale.python.org> cfandrich@8cs.com writes: > I think there's a memory leak in _PyBuiltin_Init on the following line: You're right! I've accepted your patch and flagged the bug report as resolved. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Tue Jun 20 22:42:57 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 16:42:57 -0500 Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) In-Reply-To: Your message of "Tue, 13 Jun 2000 11:55:09 -0400." <000a01bfd54f$c0fb71a0$582d153f@tim> References: <000a01bfd54f$c0fb71a0$582d153f@tim> Message-ID: <200006202142.QAA01711@cj20424-a.reston1.va.home.com> I think I understand this. It's happened to me too. Pressing ^F5 changes the focus to the PyShell window. Pressing ^F5 again then indeed complains about that window being unsaved. --Guido van Rossum (home page: http://www.python.org/~guido/) [Tim] > Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under > Windows, but darned hard to see why that would matter. Can anyone else try > this under Solaris 2.6? May have something to do with the specific script > you're running, Greg; e.g., does it happen if the script file contains just > > print "Hi!" > > ? > > > -----Original Message----- > > From: python-bugs-list-admin@python.org > > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > > Sent: Tuesday, June 13, 2000 11:30 AM > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > > > > Full_Name: Greg Kochanski > > Version: yesterday's CVS > > OS: Solaris 2.6 > > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > > > > If you type ctrl-f5 to run a script twice in sucession, > > IDLE will incorrectly pop up a window saying > > "Not Saved. Please Save First." > > > > If you save (even though you haven't changed anything, > > and even though there are no asterisks around the window > > title), then ctrl-f5 will work again. > > > > This *doesn't* happen if you run the script twice in > > succession from the menu. > > > > > > > > _______________________________________________ > > Python-bugs-list maillist - Python-bugs-list@python.org > > http://www.python.org/mailman/listinfo/python-bugs-list > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From guido@python.org Tue Jun 20 21:41:02 2000 From: guido@python.org (guido@python.org) Date: Tue, 20 Jun 2000 16:41:02 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <20000620204102.78B631CD6A@dinsdale.python.org> I think I understand this. It's happened to me too. Pressing ^F5 changes the focus to the PyShell window. Pressing ^F5 again then indeed complains about that window being unsaved. --Guido van Rossum (home page: http://www.python.org/~guido/) [Tim] > Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under > Windows, but darned hard to see why that would matter. Can anyone else try > this under Solaris 2.6? May have something to do with the specific script > you're running, Greg; e.g., does it happen if the script file contains just > > print "Hi!" > > ? > > > -----Original Message----- > > From: python-bugs-list-admin@python.org > > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > > Sent: Tuesday, June 13, 2000 11:30 AM > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > > > > Full_Name: Greg Kochanski > > Version: yesterday's CVS > > OS: Solaris 2.6 > > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > > > > If you type ctrl-f5 to run a script twice in sucession, > > IDLE will incorrectly pop up a window saying > > "Not Saved. Please Save First." > > > > If you save (even though you haven't changed anything, > > and even though there are no asterisks around the window > > title), then ctrl-f5 will work again. > > > > This *doesn't* happen if you run the script twice in > > succession from the menu. > > > > > > > > _______________________________________________ > > Python-bugs-list maillist - Python-bugs-list@python.org > > http://www.python.org/mailman/listinfo/python-bugs-list > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From gpk@bell-labs.com Tue Jun 20 22:25:37 2000 From: gpk@bell-labs.com (Greg Kochanski) Date: Tue, 20 Jun 2000 17:25:37 -0400 Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) References: <000a01bfd54f$c0fb71a0$582d153f@tim> <200006202142.QAA01711@cj20424-a.reston1.va.home.com> Message-ID: <394FE151.C21AA502@bell-labs.com> Guido van Rossum wrote: > > I think I understand this. It's happened to me too. Pressing ^F5 > changes the focus to the PyShell window. Pressing ^F5 again then > indeed complains about that window being unsaved. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Ah. Sure enough. Perhaps the best thing to do is just to have the little error message explain which window is unsaved. Include the title of the unsaved window in the error box, maybe. I'd be happy to send a patch, but the paperwork would be terrible... From gpk@bell-labs.com Tue Jun 20 22:26:00 2000 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Tue, 20 Jun 2000 17:26:00 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <20000620212600.78D131CDBD@dinsdale.python.org> Guido van Rossum wrote: > > I think I understand this. It's happened to me too. Pressing ^F5 > changes the focus to the PyShell window. Pressing ^F5 again then > indeed complains about that window being unsaved. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Ah. Sure enough. Perhaps the best thing to do is just to have the little error message explain which window is unsaved. Include the title of the unsaved window in the error box, maybe. I'd be happy to send a patch, but the paperwork would be terrible... From guido@python.org Tue Jun 20 23:08:40 2000 From: guido@python.org (guido@python.org) Date: Tue, 20 Jun 2000 18:08:40 -0400 (EDT) Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <20000620220840.AFDAB1CCFA@dinsdale.python.org> > > I think I understand this. It's happened to me too. Pressing ^F5 > > changes the focus to the PyShell window. Pressing ^F5 again then > > indeed complains about that window being unsaved. > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > Ah. Sure enough. Perhaps the best thing to do > is just to have the little error message explain > which window is unsaved. Include the title > of the unsaved window in the error box, maybe. > > I'd be happy to send a patch, but the paperwork > would be terrible... No need for paperwork, just the disclaimer text. But I think the better patch would be to make PyShell a special case and make it rerun the last window that had the focus. --Guido van Rossum (home page: http://www.python.org/~guido/) From tong@aristotech.com Tue Jun 20 23:38:42 2000 From: tong@aristotech.com (tong@aristotech.com) Date: Tue, 20 Jun 2000 18:38:42 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) Message-ID: <20000620223842.707C31CFA7@dinsdale.python.org> Full_Name: Siu-Tong Hui Version: 1.5 OS: win NT Submission from: node-d8e9472.powerinter.net (216.233.71.2) We just moved to msvc6.0 and since then, some of our developers (including myself)will crash on following every time we run from msvc debugger: c:\vsvc98\crt\src\sbheap.c // test if previous entry was free with an index change or allocated if (!((sizePrev & 1) == 0 && indPrev == indEntry)) { // connect pEntry entry to indEntry // add entry to the start of the bucket list pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - sizeof(int)); pEntry->pEntryNext = pHead->pEntryNext; pEntry->pEntryPrev = pHead; pHead->pEntryNext = pEntry; pEntry->pEntryNext->pEntryPrev = pEntry; I'm using NT4.0 service pack 6 but developers who use service pack4 and pack5 also encouter this problem. We use python/tk. From mhammond@skippinet.com.au Wed Jun 21 00:57:40 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 09:57:40 +1000 Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) In-Reply-To: <20000620223842.707C31CFA7@dinsdale.python.org> Message-ID: It appears you have simply quoted the code from the MSVC runtime library. Can you give us some details about the script that is running? Does it use any extension modules? You should also be able to provide the complete stack trace when the program crashes, as shown in the MSVC debugger "Call Stack" window. If you can provide this, we will be able to look into it further. However, Python is used successfully in many many projects. The most likely candidate is your own C code, if any exists in the project. If not, the next most likely candidate is mixing the CRT library versions - you mention MSVCRTD.DLL. You must ensure that _all_ code loaded, including Python itself, is using this debug DLL. This generally means you need to be running with the "_d" versions of the Python binaries, and with all your code compiled with "/MDd". Carefully check the MSVC "Output" window - there should be exactly one reference to "msvcrt.dll" _or_ exactly one reference to "msvcrtd.dll" - if references to both exist, or the same DLL name from different directories has been loaded twice, that is your problem. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > tong@aristotech.com > Sent: Wednesday, 21 June 2000 8:39 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe > (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) > > > Full_Name: Siu-Tong Hui > Version: 1.5 > OS: win NT > Submission from: node-d8e9472.powerinter.net (216.233.71.2) > > > We just moved to msvc6.0 and since then, some of our developers > (including > myself)will crash on following every time we run from msvc debugger: > > c:\vsvc98\crt\src\sbheap.c > // test if previous entry was free with an index change or allocated > if (!((sizePrev & 1) == 0 && indPrev == indEntry)) > { > // connect pEntry entry to indEntry > // add entry to the start of the bucket list > pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - > sizeof(int)); > pEntry->pEntryNext = pHead->pEntryNext; > pEntry->pEntryPrev = pHead; > pHead->pEntryNext = pEntry; > pEntry->pEntryNext->pEntryPrev = pEntry; > > I'm using NT4.0 service pack 6 but developers who use service > pack4 and pack5 > also encouter this problem. > > We use python/tk. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Wed Jun 21 00:58:40 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Tue, 20 Jun 2000 19:58:40 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) Message-ID: <20000620235840.EDFCC1CE49@dinsdale.python.org> It appears you have simply quoted the code from the MSVC runtime library. Can you give us some details about the script that is running? Does it use any extension modules? You should also be able to provide the complete stack trace when the program crashes, as shown in the MSVC debugger "Call Stack" window. If you can provide this, we will be able to look into it further. However, Python is used successfully in many many projects. The most likely candidate is your own C code, if any exists in the project. If not, the next most likely candidate is mixing the CRT library versions - you mention MSVCRTD.DLL. You must ensure that _all_ code loaded, including Python itself, is using this debug DLL. This generally means you need to be running with the "_d" versions of the Python binaries, and with all your code compiled with "/MDd". Carefully check the MSVC "Output" window - there should be exactly one reference to "msvcrt.dll" _or_ exactly one reference to "msvcrtd.dll" - if references to both exist, or the same DLL name from different directories has been loaded twice, that is your problem. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > tong@aristotech.com > Sent: Wednesday, 21 June 2000 8:39 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe > (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) > > > Full_Name: Siu-Tong Hui > Version: 1.5 > OS: win NT > Submission from: node-d8e9472.powerinter.net (216.233.71.2) > > > We just moved to msvc6.0 and since then, some of our developers > (including > myself)will crash on following every time we run from msvc debugger: > > c:\vsvc98\crt\src\sbheap.c > // test if previous entry was free with an index change or allocated > if (!((sizePrev & 1) == 0 && indPrev == indEntry)) > { > // connect pEntry entry to indEntry > // add entry to the start of the bucket list > pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - > sizeof(int)); > pEntry->pEntryNext = pHead->pEntryNext; > pEntry->pEntryPrev = pHead; > pHead->pEntryNext = pEntry; > pEntry->pEntryNext->pEntryPrev = pEntry; > > I'm using NT4.0 service pack 6 but developers who use service > pack4 and pack5 > also encouter this problem. > > We use python/tk. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From r32813@email.sps.mot.com Wed Jun 21 17:38:15 2000 From: r32813@email.sps.mot.com (r32813@email.sps.mot.com) Date: Wed, 21 Jun 2000 12:38:15 -0400 (EDT) Subject: [Python-bugs-list] select module: Bug in select.select() (PR#365) Message-ID: <20000621163815.DE49C1CED2@dinsdale.python.org> Full_Name: Wah Meng Wong Version: 1.5.2 OS: AIX 4.3.1 Submission from: (NULL) (202.135.119.100) The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. From guido@python.org Wed Jun 21 22:10:09 2000 From: guido@python.org (guido@python.org) Date: Wed, 21 Jun 2000 17:10:09 -0400 (EDT) Subject: [Python-bugs-list] select module: Bug in select.select() (PR#365) Message-ID: <20000621211009.B96411CE71@dinsdale.python.org> > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Jun 21 22:10:09 2000 From: guido@python.org (guido@python.org) Date: Wed, 21 Jun 2000 17:10:09 -0400 (EDT) Subject: [Python-bugs-list] select module: Bug in select.select() (PR#365) Message-ID: <20000621211009.B96411CE71@dinsdale.python.org> > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) From r32813@email.sps.mot.com Fri Jun 23 03:03:44 2000 From: r32813@email.sps.mot.com (r32813@email.sps.mot.com) Date: Thu, 22 Jun 2000 22:03:44 -0400 (EDT) Subject: [Python-bugs-list] select module: Bug in select.select() (PR#365) Message-ID: <20000623020344.685221CD36@dinsdale.python.org> This is a multi-part message in MIME format. --------------F9E74BCE6963FE221E423528 Content-Type: multipart/alternative; boundary="------------FF8E270086909CA1DBDDA697" --------------FF8E270086909CA1DBDDA697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido, Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. $ dbx -I ./Modules ./python core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2) 235 PyObject *tout = Py_None; We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. Thanks for all your help. Regards, Wah Meng Guido van Rossum wrote: > > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > > this command was run:- > > > > select.select(waitList, [], [], timeWait) > > > > This command worked fine in Python 1.5.1 build and also fine on Python > > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > > 2 AIX machines that we have. > > Could you give us some more information? You're indicating that it's > platform specific; we don't have an AIX box. I'm guessing it's not > obvious that our code is wrong, but it may violate some guidelines > given by AIX manuals. If we ever want to fix this, we'll need to > interact with you. the first thing we need is a decent stack trace; > we'll take it from there. > > If you could investigate this on your own and come up with a fix, that > would probably the best solution... > > --Guido van Rossum (home page: http://www.python.org/~guido/) --------------FF8E270086909CA1DBDDA697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido,

Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4.

$ dbx -I ./Modules ./python core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2)
  235           PyObject *tout = Py_None;

We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem.

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

>  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when
>  this command was run:-
>
>        select.select(waitList, [], [], timeWait)
>
>  This command worked fine in Python 1.5.1 build and also fine on Python
>  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
>  2 AIX machines that we have.

Could you give us some more information?  You're indicating that it's
platform specific; we don't have an AIX box.  I'm guessing it's not
obvious that our code is wrong, but it may violate some guidelines
given by AIX manuals.  If we ever want to fix this, we'll need to
interact with you.  the first thing we need is a decent stack trace;
we'll take it from there.

If you could investigate this on your own and come up with a fix, that
would probably the best solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)

--------------FF8E270086909CA1DBDDA697-- --------------F9E74BCE6963FE221E423528 Content-Type: application/x-unknown-content-type-Python.File; name="test_thread_select.py" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test_thread_select.py" IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0 IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0 Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1 dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu ZycNCg0K --------------F9E74BCE6963FE221E423528-- From rob.hathaway@freeuk.com Fri Jun 23 11:31:52 2000 From: rob.hathaway@freeuk.com (rob.hathaway@freeuk.com) Date: Fri, 23 Jun 2000 06:31:52 -0400 (EDT) Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility (PR#366) Message-ID: <20000623103152.841D81CD46@dinsdale.python.org> Full_Name: Rob Hathaway Version: 1.6 OS: windows Submission from: sot-mod08.interalpha.net (195.26.225.8) All, I recently loaded the latest (1.6) version of Python onto my PC (running win95). I then loaded wxPython on top and attempted to run the demo from the command line (python demo.py) while in the wxPython demo directory. The following error message was issued: Fatal Python Error: PyThreadStateGet: No Current Thread. I then reloaded 1.5.2 and wxPython and the demo runs fine. I then loaded 1.6 onto a win98 and win2k OS and attempted to run the wxPython demo again always with the same result. From rob.hathaway@freeuk.com Fri Jun 23 11:32:24 2000 From: rob.hathaway@freeuk.com (rob.hathaway@freeuk.com) Date: Fri, 23 Jun 2000 06:32:24 -0400 (EDT) Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility (PR#367) Message-ID: <20000623103224.3B91E1CF00@dinsdale.python.org> Full_Name: Rob Hathaway Version: 1.6 OS: windows Submission from: sot-mod08.interalpha.net (195.26.225.8) All, I recently loaded the latest (1.6) version of Python onto my PC (running win95). I then loaded wxPython on top and attempted to run the demo from the command line (python demo.py) while in the wxPython demo directory. The following error message was issued: Fatal Python Error: PyThreadStateGet: No Current Thread. I then reloaded 1.5.2 and wxPython and the demo runs fine. I then loaded 1.6 onto a win98 and win2k OS and attempted to run the wxPython demo again always with the same result. Is this a known bug and is there a remedy to the problem (apart from not using 1.6 yet !!!) many thanks rob From mhammond@skippinet.com.au Fri Jun 23 14:31:57 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 23 Jun 2000 23:31:57 +1000 Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility (PR#366) In-Reply-To: <20000623103152.841D81CD46@dinsdale.python.org> Message-ID: Im afraid this is simply a symptom of a Python extension built for Python 1.5 being loaded with 1.6. You have no choice other than to wait for a Python 1.6 specific version of wxPython. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > rob.hathaway@freeuk.com > Sent: Friday, 23 June 2000 8:32 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility > (PR#366) > > > Full_Name: Rob Hathaway > Version: 1.6 > OS: windows > Submission from: sot-mod08.interalpha.net (195.26.225.8) > > > All, > I recently loaded the latest (1.6) version of Python onto my > PC (running > win95). I then loaded wxPython on top and attempted to run the > demo from the > command line (python demo.py) while in the wxPython demo directory. The > following error message was issued: Fatal Python Error: > PyThreadStateGet: No > Current Thread. > I then reloaded 1.5.2 and wxPython and the demo runs fine. I > then loaded 1.6 > onto a win98 and win2k OS and attempted to run the wxPython demo > again always > with the same result. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Fri Jun 23 14:33:27 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Fri, 23 Jun 2000 09:33:27 -0400 (EDT) Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility (PR#366) Message-ID: <20000623133327.0333E1CEE4@dinsdale.python.org> Im afraid this is simply a symptom of a Python extension built for Python 1.5 being loaded with 1.6. You have no choice other than to wait for a Python 1.6 specific version of wxPython. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > rob.hathaway@freeuk.com > Sent: Friday, 23 June 2000 8:32 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility > (PR#366) > > > Full_Name: Rob Hathaway > Version: 1.6 > OS: windows > Submission from: sot-mod08.interalpha.net (195.26.225.8) > > > All, > I recently loaded the latest (1.6) version of Python onto my > PC (running > win95). I then loaded wxPython on top and attempted to run the > demo from the > command line (python demo.py) while in the wxPython demo directory. The > following error message was issued: Fatal Python Error: > PyThreadStateGet: No > Current Thread. > I then reloaded 1.5.2 and wxPython and the demo runs fine. I > then loaded 1.6 > onto a win98 and win2k OS and attempted to run the wxPython demo > again always > with the same result. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From guido@python.org Fri Jun 23 16:02:52 2000 From: guido@python.org (guido@python.org) Date: Fri, 23 Jun 2000 11:02:52 -0400 (EDT) Subject: [Python-bugs-list] select module: Bug in select.select() (PR#365) Message-ID: <20000623150252.7C6FE1CD61@dinsdale.python.org> > Below is the dbx information from the coredump. This only occurs when the > select.select() function is used within a thread. This same error occurs on > both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not > occur on AIX 4.1.4. > > $ dbx -I ./Modules ./python core > Type 'help' for help. > reading symbolic information ... > [using memory image in core] > > Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" > ($t2) > 235 PyObject *tout = Py_None; Thanks. Could you do this again and also type the "bt" (backtrace) command? That would perhaps be more helpful. We can't reproduce this here since we don't have access to AIX! (Even if we ha,d it would be low priority :-( ). --Guido van Rossum (home page: http://www.python.org/~guido/) From rozen@rgv.hp.com Fri Jun 23 20:31:21 2000 From: rozen@rgv.hp.com (rozen@rgv.hp.com) Date: Fri, 23 Jun 2000 15:31:21 -0400 (EDT) Subject: [Python-bugs-list] Tkinter: widget.bind('sequence') incorrect (PR#368) Message-ID: <20000623193121.067631CD4D@dinsdale.python.org> Full_Name: Don Rozenberg Version: 1.5.2 OS: Linux Submission from: palwebproxy2.core.hp.com (156.153.255.130) With Tcl/Tk, bind tag sequence returns the string which is the command. With Python, widget.bind('sequence') seems to return a reference to the command not the command. The following reproduces the problem on my machine. Try running the file and observe the print output. Pretty strange. #! /usr/bin/env python from Tkinter import * root = Tk() def init(): pass def greeting(str): import Dialog Dialog.Dialog(title="greetings", text=str, bitmap="",default=0,strings=("cont",)) class New_Toplevel_1: def __init__(self, master=None): self.ent17 = Entry (master) self.ent17.place(in_=master,x=45,y=50) self.ent17.configure(background="plum") self.ent17.configure(font="helvetica 14 bold") self.ent17.configure(foreground="black") self.ent17.configure(insertbackground="black") self.ent17.configure(selectbackground="black") self.ent17.configure(selectforeground="ivory") self.hello = StringVar() self.ent17.configure(textvariable=self.hello) self.ent17.configure(width="35") self.ent17.bind('q',lambda e: greeting('q')) x = self.ent17.bind() print 'x =', x x = self.ent17.bind('q') print 'x =', x # I expected x to be "lambda e: greeting('q')" # I actually got the following # x = set _tkinter_break [135926416 %# %b %f %h %k %s %t %w %x %y %A %E %K %N %W %T %X %Y] # if {"$_tkinter_break" == "break"} break def vp_start_gui(): global w root.title('New_Toplevel_1') root.geometry('500x200+216+41') root.configure(bg='wheat') w = New_Toplevel_1 (root) root.mainloop() if __name__ == '__main__': vp_start_gui() From guido@python.org Fri Jun 23 20:45:41 2000 From: guido@python.org (guido@python.org) Date: Fri, 23 Jun 2000 15:45:41 -0400 (EDT) Subject: [Python-bugs-list] Tkinter: widget.bind('sequence') incorrect (PR#368) Message-ID: <20000623194541.D3CAA1CD49@dinsdale.python.org> > With Tcl/Tk, bind tag sequence returns the string which is the command. > With Python, widget.bind('sequence') seems to return a reference to the > command not the command. > > The following reproduces the problem on my machine. Try running the file > and observe the print output. Pretty strange. The string returned is in fact the command bound -- this is a wrapper function. Since (typically) the argument to bind is a Python function, not a Tcl command, a wrapper is used to pass the event data to the Python function. This doesn't qualify as a bug -- it's just different. --Guido van Rossum (home page: http://www.python.org/~guido/) From redumas@eos.ncsu.edu Sat Jun 24 19:35:17 2000 From: redumas@eos.ncsu.edu (redumas@eos.ncsu.edu) Date: Sat, 24 Jun 2000 14:35:17 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Python and ASP (PR#369) Message-ID: <20000624183517.0E9DB1CD27@dinsdale.python.org> Full_Name: Dumas Version: Py1.5.2 OS: Windows 2000 Advanced Server Submission from: (NULL) (208.41.247.187) I am doing some scripting with Python and MS ASP3.0. My problem lies with using the Session object as an lvalue. Using the Session object as an rvalue works perfect. Ex - somestring = Session("info") #this works perfect #however, Session("info") = somestring #unknown error Your help would be greatly appreciated! Thanks, Dumas From mhammond@skippinet.com.au Sat Jun 24 23:54:28 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 25 Jun 2000 08:54:28 +1000 Subject: [Python-bugs-list] PRIVATE: Python and ASP (PR#369) In-Reply-To: <20000624183517.0E9DB1CD27@dinsdale.python.org> Message-ID: You can set a session variable under ASP using the syntax: Session.SetValue('Key', 4) For example... Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > redumas@eos.ncsu.edu > Sent: Sunday, 25 June 2000 4:35 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PRIVATE: Python and ASP (PR#369) > > > Full_Name: Dumas > Version: Py1.5.2 > OS: Windows 2000 Advanced Server > Submission from: (NULL) (208.41.247.187) > > > I am doing some scripting with Python and MS ASP3.0. My problem > lies with using > the Session object as an lvalue. Using the Session object as an > rvalue works > perfect. > > Ex - > somestring = Session("info") #this works perfect > > #however, > > Session("info") = somestring #unknown error > > Your help would be greatly appreciated! > > Thanks, > Dumas > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Sat Jun 24 23:57:32 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Sat, 24 Jun 2000 18:57:32 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Python and ASP (PR#369) Message-ID: <20000624225732.0D5211CD7E@dinsdale.python.org> You can set a session variable under ASP using the syntax: Session.SetValue('Key', 4) For example... Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > redumas@eos.ncsu.edu > Sent: Sunday, 25 June 2000 4:35 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PRIVATE: Python and ASP (PR#369) > > > Full_Name: Dumas > Version: Py1.5.2 > OS: Windows 2000 Advanced Server > Submission from: (NULL) (208.41.247.187) > > > I am doing some scripting with Python and MS ASP3.0. My problem > lies with using > the Session object as an lvalue. Using the Session object as an > rvalue works > perfect. > > Ex - > somestring = Session("info") #this works perfect > > #however, > > Session("info") = somestring #unknown error > > Your help would be greatly appreciated! > > Thanks, > Dumas > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From wzdd@sesgroup.net Mon Jun 26 08:34:58 2000 From: wzdd@sesgroup.net (wzdd@sesgroup.net) Date: Mon, 26 Jun 2000 03:34:58 -0400 (EDT) Subject: [Python-bugs-list] int() broken? (PR#370) Message-ID: <20000626073458.8F2F91CD72@dinsdale.python.org> Full_Name: Nicholas FitzRoy-Dale Version: 1.5.2 OS: Linux (Debian, Red Hat) Submission from: cpe-24-192-0-130.vic.bigpond.net.au (24.192.0.130) The following typescript illustrates the problem. I understand int() truncates towards zero - but can't see why it would round down by a whole int value! The same behaviour is apparent on a Red Hat 6.2 system, where Python was built with egcs. ~$ python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> test=591.92 >>> test*100 59192.0 >>> int (test*100) 59191 >>> ... and yet: >>> int (test*100+0.1) 59192 >>> From mal@lemburg.com Mon Jun 26 09:56:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 26 Jun 2000 10:56:27 +0200 Subject: [Python-bugs-list] int() broken? (PR#370) References: <20000626073458.8F2F91CD72@dinsdale.python.org> Message-ID: <39571ABB.DDADE3B6@lemburg.com> wzdd@sesgroup.net wrote: > > Full_Name: Nicholas FitzRoy-Dale > Version: 1.5.2 > OS: Linux (Debian, Red Hat) > Submission from: cpe-24-192-0-130.vic.bigpond.net.au (24.192.0.130) > > The following typescript illustrates the problem. I understand int() truncates > towards zero - but can't see why it would round down by a whole int value! > > The same behaviour is apparent on a Red Hat 6.2 system, where Python was built > with egcs. > > ~$ python > Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian > GNU/Linux)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> test=591.92 > >>> test*100 > 59192.0 > >>> int (test*100) > 59191 > >>> > > ... and yet: > >>> int (test*100+0.1) > 59192 > >>> While waiting for Tim Peters to explain the details, here's the obvious part of the answer: >>> test = 591.92 >>> '%.17f' % test '591.91999999999995907' >>> '%.17f' % (test*100) '59191.99999999999272404' >>> '%.17f' % (test*100+0.1) '59192.09999999999126885' -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jun 26 09:58:16 2000 From: mal@lemburg.com (mal@lemburg.com) Date: Mon, 26 Jun 2000 04:58:16 -0400 (EDT) Subject: [Python-bugs-list] int() broken? (PR#370) Message-ID: <20000626085816.676D11CD9C@dinsdale.python.org> wzdd@sesgroup.net wrote: > > Full_Name: Nicholas FitzRoy-Dale > Version: 1.5.2 > OS: Linux (Debian, Red Hat) > Submission from: cpe-24-192-0-130.vic.bigpond.net.au (24.192.0.130) > > The following typescript illustrates the problem. I understand int() truncates > towards zero - but can't see why it would round down by a whole int value! > > The same behaviour is apparent on a Red Hat 6.2 system, where Python was built > with egcs. > > ~$ python > Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian > GNU/Linux)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> test=591.92 > >>> test*100 > 59192.0 > >>> int (test*100) > 59191 > >>> > > ... and yet: > >>> int (test*100+0.1) > 59192 > >>> While waiting for Tim Peters to explain the details, here's the obvious part of the answer: >>> test = 591.92 >>> '%.17f' % test '591.91999999999995907' >>> '%.17f' % (test*100) '59191.99999999999272404' >>> '%.17f' % (test*100+0.1) '59192.09999999999126885' -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gottfried.ganssauge@dynix.de Tue Jun 27 14:08:23 2000 From: gottfried.ganssauge@dynix.de (gottfried.ganssauge@dynix.de) Date: Tue, 27 Jun 2000 09:08:23 -0400 (EDT) Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) Message-ID: <20000627130823.3A0EB1CD3E@dinsdale.python.org> Full_Name: Gottfried Ganßauge Version: 1.5.2 OS: Windows 2000 Submission from: joshua2go.dynix.de (195.21.130.43) I'm using PyWin32 build 132, but the problem occurs with build 129 as well. Every time I hit one of the dead keys on my keyboard (`, ^) PythonWin crashes. I traced the error back to the routine ui_translate_vk() in win32uimodule.cpp. The call to ToAsciiEx() with a dead key's scan code returns -1 and in the following call to PyString_FromStringAndSize() this eventually leads to the crash. In my opininion the reason for that lies before the call to this routine. pywin hooks WM_KEYDOWN in several places and doesn't check for dead keys but tries to translate the scan code to an ASCII character. With dead keys this obviously must fail. Windows itself already does the correct translation as described in the Platform SDK article about Dead-Character Messages: Some non-English keyboards contain character keys that are not expected to produce characters by themselves. Instead, they are used to add a diacritic to the character produced by the subsequent keystroke. These keys are called dead keys. The circumflex key on a German keyboard is an example of a dead key. To enter the character consisting of an "o" with a circumflex, a German user would type the circumflex key followed by the "o" key. The window with the keyboard focus would receive the following sequence of messages: WM_KEYDOWN WM_DEADCHAR WM_KEYUP WM_KEYDOWN WM_CHAR WM_KEYUP Consequently pywin should ignore WM_KEYDOWN messages completely if they are produced by a dead key. I tried to implement that using the current win32api implementation, but unfortunately the necessary API-Function to find out if a key is a dead key are not provided in the current implementation; namely the MapVirtualKey(Ex) function. Cheers, and keep up the good work Gottfried From mhammond@skippinet.com.au Wed Jun 28 01:33:26 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 10:33:26 +1000 Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) In-Reply-To: <20000627130823.3A0EB1CD3E@dinsdale.python.org> Message-ID: Thanks for reporting this. Ill look into it. In general, this bug mechanism is for Python itself, and not the Python for Win32 extensions. Its probably best to simply mail future bugs in the Win32 stuff directly to me. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > gottfried.ganssauge@dynix.de > Sent: Tuesday, 27 June 2000 11:08 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) > > > Full_Name: Gottfried Ganßauge > Version: 1.5.2 > OS: Windows 2000 > Submission from: joshua2go.dynix.de (195.21.130.43) > > > I'm using PyWin32 build 132, but the problem occurs with build > 129 as well. > > Every time I hit one of the dead keys on my keyboard (`, ^) > PythonWin crashes. > I traced the error back to the routine ui_translate_vk() in > win32uimodule.cpp. > The call to ToAsciiEx() with a dead key's scan code returns -1 and in the > following call to PyString_FromStringAndSize() this eventually > leads to the > crash. > In my opininion the reason for that lies before the call to this routine. > pywin hooks WM_KEYDOWN in several places and doesn't check for > dead keys but > tries to translate the scan code to an ASCII character. > With dead keys this obviously must fail. > Windows itself already does the correct translation as described in the > Platform SDK article about Dead-Character Messages: > > Some non-English keyboards contain character keys that are not > expected to > produce characters by themselves. Instead, they are used to add > a diacritic to > the character produced by the subsequent keystroke. These keys > are called dead > keys. The circumflex key on a German keyboard is an example of a > dead key. To > enter the character consisting of an "o" with a circumflex, a > German user would > type the circumflex key followed by the "o" key. The window with > the keyboard > focus would receive the following sequence of messages: > > WM_KEYDOWN > WM_DEADCHAR > WM_KEYUP > WM_KEYDOWN > WM_CHAR > WM_KEYUP > > > Consequently pywin should ignore WM_KEYDOWN messages completely > if they are > produced by a dead key. > I tried to implement that using the current win32api implementation, but > unfortunately the necessary API-Function to find out if a key is > a dead key are > not provided in the current implementation; namely the MapVirtualKey(Ex) > function. > > Cheers, and keep up the good work > > Gottfried > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From mhammond@skippinet.com.au Wed Jun 28 01:35:06 2000 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Tue, 27 Jun 2000 20:35:06 -0400 (EDT) Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) Message-ID: <20000628003506.2EBD01CEE8@dinsdale.python.org> Thanks for reporting this. Ill look into it. In general, this bug mechanism is for Python itself, and not the Python for Win32 extensions. Its probably best to simply mail future bugs in the Win32 stuff directly to me. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > gottfried.ganssauge@dynix.de > Sent: Tuesday, 27 June 2000 11:08 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) > > > Full_Name: Gottfried Ganßauge > Version: 1.5.2 > OS: Windows 2000 > Submission from: joshua2go.dynix.de (195.21.130.43) > > > I'm using PyWin32 build 132, but the problem occurs with build > 129 as well. > > Every time I hit one of the dead keys on my keyboard (`, ^) > PythonWin crashes. > I traced the error back to the routine ui_translate_vk() in > win32uimodule.cpp. > The call to ToAsciiEx() with a dead key's scan code returns -1 and in the > following call to PyString_FromStringAndSize() this eventually > leads to the > crash. > In my opininion the reason for that lies before the call to this routine. > pywin hooks WM_KEYDOWN in several places and doesn't check for > dead keys but > tries to translate the scan code to an ASCII character. > With dead keys this obviously must fail. > Windows itself already does the correct translation as described in the > Platform SDK article about Dead-Character Messages: > > Some non-English keyboards contain character keys that are not > expected to > produce characters by themselves. Instead, they are used to add > a diacritic to > the character produced by the subsequent keystroke. These keys > are called dead > keys. The circumflex key on a German keyboard is an example of a > dead key. To > enter the character consisting of an "o" with a circumflex, a > German user would > type the circumflex key followed by the "o" key. The window with > the keyboard > focus would receive the following sequence of messages: > > WM_KEYDOWN > WM_DEADCHAR > WM_KEYUP > WM_KEYDOWN > WM_CHAR > WM_KEYUP > > > Consequently pywin should ignore WM_KEYDOWN messages completely > if they are > produced by a dead key. > I tried to implement that using the current win32api implementation, but > unfortunately the necessary API-Function to find out if a key is > a dead key are > not provided in the current implementation; namely the MapVirtualKey(Ex) > function. > > Cheers, and keep up the good work > > Gottfried > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > From tpeters@beopen.com Thu Jun 29 07:25:20 2000 From: tpeters@beopen.com (tpeters@beopen.com) Date: Thu, 29 Jun 2000 02:25:20 -0400 (EDT) Subject: [Python-bugs-list] Win32 os.listdir raises confusing errors (PR#374) Message-ID: <20000629062520.022F41CE3D@dinsdale.python.org> Full_Name: Tim Peters Version: 1.6a2 OS: Windows Submission from: waf-dc1b-135.rasserver.net (206.217.144.135) Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> From tpeters@beopen.com Thu Jun 29 07:32:01 2000 From: tpeters@beopen.com (tpeters@beopen.com) Date: Thu, 29 Jun 2000 02:32:01 -0400 (EDT) Subject: [Python-bugs-list] 'python -U' breaks eval/exec (PR#375) Message-ID: <20000629063201.EE2A71CD8D@dinsdale.python.org> Full_Name: Tim Peters Version: 1.6a2 OS: Win32 Submission from: waf-dc1b-135.rasserver.net (206.217.144.135) Moving this bug from the SourceForge Bug Manager, https://sourceforge.net/bugs/?func=detailbug&bug_id=107608&group_id=5470 Original Submission: Freshly built python: [mwh21@atrus build]$ PYTHONSTARTUP= ./python -U 'import site' failed; use -v for traceback Python 1.6a2 (#1, Jun 17 2000, 00:21:58) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> eval("1") Traceback (most recent call last): File "", line 1, in ? TypeError: eval() argument 1 must be string or code object (this is also why the import site fails). exec is also broken. [I believe this was originally sent in by Michael Hudson - tgp] Comment from Guido: eval and exec need to support Unicode objects. This may be hard, and since -U is mostly experimental, I've given it a low priority. From fstajano@uk.research.att.com Thu Jun 29 17:49:45 2000 From: fstajano@uk.research.att.com (fstajano@uk.research.att.com) Date: Thu, 29 Jun 2000 12:49:45 -0400 (EDT) Subject: [Python-bugs-list] Tk-based widgets misbehave with dead keys (PR#376) Message-ID: <20000629164945.D012B1D1CA@dinsdale.python.org> Full_Name: Frank Stajano Version: 1.6a2 OS: Windows 98 and 2000 Submission from: xadhoom.al.cl.cam.ac.uk (128.232.15.185) This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] From epx@conectiva.com Fri Jun 30 21:10:25 2000 From: epx@conectiva.com (epx@conectiva.com) Date: Fri, 30 Jun 2000 16:10:25 -0400 (EDT) Subject: [Python-bugs-list] pythonlib.a makes SIGSEGV with LD_PRELOAD variable (PR#378) Message-ID: <20000630201025.0F0241CD51@dinsdale.python.org> Full_Name: Elvis Pfützenreuter Version: 1.5.2 OS: Linux glibc 2.1.3 kernel 2.2.16 Submission from: presuntinho.conectiva.com.br (200.250.58.147) Modules/posixmodule,c, function convertenviron(), uses a dirty trick when parsing POSIX environment variables. All variables are formatted as = Example: KDEDIR=/usr Python changes '=' to '\0' for a moment while parsing, in the line *p = '\0' But, if LD_PRELOAD variable is present, it SIGSEGVs in this command. I guess this variable is in a mprotect()ed page for security reasons. The environment variable parser should strdup() the variables or change the parsing algorithm so it no longer writes directly the environment var. array. From guido@python.org Fri Jun 30 22:36:00 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:36:00 -0500 Subject: [Python-bugs-list] pythonlib.a makes SIGSEGV with LD_PRELOAD variable (PR#378) In-Reply-To: Your message of "Fri, 30 Jun 2000 16:10:25 -0400." <20000630201025.0F0241CD51@dinsdale.python.org> References: <20000630201025.0F0241CD51@dinsdale.python.org> Message-ID: <200006302136.QAA20716@cj20424-a.reston1.va.home.com> > Modules/posixmodule,c, function convertenviron(), uses a dirty trick when > parsing POSIX environment variables. All variables are formatted as > > = > Example: KDEDIR=/usr > > Python changes '=' to '\0' for a moment while parsing, in the line > > *p = '\0' > > But, if LD_PRELOAD variable is present, it SIGSEGVs in this command. I guess > this variable is in a mprotect()ed page for security reasons. The environment > variable parser should strdup() the variables or change the parsing algorithm so > it no longer writes directly the environment var. array. This has long been fixed in the CVS repository. Check out 1.6a2 or the new 2.0b1 that will be out tomorrow. --Guido van Rossum (home page: http://www.python.org/~guido/)