From lele@seldati.it Sat Oct 2 09:01:19 1999 From: lele@seldati.it (lele@seldati.it) Date: Sat, 2 Oct 1999 04:01:19 -0400 (EDT) Subject: [Python-bugs-list] Possible bug in Python 1.5.x (PR#91) Message-ID: <199910020801.EAA28183@python.org> --HA6n+H7tic Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hi all, I'm forwarding this because I didn't receive an ACK from GvR. I'd like to hear something on the matter; in the meantime I searched the bugs archive but didn't find anything fitting. Thanx a lot, bye, lele. --HA6n+H7tic Content-Type: message/rfc822 Content-Description: forwarded message Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <14321.21121.269781.745202@paci.nautilus> In-Reply-To: <19990927224546.A27570@joker.rhwd.owl.de> References: <55694952C05DD2119CFF0008C7A4518101277B@HO-NT-01> <14315.50701.493215.765326@paci.nautilus> <14317.413.460416.916258@paci.nautilus> <14318.24767.537657.23927@paci.nautilus> <19990927174718.A22553@joker.rhwd.owl.de> <14319.52307.661922.223595@paci.nautilus> <19990927224546.A27570@joker.rhwd.owl.de> X-Mailer: VM 6.73 under 20.4 "Emerald" XEmacs Lucid From: Lele Gaifax To: pyapache-devel@msg.com.mx Cc: Guido Van Rossum Subject: Possible bug in Python 1.5.x (was PyApache & apxs (or not)) Date: Wed, 29 Sep 1999 01:42:57 +0200 (CEST) >>>>> "AR" == Alexander Reelsen writes: AR> Sorry for mixing up this thread, but: Afaik not ;). So here we AR> go: (I hope I didn't forget anything) This is python 1.5.2, AR> Debian GNU/Linux 2.2 (aka potato) with glibc 2.1.2 PyApache is AR> 4.16. Hi, I think I isolated the problem! And I'm almost sure that it's on the Python side. I'm CCing this directly to Guido (hi again!). It's caused by Py_VerboseFlag+Py_NewInterpreter(). For example, trying Demo/pysrv/pysrv with PYTHONVERBOSE set causes a segfault. The reason is that with that flag on, the call to _PyImport_FindExtension in turn call PySys_WriteStderr(), then PySys_GetObject to lookup the "stderr" file in the sysdict... but interp->sysdict isn't initialized yet, it will be a few statement later in Py_NewInterpreter()! So, I think that either PySys_WriteStderr() do its own check on whether the syserr actually exist or the code in Py_NewInterpreter() must be changed (the order of init). Maybe I missed something obvious, but the pysrv demo seems to confirm the bug. Meanwhile, about Alexander's problem I would suggest to turn off the verbosity in the httpd.conf. Hope this help, bye & thanx. -- nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia. email: lele@seldati.it | -- Fortunato Depero, 1929. --HA6n+H7tic Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia. email: lele@seldati.it | -- Fortunato Depero, 1929. --HA6n+H7tic-- From mhammond@skippinet.com.au Mon Oct 4 08:21:21 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 4 Oct 1999 17:21:21 +1000 Subject: franzk@netal.com: [Python-bugs-list] Memory exception in python15.dll when calling IActi veScript::AddTypeLib (PR#76) In-Reply-To: <199909112112.RAA28681@eric.cnri.reston.va.us> Message-ID: <002a01bf0e39$0f4e07c0$0801a8c0@bobcat> Regarding bug ID 76, as detailed below. This can be moved to "resolved" with a note that it is fixed in win32all-127 and later (not yet out, but preparing for it now) Thanks, Mark. > > > Do you have any insights here? I'm not sure how to file this in the > bugs list... > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > ------- Forwarded Message > > Date: Sat, 11 Sep 1999 10:47:13 -0400 > From: franzk@netal.com > To: python-bugs-list@python.org > cc: bugs-py@python.org > Subject: [Python-bugs-list] Memory exception in python15.dll > when calling IActi > veScript::AddTypeLib (PR#76) > > Full_Name: Franz Krainer > Version: 1.5.2 > OS: NT > Submission from: tk142052.telekabel.at (195.34.142.52) > > > A memory exception happens in python15.dll when an ActiveX > Scripting Host > (Windows Scripting Host 2.0, for example) calls > IActiveScript::AddTypeLib to ad > d > a type library to the engine. > > Use the following WSH 2.0 Beta 2 code to reproduce the problem: > > - --------------------Start of > bugtest.ws---------------------------------- > > > > > - --------------------End of bugtest.ws------------------ > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > > ------- End of Forwarded Message > From shainan@hotmail.com Mon Oct 4 16:44:38 1999 From: shainan@hotmail.com (shainan@hotmail.com) Date: Mon, 4 Oct 1999 11:44:38 -0400 (EDT) Subject: [Python-bugs-list] Win32.exe installation (PR#92) Message-ID: <199910041544.LAA05491@python.org> Full_Name: Shainan Patel Version: 1.5 OS: Windows 98 Submission from: p1476c66a.us.kpmg.com (199.206.254.66) Hi, I am trying to install the ODBC module... For that the steps were to install python and then run win32.exe.. Python installed fine(version 1.5) but when i try to run win32.exe it says System could not find python1.4, install python 1.4 and run again. I think win32.exe is not recognising python1.5... Any suggestions... Thanks, Shainan From guido@CNRI.Reston.VA.US Mon Oct 4 16:58:43 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 4 Oct 1999 11:58:43 -0400 (EDT) Subject: [Python-bugs-list] Win32.exe installation (PR#92) Message-ID: <199910041558.LAA06039@python.org> > Full_Name: Shainan Patel > Version: 1.5 > OS: Windows 98 > Submission from: p1476c66a.us.kpmg.com (199.206.254.66) > > > Hi, > > I am trying to install the ODBC module... For that the steps were to install > python and then run win32.exe.. > > Python installed fine(version 1.5) but when i try to run win32.exe it says > System could not find python1.4, install python 1.4 and run again. > > I think win32.exe is not recognising python1.5... > > Any suggestions... > > Thanks, > Shainan You need help with the installation. Please don't send this in as a bug report. Please write help@python.org for help. --Guido van Rossum (home page: http://www.python.org/~guido/) From jmrober1@ingr.com Mon Oct 4 21:00:39 1999 From: jmrober1@ingr.com (jmrober1@ingr.com) Date: Mon, 4 Oct 1999 16:00:39 -0400 (EDT) Subject: [Python-bugs-list] normpath error (PR#93) Message-ID: <199910042000.QAA12550@python.org> Full_Name: Joe Robertson Version: 1.5.2 OS: Windows NT Submission from: ckpnt04.intergraph.com (63.75.137.2) File: posixpath.py and ntpath.py Method: normpath Problem: initial multiple slashes are not collapsed I traced to ntpath.py because I am using WindowsNT 4.0, but I believe that the same error will occur under POSIX. Using a path such as: d://data\testdlf/test.dlf for a test input I discovered that slashes were converted except for the first 2. So I ended up with: d://data/test/test.dlf Making this change to the ntpath.py file fixed this issue. os.sep is being added for each iteration of the loop. def normpath(path): """Normalize path, eliminating double slashes, etc.""" path = string.replace(path, "/", "\\") prefix, path = splitdrive(path) while path[:1] == os.sep: #prefix = prefix + os.sep path = path[1:] ## jmr 10/4/99 ## add the sep to the prefix only 1 time prefix = prefix + os.sep comps = string.splitfields(path, os.sep) i = 0 ---legal release--- 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. Joe Robertson jmrober1@ingr.com jmrobert@ro.com From guido@CNRI.Reston.VA.US Mon Oct 4 21:24:16 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 04 Oct 1999 16:24:16 -0400 Subject: [Python-bugs-list] normpath error (PR#93) In-Reply-To: Your message of "Mon, 04 Oct 1999 16:00:39 EDT." <199910042000.QAA12550@python.org> References: <199910042000.QAA12550@python.org> Message-ID: <199910042024.QAA19116@eric.cnri.reston.va.us> > File: posixpath.py and ntpath.py > Method: normpath > Problem: initial multiple slashes are not collapsed > > I traced to ntpath.py because I am using WindowsNT 4.0, > but I believe that the same error will occur under POSIX. > > Using a path such as: > d://data\testdlf/test.dlf > for a test input I discovered that slashes were converted > except for the first 2. > > So I ended up with: > d://data/test/test.dlf > > Making this change to the ntpath.py file fixed this issue. > os.sep is being added for each iteration of the loop. This is actually a feature. When there is no drive letter, Windows (as well as some Unix versions) has a different interpretation for a double leading (back)slash. Some experimentation with NT 4.0 learns that (at least on that system) if a drive letter is followed by a double backslash, the drive letter is ignored -- while a double backslash elsewhere in a filename is treated the same as a single. I can't say that I understand the wisdom of these rules, but they are standard NT, and I prefer not to try to "improve" upon it. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Oct 4 21:24:10 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 4 Oct 1999 16:24:10 -0400 (EDT) Subject: [Python-bugs-list] normpath error (PR#93) Message-ID: <199910042024.QAA13001@python.org> > File: posixpath.py and ntpath.py > Method: normpath > Problem: initial multiple slashes are not collapsed > > I traced to ntpath.py because I am using WindowsNT 4.0, > but I believe that the same error will occur under POSIX. > > Using a path such as: > d://data\testdlf/test.dlf > for a test input I discovered that slashes were converted > except for the first 2. > > So I ended up with: > d://data/test/test.dlf > > Making this change to the ntpath.py file fixed this issue. > os.sep is being added for each iteration of the loop. This is actually a feature. When there is no drive letter, Windows (as well as some Unix versions) has a different interpretation for a double leading (back)slash. Some experimentation with NT 4.0 learns that (at least on that system) if a drive letter is followed by a double backslash, the drive letter is ignored -- while a double backslash elsewhere in a filename is treated the same as a single. I can't say that I understand the wisdom of these rules, but they are standard NT, and I prefer not to try to "improve" upon it. --Guido van Rossum (home page: http://www.python.org/~guido/) From dcoffin@shore.net Mon Oct 4 21:35:05 1999 From: dcoffin@shore.net (dcoffin@shore.net) Date: Mon, 4 Oct 1999 16:35:05 -0400 (EDT) Subject: [Python-bugs-list] Problem with multi-dimensional arrays (PR#94) Message-ID: <199910042035.QAA13193@python.org> Full_Name: Dave Coffin Version: 1.5.2 OS: Linux Submission from: (NULL) (206.166.179.42) When I do an assignment of the form "array[i][j]=k", every element in column j gets set to k: Python 1.5.2 (#3, Sep 22 1999, 16:32:41) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> foo = [ [1] * 4 ] * 4 >>> foo [[1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1]] >>> foo[3] [1, 1, 1, 1] >>> foo[3][2] 1 >>> foo[3][2]=5 >>> foo [[1, 1, 5, 1], [1, 1, 5, 1], [1, 1, 5, 1], [1, 1, 5, 1]] >>> foo[1][2] 5 From guido@CNRI.Reston.VA.US Mon Oct 4 21:42:02 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 4 Oct 1999 16:42:02 -0400 (EDT) Subject: [Python-bugs-list] Problem with multi-dimensional arrays (PR#94) Message-ID: <199910042042.QAA13645@python.org> > When I do an assignment of the form "array[i][j]=k", every element in > column j gets set to k: > > Python 1.5.2 (#3, Sep 22 1999, 16:32:41) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> foo = [ [1] * 4 ] * 4 > >>> foo > [[1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1]] > >>> foo[3] > [1, 1, 1, 1] > >>> foo[3][2] > 1 > >>> foo[3][2]=5 > >>> foo > [[1, 1, 5, 1], [1, 1, 5, 1], [1, 1, 5, 1], [1, 1, 5, 1]] > >>> foo[1][2] > 5 This is not a bug; the expression [ [1]*4 ] * 4 yields a list with four references to the same object (each of which in turn is a list of four references to the number 1). A solution in this case would be: >>> foo = [] >>> for i in range(4): ... foo.append([1]*4) ... >>> But it is important to have a thourough understanding of this issue before getting further entangled. Ask the Python newsgroup comp.lang.python or write to help@python.org for more help on this issue. It is also dealt with in the book Learning PYthon. --Guido van Rossum (home page: http://www.python.org/~guido/) From jmrober1@ingr.com Mon Oct 4 22:05:45 1999 From: jmrober1@ingr.com (jmrober1@ingr.com) Date: Mon, 4 Oct 1999 17:05:45 -0400 (EDT) Subject: [Python-bugs-list] normpath error (PR#93) Message-ID: <199910042105.RAA14235@python.org> Hmmm, I see your reasoning. But what if (and I have not run this yet) the test path is d:\\\data/test\\test.dlf? By using this function I am saying I cannot gaurantee what the input will look like. Looking at that loop, i would expect, d:\\\data\test\test.dlf since each pass adds a os.sep to the drive part after the split a drive letter + ':' IS a detectable situation and could be handled and would not upset a UNC type path of just plain \\data\test\test.dlf Thanks, Joe Robertson 256-730-8216 jmrober1@ingr.com jmrobert@ro.com http://ro.com/~jmrobert/ "Does my reputation precede me...or was I too fast for it?" Captain Zap Brannagan, Futurama > -----Original Message----- > From: Guido van Rossum [SMTP:guido@CNRI.Reston.VA.US] > Sent: Monday, October 04, 1999 3:24 PM > To: Robertson, Joseph M > Cc: python-bugs-list@python.org; bugs-py@python.org > Subject: Re: [Python-bugs-list] normpath error (PR#93) > > > File: posixpath.py and ntpath.py > > Method: normpath > > Problem: initial multiple slashes are not collapsed > > > > I traced to ntpath.py because I am using WindowsNT 4.0, > > but I believe that the same error will occur under POSIX. > > > > Using a path such as: > > d://data\testdlf/test.dlf > > for a test input I discovered that slashes were converted > > except for the first 2. > > > > So I ended up with: > > d://data/test/test.dlf > > > > Making this change to the ntpath.py file fixed this issue. > > os.sep is being added for each iteration of the loop. > > This is actually a feature. When there is no drive letter, Windows > (as well as some Unix versions) has a different interpretation for a > double leading (back)slash. > > Some experimentation with NT 4.0 learns that (at least on that system) > if a drive letter is followed by a double backslash, the drive letter > is ignored -- while a double backslash elsewhere in a filename is > treated the same as a single. > > I can't say that I understand the wisdom of these rules, but they are > standard NT, and I prefer not to try to "improve" upon it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) From jmrober1@ingr.com Mon Oct 4 22:05:41 1999 From: jmrober1@ingr.com (Robertson, Joseph M) Date: Mon, 4 Oct 1999 16:05:41 -0500 Subject: [Python-bugs-list] normpath error (PR#93) Message-ID: Hmmm, I see your reasoning. But what if (and I have not run this yet) the test path is d:\\\data/test\\test.dlf? By using this function I am saying I cannot gaurantee what the input will look like. Looking at that loop, i would expect, d:\\\data\test\test.dlf since each pass adds a os.sep to the drive part after the split a drive letter + ':' IS a detectable situation and could be handled and would not upset a UNC type path of just plain \\data\test\test.dlf Thanks, Joe Robertson 256-730-8216 jmrober1@ingr.com jmrobert@ro.com http://ro.com/~jmrobert/ "Does my reputation precede me...or was I too fast for it?" Captain Zap Brannagan, Futurama > -----Original Message----- > From: Guido van Rossum [SMTP:guido@CNRI.Reston.VA.US] > Sent: Monday, October 04, 1999 3:24 PM > To: Robertson, Joseph M > Cc: python-bugs-list@python.org; bugs-py@python.org > Subject: Re: [Python-bugs-list] normpath error (PR#93) > > > File: posixpath.py and ntpath.py > > Method: normpath > > Problem: initial multiple slashes are not collapsed > > > > I traced to ntpath.py because I am using WindowsNT 4.0, > > but I believe that the same error will occur under POSIX. > > > > Using a path such as: > > d://data\testdlf/test.dlf > > for a test input I discovered that slashes were converted > > except for the first 2. > > > > So I ended up with: > > d://data/test/test.dlf > > > > Making this change to the ntpath.py file fixed this issue. > > os.sep is being added for each iteration of the loop. > > This is actually a feature. When there is no drive letter, Windows > (as well as some Unix versions) has a different interpretation for a > double leading (back)slash. > > Some experimentation with NT 4.0 learns that (at least on that system) > if a drive letter is followed by a double backslash, the drive letter > is ignored -- while a double backslash elsewhere in a filename is > treated the same as a single. > > I can't say that I understand the wisdom of these rules, but they are > standard NT, and I prefer not to try to "improve" upon it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Oct 4 22:12:38 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 04 Oct 1999 17:12:38 -0400 Subject: [Python-bugs-list] normpath error (PR#93) In-Reply-To: Your message of "Mon, 04 Oct 1999 16:05:41 CDT." References: Message-ID: <199910042112.RAA19335@eric.cnri.reston.va.us> > Hmmm, I see your reasoning. > > But what if (and I have not run this yet) the test path is > d:\\\data/test\\test.dlf? > By using this function I am saying I cannot gaurantee what the input will > look like. > > Looking at that loop, i would expect, > d:\\\data\test\test.dlf > since each pass adds a os.sep to the drive part after the split > > a drive letter + ':' IS a detectable situation and could be handled and > would not upset a UNC type path of just plain \\data\test\test.dlf If you want to submit a patch that strips excess leading separators beyond the second, be my guest. Personally, I think it's of marginal value. The drive letter doesn't enter into the equation as far as I can tell though. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Oct 4 22:12:33 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 4 Oct 1999 17:12:33 -0400 (EDT) Subject: [Python-bugs-list] normpath error (PR#93) Message-ID: <199910042112.RAA14470@python.org> > Hmmm, I see your reasoning. > > But what if (and I have not run this yet) the test path is > d:\\\data/test\\test.dlf? > By using this function I am saying I cannot gaurantee what the input will > look like. > > Looking at that loop, i would expect, > d:\\\data\test\test.dlf > since each pass adds a os.sep to the drive part after the split > > a drive letter + ':' IS a detectable situation and could be handled and > would not upset a UNC type path of just plain \\data\test\test.dlf If you want to submit a patch that strips excess leading separators beyond the second, be my guest. Personally, I think it's of marginal value. The drive letter doesn't enter into the equation as far as I can tell though. --Guido van Rossum (home page: http://www.python.org/~guido/) From bridge@gsnet.com Tue Oct 5 17:45:14 1999 From: bridge@gsnet.com (bridge@gsnet.com) Date: Tue, 5 Oct 1999 12:45:14 -0400 (EDT) Subject: [Python-bugs-list] strptime buffer overflow (PR#95) Message-ID: <199910051645.MAA15107@python.org> Full_Name: Mike Bridge Version: 1.5.2 OS: RedHat 5.2 Submission from: zuls.hebdomag.com (207.229.3.225) Hi- I got a core dump with the following line, and I don't see it in the bug database. I inadvertantly put a %X instead of a %Y in the format string for strptime: Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201 (egcs-1.1.1 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.strptime("Oct 28 1999", "%b %d %X") Segmentation fault (core dumped) From guido@CNRI.Reston.VA.US Tue Oct 5 17:50:00 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 5 Oct 1999 12:50:00 -0400 (EDT) Subject: [Python-bugs-list] strptime buffer overflow (PR#95) Message-ID: <199910051650.MAA15246@python.org> > I got a core dump with the following line, and I don't see it in the bug > database. I inadvertantly put a %X instead of a %Y in the format > string for strptime: > > Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201 (egcs-1.1.1 > on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import time > >>> time.strptime("Oct 28 1999", "%b %d %X") > Segmentation fault (core dumped) Thanks. This raises a ValueError when I try it on Solaris. The C code in the Python time module for this is very simple; unless you can prove otherwise, this is a bug in the C library on the Linux version you're using. (Note that this is one of the reasons why I was originally very reluctant to add strptime() to the time module -- it is ill specified and can be buggy, and it would be a lot of work to write a bulletproof piece of code to check that the format string is valid. But there was continuous pressure from strptime() fans to add it. My advice: write your own time parser for your own needs using regular expressions.) --Guido van Rossum (home page: http://www.python.org/~guido/) From vivek@khera.org Tue Oct 5 22:41:58 1999 From: vivek@khera.org (vivek@khera.org) Date: Tue, 5 Oct 1999 17:41:58 -0400 (EDT) Subject: [Python-bugs-list] BSDI BSD/OS 4.x has dynamic modules (PR#96) Message-ID: <199910052141.RAA25701@python.org> Full_Name: Vivek Khera Version: 1.5.2 OS: BSD/OS 4.0.1 Submission from: kci.kcilink.com (204.117.82.1) BSDI's BSD/OS 4.x supports dynamic loading of object modules. To enable it in Python, simply add lines of the form BSD/OS/4*) .... wherever there is a similar FreeBSD/3*) ... line using the same options. There were three lines I added: BSD/OS/4*) LDSHARED="gcc -shared";; BSD/OS/4*) CCSHARED="-fpic";; BSD/OS/4*) LINKFORSHARED="-Xlinker -export-dynamic";; I don't have autoconfig, so I can't really give you the patch directly to configure.in. make test works fine with these. From guido@CNRI.Reston.VA.US Tue Oct 5 22:59:50 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 5 Oct 1999 17:59:50 -0400 (EDT) Subject: [Python-bugs-list] BSDI BSD/OS 4.x has dynamic modules (PR#96) Message-ID: <199910052159.RAA26113@python.org> Thanks, I've applied something like you suggested. --Guido van Rossum (home page: http://www.python.org/~guido/) From alvin_nonaka@yahoo.com Wed Oct 6 13:41:21 1999 From: alvin_nonaka@yahoo.com (alvin_nonaka@yahoo.com) Date: Wed, 6 Oct 1999 08:41:21 -0400 (EDT) Subject: [Python-bugs-list] whichdb is coded wrong (PR#97) Message-ID: <199910061241.IAA21161@python.org> Full_Name: Alvin Y. Nonaka Version: 1.5.2 OS: Linux -- SuSE 6.2 distribution Submission from: (NULL) (209.241.96.11) I attempted to reproduce the exercise in Lutz's "Programming Python" book using the anydbm module, pp. 39-41. After creating the underlying file, I re-open the file using again anydbm and a simple program fails with File "/user/lib/python1.5/anydbm.py, line 83, in open raise error, "db type cannot be determined" anydbm.error: db type cannot be determined I created a series of simple test cases where being one of dbhash, gdbm, dbm, dumbdbm: import file=.open('test_','c'> file['Batman_']='this is ' file.close() The file types and first four bytes are as follows: test_dbhash 00 00 00 00 test_dbm.db 00 00 00 00 test_dumbdbm.dat 74 68 69 73 'this is dumbdbm' test_dumbdbm.dir 27 42 61 74 'Batman_dumbdbm' test_gdbm ce 9a 57 13 I used "hex editor" and "binary editor" from the kde interface under the "utility" menu. whichdb in pseudo-code: file has file extension .pag and .dir => "dbm" magic =1st 4 bytes of file magic == 0x13579ace => "gdbm" magic == 0x00061561 or magic == 0x61150600 => "dbhash" return "" My interpretation of the test cases tells me that the code should be: .dat and .dir => "dumbdbm" .db => "dbm" magic == 0x00000000 => "dbhash" magic == 0xce9a5713 => "gdbm" return "" It is no problem for me to code my own personal whichdb module that will work on my machine but I don't understand why whichdb is coded the way it is. I might grant different byte ordering for the "gdbm" case as I am running Linux on an Intel platform using the SuSE 6.2 distribution. The command line python echoes: Python 1.5.2 (#1, Jul 23, 19999, 06:38:16) [GCC egcs-2.91.66 19990314/Linux (egcs -- on linux2 However, with test cases for "dbhash", "dbm" and "dumbdbm", I can't determine why whichdb is coded the way it is. Instead of staticly coding whichdb, which might fail for various distribution/platform types, couldn't you create a generator that for the various test cases above generate a "tailored" whichdb for that particular distribution/platform? From guido@CNRI.Reston.VA.US Wed Oct 6 16:12:24 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 11:12:24 -0400 Subject: [Python-bugs-list] whichdb is coded wrong (PR#97) In-Reply-To: Your message of "Wed, 06 Oct 1999 08:41:21 EDT." <199910061241.IAA21161@python.org> References: <199910061241.IAA21161@python.org> Message-ID: <199910061512.LAA08832@eric.cnri.reston.va.us> > I attempted to reproduce the exercise in Lutz's "Programming Python" > book using the anydbm module, pp. 39-41. After creating the > underlying file, I re-open the file using again anydbm and a simple > program fails with > > File "/user/lib/python1.5/anydbm.py, line 83, in open > raise error, "db type cannot be determined" > anydbm.error: db type cannot be determined Apaprently new versions of bsddb have 12 null bytes in front of the magin number. A patch for whichdbm.py exists in the CVS archives; it is reproduced here: Index: whichdb.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/whichdb.py,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** whichdb.py 1998/04/28 15:41:03 1.4 --- whichdb.py 1999/06/08 13:13:16 1.5 *************** *** 31,39 **** except IOError: return None ! # Read the first 4 bytes of the file -- the magic number ! s = f.read(4) f.close() # Return "" if not at least 4 bytes if len(s) != 4: --- 31,40 ---- except IOError: return None ! # Read the start of the file -- the magic number ! s16 = f.read(16) f.close() + s = s16[0:4] # Return "" if not at least 4 bytes if len(s) != 4: *************** *** 48,53 **** --- 49,64 ---- # Check for GNU dbm if magic == 0x13579ace: return "gdbm" + + # Check for BSD hash + if magic in (0x00061561, 0x61150600): + return "dbhash" + + # BSD hash v2 has a 12-byte NULL pad in front of the file type + try: + (magic,) = struct.unpack("=l", s16[-4:]) + except struct.error: + return "" # Check for BSD hash if magic in (0x00061561, 0x61150600): > Instead of staticly coding whichdb, which might fail for various > distribution/platform types, couldn't you create a generator that for the > various test cases above generate a "tailored" whichdb for that particular > distribution/platform? The whichdbm module wants to be able to tell you the db type even if you don't have the library code to read it. Hardcoding a list of magic numbers is a common approach. Often (as you see here) the rules aren't as simple as "look at the first 4 bytes", and adding a new file type requires a little bit of thinking. Given the infrequent appearance of new db types, an automated approach is hardly worth it. (Prove me wrong by submitting the code :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Oct 6 16:12:15 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 6 Oct 1999 11:12:15 -0400 (EDT) Subject: [Python-bugs-list] whichdb is coded wrong (PR#97) Message-ID: <199910061512.LAA24958@python.org> > I attempted to reproduce the exercise in Lutz's "Programming Python" > book using the anydbm module, pp. 39-41. After creating the > underlying file, I re-open the file using again anydbm and a simple > program fails with > > File "/user/lib/python1.5/anydbm.py, line 83, in open > raise error, "db type cannot be determined" > anydbm.error: db type cannot be determined Apaprently new versions of bsddb have 12 null bytes in front of the magin number. A patch for whichdbm.py exists in the CVS archives; it is reproduced here: Index: whichdb.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/whichdb.py,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** whichdb.py 1998/04/28 15:41:03 1.4 --- whichdb.py 1999/06/08 13:13:16 1.5 *************** *** 31,39 **** except IOError: return None ! # Read the first 4 bytes of the file -- the magic number ! s = f.read(4) f.close() # Return "" if not at least 4 bytes if len(s) != 4: --- 31,40 ---- except IOError: return None ! # Read the start of the file -- the magic number ! s16 = f.read(16) f.close() + s = s16[0:4] # Return "" if not at least 4 bytes if len(s) != 4: *************** *** 48,53 **** --- 49,64 ---- # Check for GNU dbm if magic == 0x13579ace: return "gdbm" + + # Check for BSD hash + if magic in (0x00061561, 0x61150600): + return "dbhash" + + # BSD hash v2 has a 12-byte NULL pad in front of the file type + try: + (magic,) = struct.unpack("=l", s16[-4:]) + except struct.error: + return "" # Check for BSD hash if magic in (0x00061561, 0x61150600): > Instead of staticly coding whichdb, which might fail for various > distribution/platform types, couldn't you create a generator that for the > various test cases above generate a "tailored" whichdb for that particular > distribution/platform? The whichdbm module wants to be able to tell you the db type even if you don't have the library code to read it. Hardcoding a list of magic numbers is a common approach. Often (as you see here) the rules aren't as simple as "look at the first 4 bytes", and adding a new file type requires a little bit of thinking. Given the infrequent appearance of new db types, an automated approach is hardly worth it. (Prove me wrong by submitting the code :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From a.eyre@optichrome.com Fri Oct 8 15:29:59 1999 From: a.eyre@optichrome.com (a.eyre@optichrome.com) Date: Fri, 8 Oct 1999 10:29:59 -0400 (EDT) Subject: [Python-bugs-list] BUG: classobject.c (PR#98) Message-ID: <199910081429.KAA09979@python.org> 3 lines starting at 1554: funcname = PyObject_GetAttrString(func,"__name__"); if (funcname == NULL) PyErr_Clear(); should be (perhaps - not sure if this will leak or not): funcname = PyObject_GetAttrString(func,"__name__"); if (funcname == NULL) PyErr_Clear(); else Py_INCREF(funcname); or else - line 1562: Py_XDECREF(funcname); causes an free'd memory read (fname) at line 1567: if (self == NULL) sprintf(buf, "", fcname, fname); -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From janderson@novazen.com Fri Oct 8 20:56:39 1999 From: janderson@novazen.com (janderson@novazen.com) Date: Fri, 8 Oct 1999 15:56:39 -0400 (EDT) Subject: [Python-bugs-list] problem downloading python (PR#99) Message-ID: <199910081956.PAA17940@python.org> Full_Name: John Anderson Version: 1.5 OS: NT Submission from: fw.novazen.com (209.38.244.2) I received the following error upon installation of Python: " This application uses CTL3D32.dll, which is not the correct version. This version of CTL3D32.dll is designed only for WIN 32 or Windows 95 systems" According to your web site NT downloads fall under the same category as 32/95. Please let me know what the problem is, I enjoy your product and need to do some scripting. Thanks for your help From deirdre@linuxcare.com Sat Oct 9 00:42:49 1999 From: deirdre@linuxcare.com (deirdre@linuxcare.com) Date: Fri, 8 Oct 1999 19:42:49 -0400 (EDT) Subject: [Python-bugs-list] Patch for poplib LIST command (PR#100) Message-ID: <199910082342.TAA23015@python.org> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --4786689-1676962025-939425855=:8432 Content-Type: TEXT/PLAIN; charset=US-ASCII There are two syntaxes for the LIST command; both were assumed to be multiline however only one of them is per RFC 1939. From the RFC, the syntax for LIST n: C: LIST 2 S: +OK 2 200 The patch below fixes poplib.py (as it'll be munged my my MUA, I've attached a copy also): 8d7 < Updated: Deirdre Saoirse , [Oct '99] 202,210c201,203 < Two syntaxes: < LIST (no parameter): < Result is in form ['response', ['mesg_num octets', ...], 39]. < This is a "long" command as it is a multiline response. < < LIST (with parameter): < Response is for specified message number < Result is in form ['response', 'mesg_num octets']. < This is a "short" command as it is a one-line response. --- > Result is in form ['response', ['mesg_num octets', ...]]. > > Unsure what the optional 'msg' arg does. 213,214c206 < return self._shortcmd('LIST %s' % which) < --- > return self._longcmd('LIST %s' % which) -- Deirdre Saoirse, Systems Analyst, Linuxcare, Inc. 415.354.4878 x252 tel, 415.701.7457 fax dsaoirse@linuxcare.com, http://www.linuxcare.com/ Linuxcare. At the center of Linux. --4786689-1676962025-939425855=:8432 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=poplibdiff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=poplibdiff OGQ3DQo8IFVwZGF0ZWQ6IERlaXJkcmUgU2FvaXJzZSA8ZGVpcmRyZUBsaW51 eGNhcmUuY29tPiwgPGRlaXJkcmVAZGVpcmRyZS5uZXQ+IFtPY3QgJzk5XQ0K MjAyLDIxMGMyMDEsMjAzDQo8IAkJVHdvIHN5bnRheGVzOg0KPCAJCUxJU1Qg KG5vIHBhcmFtZXRlcik6DQo8IAkJUmVzdWx0IGlzIGluIGZvcm0gWydyZXNw b25zZScsIFsnbWVzZ19udW0gb2N0ZXRzJywgLi4uXSwgMzldLg0KPCAJCVRo aXMgaXMgYSAibG9uZyIgY29tbWFuZCBhcyBpdCBpcyBhIG11bHRpbGluZSBy ZXNwb25zZS4NCjwgCQkNCjwgCQlMSVNUICh3aXRoIHBhcmFtZXRlcik6DQo8 IAkJUmVzcG9uc2UgaXMgZm9yIHNwZWNpZmllZCBtZXNzYWdlIG51bWJlcg0K PCAJCVJlc3VsdCBpcyBpbiBmb3JtIFsncmVzcG9uc2UnLCAnbWVzZ19udW0g b2N0ZXRzJ10uDQo8IAkJVGhpcyBpcyBhICJzaG9ydCIgY29tbWFuZCBhcyBp dCBpcyBhIG9uZS1saW5lIHJlc3BvbnNlLg0KLS0tDQo+IAkJUmVzdWx0IGlz IGluIGZvcm0gWydyZXNwb25zZScsIFsnbWVzZ19udW0gb2N0ZXRzJywgLi4u XV0uDQo+IA0KPiAJCVVuc3VyZSB3aGF0IHRoZSBvcHRpb25hbCAnbXNnJyBh cmcgZG9lcy4NCjIxMywyMTRjMjA2DQo8IAkJCXJldHVybiBzZWxmLl9zaG9y dGNtZCgnTElTVCAlcycgJSB3aGljaCkNCjwgCQkNCi0tLQ0KPiAJCQlyZXR1 cm4gc2VsZi5fbG9uZ2NtZCgnTElTVCAlcycgJSB3aGljaCkNCg== --4786689-1676962025-939425855=:8432-- From tim_one@email.msn.com Sat Oct 9 03:20:45 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 8 Oct 1999 22:20:45 -0400 Subject: [Python-bugs-list] problem downloading python (PR#99) In-Reply-To: <199910081956.PAA17940@python.org> Message-ID: <000f01bf11fc$e5343d20$19a2143f@tim> [janderson@novazen.com] > I received the following error upon installation of Python: > > " This application uses CTL3D32.dll, which is not the correct version. > This version of CTL3D32.dll is designed only for WIN 32 or > Windows 95 systems" This is not a bug. The Python installer does not ship with this DLL. It's a Microsoft DLL that the installer happens to *use* (specifically, the installer uses it to give its progress bar a three-dimensional "look"). The message means what it says: you have the wrong DLL for your operating system. Some previous installation of something else did this to you, but you never noticed it before because few programs-- other than, it seems, installers! --use this DLL. Search the web for CTL3D32.DLL, and you'll find over a thousand pages complaining about the same thing for hundreds of other products. One of the funniest is at http://support.microsoft.com/support/kb/articles/q181/0/17.asp where Microsoft itself got burned by this problem. You can ignore the error (it doesn't affect the installation), or you can get the correct DLL for your system. For example, from your Windows installation CD, or from http://www.techadvice.com/tech/C/CTL3D32.htm From tim_one@email.msn.com Sat Oct 9 03:21:09 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Fri, 8 Oct 1999 22:21:09 -0400 (EDT) Subject: [Python-bugs-list] problem downloading python (PR#99) Message-ID: <199910090221.WAA24953@python.org> [janderson@novazen.com] > I received the following error upon installation of Python: > > " This application uses CTL3D32.dll, which is not the correct version. > This version of CTL3D32.dll is designed only for WIN 32 or > Windows 95 systems" This is not a bug. The Python installer does not ship with this DLL. It's a Microsoft DLL that the installer happens to *use* (specifically, the installer uses it to give its progress bar a three-dimensional "look"). The message means what it says: you have the wrong DLL for your operating system. Some previous installation of something else did this to you, but you never noticed it before because few programs-- other than, it seems, installers! --use this DLL. Search the web for CTL3D32.DLL, and you'll find over a thousand pages complaining about the same thing for hundreds of other products. One of the funniest is at http://support.microsoft.com/support/kb/articles/q181/0/17.asp where Microsoft itself got burned by this problem. You can ignore the error (it doesn't affect the installation), or you can get the correct DLL for your system. For example, from your Windows installation CD, or from http://www.techadvice.com/tech/C/CTL3D32.htm From guido@cnri.reston.va.us Mon Oct 11 13:41:41 1999 From: guido@cnri.reston.va.us (guido@cnri.reston.va.us) Date: Mon, 11 Oct 1999 08:41:41 -0400 (EDT) Subject: [Python-bugs-list] Patch for poplib LIST command (PR#100) Message-ID: <199910111241.IAA20275@python.org> Deirdre, Are you sure you are working against the 1.5.2 poplib.py? your patch fails, and the code seems to already do what you describe. Also, please follow the instructions in www.python.org/1.5/patch.html regarding patches -- I strongly prefer context diffs (and please don't send reverse diffs) and CNRI's lawyers like to see some standard disclaimer text. It also seems that the bugs-py mailing address doesn't like attachments. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@cnri.reston.va.us Mon Oct 11 13:41:44 1999 From: guido@cnri.reston.va.us (guido@cnri.reston.va.us) Date: Mon, 11 Oct 1999 08:41:44 -0400 (EDT) Subject: [Python-bugs-list] BUG: classobject.c (PR#98) Message-ID: <199910111241.IAA20285@python.org> > 3 lines starting at 1554: > funcname = PyObject_GetAttrString(func,"__name__"); > if (funcname == NULL) > PyErr_Clear(); > > should be (perhaps - not sure if this will leak or not): > funcname = PyObject_GetAttrString(func,"__name__"); > if (funcname == NULL) > PyErr_Clear(); > else > Py_INCREF(funcname); > > or else - line 1562: > Py_XDECREF(funcname); > > causes an free'd memory read (fname) at line 1567: > if (self == NULL) > sprintf(buf, "", fcname, fname); Almost. The PyObject_GetAttrString() call increfs the object, but if the refcnt is 1, the fname variable can point to freed memory because the object is decrefed before it is used. I think that the proper fix is to move the Py_XDECREF() call down towards the end of the function, as follows: Index: classobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/classobject.c,v retrieving revision 2.80 diff -c -r2.80 classobject.c *** classobject.c 1998/08/04 14:59:16 2.80 --- classobject.c 1999/10/10 21:21:26 *************** *** 1559,1565 **** fname = PyString_AS_STRING(funcname); else fname = "?"; - Py_XDECREF(funcname); if (fclassname != NULL && PyString_Check(fclassname)) fcname = PyString_AsString(fclassname); else --- 1559,1564 ---- *************** *** 1575,1580 **** --- 1574,1580 ---- sprintf(buf, "", fcname, fname, icname, (long)self); } + Py_XDECREF(funcname); return PyString_FromString(buf); } Can you try this? (I don't have a testcase that exposes this bug; do you?) Please let me know so I can check in the fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@cnri.reston.va.us Sun Oct 10 22:24:34 1999 From: guido@cnri.reston.va.us (Guido van Rossum) Date: Sun, 10 Oct 1999 17:24:34 -0400 Subject: [Python-bugs-list] BUG: classobject.c (PR#98) In-Reply-To: Your message of "Fri, 08 Oct 1999 10:29:59 EDT." <199910081429.KAA09979@python.org> References: <199910081429.KAA09979@python.org> Message-ID: <199910102124.RAA12392@eric.cnri.reston.va.us> > 3 lines starting at 1554: > funcname = PyObject_GetAttrString(func,"__name__"); > if (funcname == NULL) > PyErr_Clear(); > > should be (perhaps - not sure if this will leak or not): > funcname = PyObject_GetAttrString(func,"__name__"); > if (funcname == NULL) > PyErr_Clear(); > else > Py_INCREF(funcname); > > or else - line 1562: > Py_XDECREF(funcname); > > causes an free'd memory read (fname) at line 1567: > if (self == NULL) > sprintf(buf, "", fcname, fname); Almost. The PyObject_GetAttrString() call increfs the object, but if the refcnt is 1, the fname variable can point to freed memory because the object is decrefed before it is used. I think that the proper fix is to move the Py_XDECREF() call down towards the end of the function, as follows: Index: classobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/classobject.c,v retrieving revision 2.80 diff -c -r2.80 classobject.c *** classobject.c 1998/08/04 14:59:16 2.80 --- classobject.c 1999/10/10 21:21:26 *************** *** 1559,1565 **** fname = PyString_AS_STRING(funcname); else fname = "?"; - Py_XDECREF(funcname); if (fclassname != NULL && PyString_Check(fclassname)) fcname = PyString_AsString(fclassname); else --- 1559,1564 ---- *************** *** 1575,1580 **** --- 1574,1580 ---- sprintf(buf, "", fcname, fname, icname, (long)self); } + Py_XDECREF(funcname); return PyString_FromString(buf); } Can you try this? (I don't have a testcase that exposes this bug; do you?) Please let me know so I can check in the fix. --Guido van Rossum (home page: http://www.python.org/~guido/) From flight@mathi.uni-heidelberg.de Mon Oct 11 14:10:34 1999 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Mon, 11 Oct 1999 09:10:34 -0400 (EDT) Subject: [Python-bugs-list] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101) Message-ID: <199910111310.JAA20818@python.org> Full_Name: Gregor Hoffleit Version: 1.5.2 OS: Debian GNU/Linux potato [This was recorded as Debian bug#46993, cf. http://www.debian.org/Bugs/db/46/46993.html] Package: python-base Version: 1.5.2-6 Severity: normal On Unix systems, py_compile.compile() (and therefore compileall.py) won't compile files with DOS/Windows lineendings (CR+LF). Commands like "import" or "exec" will work, though. The problem seems to be that py_compile.compile read()'s the whole file at once and passes it as a string to __builtin__.compile(), while "import" calls __builtin__.compile() for a file, so that __builtin__.compile seems to do some magic while reading the file. For a quick testcase: import __builtin__ f=open("test.py","w") f.write('print "Hello"\015\012') f.close() f=open("test.py") c=f.read() f.close() __builtin__.compile(c,"test.py","exec") results in: Traceback (innermost last): File "", line 1, in ? File "", line 9, in x File "", line 1 print "Hello" ^ SyntaxError: invalid syntax while "import test" works fine and results in test.pyc. Certainly the file.read() in py_compile.compile() isn't good enough for this case. Gregor From Vladimir.Benes@pvt.cz Mon Oct 11 14:45:56 1999 From: Vladimir.Benes@pvt.cz (Vladimir.Benes@pvt.cz) Date: Mon, 11 Oct 1999 09:45:56 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <199910111345.JAA21590@python.org> Good afternoon, I have found a bug on Python 1.5.2. This bug doesn't occur on Python 1.5.1. Python versions and OS: - Python 1.5.1. at Debian GNU/Linux 2.0.36 - Python 1.5.2. at Debian GNU/Linux 2.2.9 Bug: Incorrect signal processing (Python 1.5.2). Process can assign procedure for signal processing. When process is waiting at system call and this signal occur, then the signal assigned procedure is otherwise correctly completed but then waiting at system call is broken and process continues. Here is a simple program for demonstrate this bug: #!/usr/bin/python import signal import sys def signal_handle(signum, frame) : signal.signal(signal.SIGALRM, signal_handle) signal.alarm(2) print "signal" signal_handle(0,0) a=sys.stdin.readline() print "Line examined..." b=sys.stdin.readline() print "Line examined..." print a,b,"end" # end of example Correct behaviour: Message "Line examined..." occurs only after pressing ENTER by user. Bug: Message "Line examined..." occurs immediately after signal occured and procedure signal_handle finished. Output then look thus (when no input entered): signal signal Line examined... signal Line examined... end This bug appears at any signal occur and whatever process waiting at system call. Some system call even produces exception (e.g. waiting for data or connection on socket). Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I haven't found any way how call in Python program "siginterrupt" for correct behavior of signal processing. Good bye, V. Benes **************************************************************************** Ing. Vladimir Benes, pvt.net PVT, a.s., OZ Chomutov e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz **************************************************************************** From deirdre@linuxcare.com Mon Oct 11 18:05:27 1999 From: deirdre@linuxcare.com (deirdre@linuxcare.com) Date: Mon, 11 Oct 1999 13:05:27 -0400 (EDT) Subject: [Python-bugs-list] Patch for poplib LIST command (PR#100) Message-ID: <199910111705.NAA29973@python.org> On Sun, 10 Oct 1999, Guido van Rossum wrote: > Are you sure you are working against the 1.5.2 poplib.py? your patch > fails, and the code seems to already do what you describe. Actually, when I reversed my version recently from a CVS, it seems I installed the LinuxPPC 1.5.1 version rather than 1.5.2. Eep. And yes, it was modified in 1.5.2 which explains why it suddenly stopped working (I went back a version). I'm writing an APOP server (technically, a POP3 server that only does APOP authentication) that I'd be happy to contribute if you're interested. > Also, please follow the instructions in www.python.org/1.5/patch.html > regarding patches -- I strongly prefer context diffs (and please don't > send reverse diffs) and CNRI's lawyers like to see some standard > disclaimer text. Ah, OK. I was looking for an official way of doing this but couldn't find it. I'll bookmark the page. > It also seems that the bugs-py mailing address doesn't like > attachments. OK. Thanks for the tips. -- Deirdre Saoirse, Systems Analyst, Linuxcare, Inc. 415.354.4878 x252 tel, 415.701.7457 fax dsaoirse@linuxcare.com, http://www.linuxcare.com/ Linuxcare. At the center of Linux. From mhammond@skippinet.com.au Mon Oct 11 23:13:10 1999 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Mon, 11 Oct 1999 18:13:10 -0400 (EDT) Subject: [Python-Help] janderson@novazen.com: [Python-bugs-list] problem downloading python (PR#99) Message-ID: <199910112213.SAA10263@python.org> This usually means that some other application has installed a bad CTL3D32.DLL, and when the WISE installer attempts to use it, it fails. There is an option in WISE you can set for the installation to use "internal 3D effects" - the documentation is very scant on this, but it appears this will prevent WISE from trying to use this file. It may be worth setting next time you go into WISE (although we need someone with the problem so we can determine if we have fixed anything :-) Mark. > I've seen this before but I don't recall the answer. If someone can > cc me the answer I'll add it to the bugs database... > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ------- Forwarded Message > > Date: Fri, 08 Oct 1999 15:56:39 -0400 > From: janderson@novazen.com > To: python-bugs-list@python.org > cc: bugs-py@python.org > Subject: [Python-bugs-list] problem downloading python (PR#99) > > Full_Name: John Anderson > Version: 1.5 > OS: NT > Submission from: fw.novazen.com (209.38.244.2) > > > I received the following error upon installation of Python: > > " This application uses CTL3D32.dll, which is not the correct version. > This version of CTL3D32.dll is designed only for WIN 32 or > Windows 95 systems" > > > According to your web site NT downloads fall under the same > category as 32/95. > Please let me know what the problem is, I enjoy your product > and need to do som > e > scripting. > Thanks for your help > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > > ------- End of Forwarded Message > > > _______________________________________________ > Python-Help maillist - Python-Help@python.org > http://www.python.org/mailman/listinfo/python-help > From apsteffe@netwood.net Tue Oct 12 03:21:01 1999 From: apsteffe@netwood.net (apsteffe@netwood.net) Date: Mon, 11 Oct 1999 22:21:01 -0400 (EDT) Subject: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Message-ID: <199910120221.WAA17590@python.org> Full_Name: Alfred Steffens Jr. Version: 1.5.2 OS: Linux Submission from: p138.netwood.net (209.247.185.38) I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . From guido@CNRI.Reston.VA.US Tue Oct 12 04:08:55 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 11 Oct 1999 23:08:55 -0400 (EDT) Subject: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Message-ID: <199910120308.XAA18088@python.org> > Full_Name: Alfred Steffens Jr. > Version: 1.5.2 > OS: Linux > Submission from: p138.netwood.net (209.247.185.38) > > I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to > execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. > The functions work ok with kernel 1.2.13 . The Linux and glibc kernel versions don't mean much to me. Can you fire up a debugger and see where in the C code it crashes? Also, is this for a specific URL or is it for any URL? If a specific URL, I'd like to know which one. Finally, did you get or build the Python executable matching your kernel? A Linux upgrade from 1.x to 2.x seems a big deal, it's possible that you'll need a new Python installation or build. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@cnri.reston.va.us Tue Oct 12 17:04:35 1999 From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us) Date: Tue, 12 Oct 1999 12:04:35 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <199910121604.MAA09415@python.org> >>>>> "VB" == Vladimir Benes writes: VB> Bug: Incorrect signal processing (Python 1.5.2). Process can VB> assign procedure for signal processing. When process is waiting VB> at system call and this signal occur, then the signal assigned VB> procedure is otherwise correctly completed but then waiting at VB> system call is broken and process continues. [example program] I see the behavior you report for 1.5.2 on Solaris 2.6. VB> This bug appears at any signal occur and whatever process VB> waiting at system call. Some system call even produces exception VB> (e.g. waiting for data or connection on socket). These issues always occur in twos don't they. There was a similar question posted on comp.lang.python yesterday. I'm not sure that the behavior you're seeing is a bug; it is the behavior I would expect. Slow system calls are interrupted, returning EINTR, when a signal occurs. VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. Perhaps the signal module for Python should be extended to support siginterrupt, but it sounds like it will only reduce the number of system calls that can be interrupted. The Solaris man page says: NOTES Use of these interfaces should be restricted to only appli- cations written on BSD platforms. Use of these interfaces with any of the system libraries or in multi-threaded appli- cations is unsupported. It doesn't sound particularly safe. Jeremy From jeremy@cnri.reston.va.us Tue Oct 12 17:04:42 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) In-Reply-To: <199910111345.JAA21590@python.org> References: <199910111345.JAA21590@python.org> Message-ID: <14339.23578.578924.338442@bitdiddle.cnri.reston.va.us> >>>>> "VB" == Vladimir Benes writes: VB> Bug: Incorrect signal processing (Python 1.5.2). Process can VB> assign procedure for signal processing. When process is waiting VB> at system call and this signal occur, then the signal assigned VB> procedure is otherwise correctly completed but then waiting at VB> system call is broken and process continues. [example program] I see the behavior you report for 1.5.2 on Solaris 2.6. VB> This bug appears at any signal occur and whatever process VB> waiting at system call. Some system call even produces exception VB> (e.g. waiting for data or connection on socket). These issues always occur in twos don't they. There was a similar question posted on comp.lang.python yesterday. I'm not sure that the behavior you're seeing is a bug; it is the behavior I would expect. Slow system calls are interrupted, returning EINTR, when a signal occurs. VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. Perhaps the signal module for Python should be extended to support siginterrupt, but it sounds like it will only reduce the number of system calls that can be interrupted. The Solaris man page says: NOTES Use of these interfaces should be restricted to only appli- cations written on BSD platforms. Use of these interfaces with any of the system libraries or in multi-threaded appli- cations is unsupported. It doesn't sound particularly safe. Jeremy From mengkuan@lga.net.sg Wed Oct 13 03:40:52 1999 From: mengkuan@lga.net.sg (mengkuan@lga.net.sg) Date: Tue, 12 Oct 1999 22:40:52 -0400 (EDT) Subject: [Python-bugs-list] time.daylight error (PR#104) Message-ID: <199910130240.WAA27917@python.org> Full_Name: Chew Meng Kuan Version: 1.5.2 OS: Linux 2.2 Submission from: (NULL) (203.116.84.242) Hi, The following works in Python 1.5.1: $ /usr/bin/python1.5 Python 1.5.1 (#1, Oct 19 1998, 21:36:37) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.daylight 0 >>> However, the same thing fails in 1.5.2 on the same machine: $ /usr/local/bin/python Python 1.5.2 (#1, Oct 13 1999, 10:18:22) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.daylight Traceback (innermost last): File "", line 1, in ? AttributeError: daylight >>> I was trying to compile python 1.5.2 for use with Zope 2.0.1. Thanks. Meng Kuan From guido@CNRI.Reston.VA.US Wed Oct 13 04:17:52 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 12 Oct 1999 23:17:52 -0400 (EDT) Subject: [Python-bugs-list] time.daylight error (PR#104) Message-ID: <199910130317.XAA02032@python.org> > However, the same thing fails in 1.5.2 on the same machine: > > $ /usr/local/bin/python > Python 1.5.2 (#1, Oct 13 1999, 10:18:22) [GCC 2.7.2.3] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import time > >>> time.daylight > Traceback (innermost last): > File "", line 1, in ? > AttributeError: daylight > >>> I believe this is a bug in the way timemodule.c detects different GLIBC versions. It has been fixed in our CVS version; here is the patch for you: Index: timemodule.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Modules/timemodule.c,v retrieving revision 2.74 retrieving revision 2.75 diff -c -r2.74 -r2.75 *** timemodule.c 1999/04/05 21:54:14 2.74 --- timemodule.c 1999/04/23 20:59:05 2.75 *************** *** 616,622 **** /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GNU_LIBRARY__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); --- 616,622 ---- /* Squirrel away the module's dictionary for the y2k check */ Py_INCREF(d); moddict = d; ! #if defined(HAVE_TZNAME) && !defined(__GLIBC__) tzset(); #ifdef PYOS_OS2 ins(d, "timezone", PyInt_FromLong((long)_timezone)); *************** *** 634,640 **** #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GNU_LIBRARY__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) --- 634,640 ---- #endif ins(d, "daylight", PyInt_FromLong((long)daylight)); ins(d, "tzname", Py_BuildValue("(zz)", tzname[0], tzname[1])); ! #else /* !HAVE_TZNAME || __GLIBC__ */ #ifdef HAVE_TM_ZONE { #define YEAR ((time_t)((365 * 24 + 6) * 3600)) *************** *** 683,689 **** ins(d, "tzname", Py_BuildValue("(zz)", "", "")); #endif /* macintosh */ #endif /* HAVE_TM_ZONE */ ! #endif /* !HAVE_TZNAME || __GNU_LIBRARY__ */ if (PyErr_Occurred()) Py_FatalError("Can't initialize time module"); } --- 683,689 ---- ins(d, "tzname", Py_BuildValue("(zz)", "", "")); #endif /* macintosh */ #endif /* HAVE_TM_ZONE */ ! #endif /* !HAVE_TZNAME || __GLIBC__ */ if (PyErr_Occurred()) Py_FatalError("Can't initialize time module"); } --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Benes@pvt.cz Wed Oct 13 08:19:40 1999 From: Vladimir.Benes@pvt.cz (Vladimir.Benes@pvt.cz) Date: Wed, 13 Oct 1999 03:19:40 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <199910130719.DAA10439@python.org> From: Jeremy Hylton To: Vladimir.Benes@pvt.cz Cc: python-bugs-list@python.org ; bugs-py@python.org Date: 12. 10. 1999 18:04 Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) JH>I see the behavior you report for 1.5.2 on Solaris 2.6. You don't write whether this bug appeared there. JH> ...... I'm not sure that the JH> behavior you're seeing is a bug; it is the behavior I would expect. JH> Slow system calls are interrupted, returning EINTR, when a signal JH> occurs. I'am sure that this behavior is bug becouse: 1. I wrote the same program in C language (see below). 2. I ran this program at the same machine where the Python *) program works incorrectly. 3. Behavior of C program is correct (line scan is ended only when user press ENTER and this end is independed on signal). => The C program works correct and the same Python *) program fails at the same platform. Base run of program should by independed on signal processing except program terminating signals. It's independed at C program but incorrect processed by Python *) programs. *) only Python 1.5.2; Python 1.5.1 here works correctly Here is the mentioned program: #include #include #include void signal_handle(int signum) { signal(SIGALRM, signal_handle); alarm(2); printf("signal\n\r"); } void main(void) { char a[100], b[100]; signal_handle(0); scanf("%s",&a); printf("Line examined...\n\r"); scanf("%s",&b); printf("Line examined...\n\r"); printf("%s\t%s\tend\n\r", a, b); } VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. JH> Perhaps the signal module for Python should be extended to support JH> siginterrupt, but it sounds like it will only reduce the number of JH> system calls that can be interrupted. ....... Sorry, I wrong formulated possible couse of bug. I will try to specify my idea: It looks that there is any wrong calling "siginterupt" on signal module. Python libraries doesn't allow me to try correct this bug by calling "siginiterrupt" in my program before signal setting. But the best way is to reapir bug on signal module. Good bye, V. Benes From Vladimir.Benes@pvt.cz Wed Oct 13 08:19:44 1999 From: Vladimir.Benes@pvt.cz (=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=) Date: Wed, 13 Oct 1999 09:19:44 +0200 Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <001a01bf154b$52d53c20$451c11ac@p53apk.chv.pvt.cz> From: Jeremy Hylton To: Vladimir.Benes@pvt.cz Cc: python-bugs-list@python.org ; bugs-py@python.org Date: 12. 10. 1999 18:04 Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) JH>I see the behavior you report for 1.5.2 on Solaris 2.6. You don't write whether this bug appeared there. JH> ...... I'm not sure that the JH> behavior you're seeing is a bug; it is the behavior I would expect. JH> Slow system calls are interrupted, returning EINTR, when a signal JH> occurs. I'am sure that this behavior is bug becouse: 1. I wrote the same program in C language (see below). 2. I ran this program at the same machine where the Python *) program works incorrectly. 3. Behavior of C program is correct (line scan is ended only when user press ENTER and this end is independed on signal). => The C program works correct and the same Python *) program fails at the same platform. Base run of program should by independed on signal processing except program terminating signals. It's independed at C program but incorrect processed by Python *) programs. *) only Python 1.5.2; Python 1.5.1 here works correctly Here is the mentioned program: #include #include #include void signal_handle(int signum) { signal(SIGALRM, signal_handle); alarm(2); printf("signal\n\r"); } void main(void) { char a[100], b[100]; signal_handle(0); scanf("%s",&a); printf("Line examined...\n\r"); scanf("%s",&b); printf("Line examined...\n\r"); printf("%s\t%s\tend\n\r", a, b); } VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. JH> Perhaps the signal module for Python should be extended to support JH> siginterrupt, but it sounds like it will only reduce the number of JH> system calls that can be interrupted. ....... Sorry, I wrong formulated possible couse of bug. I will try to specify my idea: It looks that there is any wrong calling "siginterupt" on signal module. Python libraries doesn't allow me to try correct this bug by calling "siginiterrupt" in my program before signal setting. But the best way is to reapir bug on signal module. Good bye, V. Benes From guido@CNRI.Reston.VA.US Wed Oct 13 13:57:09 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 13 Oct 1999 08:57:09 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <199910131257.IAA24286@python.org> > JH> ...... I'm not sure that the > JH> behavior you're seeing is a bug; it is the behavior I would expect. > JH> Slow system calls are interrupted, returning EINTR, when a signal > JH> occurs. > [Vladimir] > I'am sure that this behavior is bug becouse: When I first thought about this, I agreed with Vladimir. If you look careful at his code, readline() is returning "" when the alarm goes off; this can't be right, because it's not an end of file. It should either raise an exception (EINTR) or return one line of valid data. On the other hand, whatever solution is chosen should be careful that other signals raise exceptions; in particular you want SIGINT (^C) to be translated to a KeyboardError exception. Since the C code in readline() can't tell which signal was trapped or whether the handler raised an exception, it has two choices, both of which are bad: - Raise an IOError exception, honoring the EINTR. Unfortunately, in the SIGINT/^C case, the handler will run after this exception is raised, and it will raise KeyboardError. The Python program will *probably* see the KeyboardError exception, but it is not guaranteed that the signal handler is run immediately. (The Python-level signal handler is run only after the Python virtual machine finishes the current instruction, i.e. after the readline() completes.) - Continue to read a line, ignoring the EINTR. Unfortunately, this would mean that the user has to type ^C followed by Return to interrupt the program! An alternative solution would be to arrange for the Python-level interrupt handler to execute inside the readline() method, and to restart the read only when it raises no exception; but this would require a massive code rewrite (you'd want this behavior in any place that does a blocking I/O operation). Concluding, I think Vladimir is better off not to use signal handlers in the way he is using them now. Python's emulation of signal semantics is sufficiently different from C that you can't rely on the same behavior. (And note that in C, signal handlers are usually broken anyway; e.g. the code you write, which prints something inside the signal handler, is broken on C too because you don't know the state of stdout when the handler is invoked.) I looked at what could be different between 1.5.1 and 1.5.2, and found that the call to siginterrupt() to disable restarting system calls was added after 1.5.1. Given the alternatives, I think I like the 1.5.2 behavior better than the 1.5.1 behavior. --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Benes@pvt.cz Wed Oct 13 15:32:42 1999 From: Vladimir.Benes@pvt.cz (Vladimir.Benes@pvt.cz) Date: Wed, 13 Oct 1999 10:32:42 -0400 (EDT) Subject: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <199910131432.KAA26230@python.org> >... >Concluding, I think Vladimir is better off not to use signal handlers >in the way he is using them now. Python's emulation of signal >semantics is sufficiently different from C that you can't rely on the >same behavior. (And note that in C, signal handlers are usually >broken anyway; e.g. the code you write, which prints something inside >the signal handler, is broken on C too because you don't know the >state of stdout when the handler is invoked.) Well, meantioned programs were only very simple demos for demonstrate incorrect signal processing. But exists a large range of meaningful programs where is necessary both synchronous and asynchronous signal processing - and signal can be triggered whenever. Example of C symbolic structure this programs: .... int event_flag; void trigger_signal(int signum) { // asynchonous signal processing event_flag = MY_EVENT; // only flag set } void initialize_signal(int sig) { event_flag = NO_EVENT; // initialize signal(sig, trigger_signal); } int main() { initialize_signal(SIGTERM); while (1) { my_func(); // synchronous signal processing: if (event_flag==MY_EVENT) my_sync_trigger(); } } Signal can be raised whenever when function my_func runs => flag event_flag is then set but my_func "does't know" his and continues at own processing. Signal should not influence my_func becouse my_func "doesn't know" both this signal and flag event_flag. Function event_flag can wait for system call (read, write, connect, etc). Incoming signal should not finish this waiting after trigger_signal function processing. So my_func is independed on signal processing and "does'nt know" signals. Program tests the flag at any "safe" location(s). If this flag is set, program run specific synchronous signal processing. It can be for example safe program end or synchronous SIGALRM processing. Python programs can by compose similar this example. >I looked at what could be different between 1.5.1 and 1.5.2, and found >that the call to siginterrupt() to disable restarting system calls was >added after 1.5.1. Given the alternatives, I think I like the 1.5.2 >behavior better than the 1.5.1 behavior. But then old Python programs writen for Python 1.5.1 are not compatible with Python 1.5.2. in this feature. I thing that better way is to let this behavior equal as in Python 1.5.1. but allow programs to call either new function "siginterrupt" at signal module (more flexible solution) or any else new function at signal module to set behavior signal processing by Your idea. Good bye, V. Benes From igal@sphera.com Wed Oct 13 19:06:34 1999 From: igal@sphera.com (igal@sphera.com) Date: Wed, 13 Oct 1999 14:06:34 -0400 (EDT) Subject: [Python-bugs-list] append add to list in both father and inherit class (PR#105) Message-ID: <199910131806.OAA01855@python.org> Full_Name: Igal Harel Version: 1.5.2 OS: solaris 7 Submission from: (NULL) (212.29.248.198) ## List's Append BUG Example class A: FList = [] def Append(self,Item=''): self.FList.append(Item) class B(A): "" class C(A): FB = None def __init__(self): self.FB = B() c = C() c.Append('Item for container ( instance of C ) only') print c.FB.FList,c.FList From guido@CNRI.Reston.VA.US Wed Oct 13 19:22:32 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 13 Oct 1999 14:22:32 -0400 (EDT) Subject: [Python-bugs-list] append add to list in both father and inherit class (PR#105) Message-ID: <199910131822.OAA02317@python.org> > Full_Name: Igal Harel > Version: 1.5.2 > OS: solaris 7 > Submission from: (NULL) (212.29.248.198) > > > ## List's Append BUG Example > > class A: > FList = [] > def Append(self,Item=''): > self.FList.append(Item) > > class B(A): > "" > > class C(A): > FB = None > def __init__(self): > self.FB = B() > > c = C() > c.Append('Item for container ( instance of C ) only') > print c.FB.FList,c.FList You're not very clear about what happens or what you had expected, but my guess is that you're confused by Python's rules about sharing objects. There is only a single FList object shared by all instances of class A, including instances of its subclasses (B and C). This object can be accessed as self.FList but that is really just another name for A.FList. When you append to it, the change will be reflected no matter which name you use to access it later. If you want each A instance to have its own FList object, use a constructor method: class A: def __init__(self): self.FList = [] def Append(self, Item=''): ....as before.... --Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Wed Oct 13 19:35:17 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Wed, 13 Oct 1999 14:35:17 -0400 (EDT) Subject: [Python-bugs-list] Tkinter bug: winfo_visualsavailable (PR#106) Message-ID: <199910131835.OAA02727@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5.5f Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) It appears that winfo_visualsavailable isn't prepared to get back hex values for visual IDs (which is what comes up from Tk). ( Python 1.5.2, tcl/tk8.0.4 ) Randall > python Python 1.5.2 (#3, Jul 8 1999, 11:01:48) [C] on irix646-n32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import Tkinter >>> root = Tkinter.Tk() >>> root.tk.call('winfo', 'visualsavailable', root._w, 'includeids') '{pseudocolor 2 0x20} {pseudocolor 2 0x21} {pseudocolor 4 0x22} {pseudocolor 4 0 x23} {truecolor 4 0x24} {pseudocolor 8 0x25} {staticcolor 8 0x26} {truecolor 8 0 x27} {pseudocolor 12 0x28} {pseudocolor 12 0x29} {pseudocolor 12 0x2a} {pseudoco lor 12 0x2b} {truecolor 12 0x2c} {truecolor 12 0x2d} {truecolor 24 0x2e} {trueco lor 24 0x2f} {directcolor 24 0x30} {truecolor 24 0x31}' >>> print root.winfo_visualsavailable( includeids=1 ) Traceback (innermost last): File "", line 1, in ? File "/home/rhh/software/python-1.5.2/lib/python1.5/lib-tk/Tkinter.py", line 4 28, in winfo_visualsavailable return map(parseitem, data) File "/home/rhh/software/python-1.5.2/lib/python1.5/lib-tk/Tkinter.py", line 4 27, in parseitem return x[:1] + tuple(map(getint, x[1:])) ValueError: invalid literal for int(): 0x20 From aa8vb@yahoo.com Thu Oct 14 17:00:03 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Thu, 14 Oct 1999 12:00:03 -0400 (EDT) Subject: [Python-bugs-list] Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) Message-ID: <199910141600.MAA06813@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5.5f Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) In Tcl/Tk you can say: wm colormapwindows . {.frame.label .frame} In Tkinter, one would think you could use: main.wm_colormapwindows( [ label, frame ] ) but this results in an error: TclError: wrong # arguments: must be "wm colormapwindows window ?windowList?" this is what is sent to Tk: ('wm', 'colormapwindows', '.269680944', , ) As a workaround, the following works (or at least Tk doesn't complain about it) but is obviously a hack: main.tk.call( "wm", "colormapwindows", main._w, '%s %s' % ( canvas._w, frame._w ) ) From clarence@netlojix.com Thu Oct 14 18:21:38 1999 From: clarence@netlojix.com (clarence@netlojix.com) Date: Thu, 14 Oct 1999 13:21:38 -0400 (EDT) Subject: [Python-bugs-list] socket left in FIN_WAIT_2 state (PR#108) Message-ID: <199910141721.NAA08977@python.org> Full_Name: Clarence Gardner Version: 1.5.2 OS: Linux Submission from: cache3.avtel.net (207.71.192.251) Using the SocketServer.TCPServer class, the request socket is being left in FIN_WAIT_2 state. Adding request.close() to the end of handle_request fixes it. I would guess this is actually a deficiency in the __del__ method of the socket object. From curt@journyx.com Thu Oct 14 20:49:04 1999 From: curt@journyx.com (curt@journyx.com) Date: Thu, 14 Oct 1999 15:49:04 -0400 (EDT) Subject: [Python-bugs-list] Re: Date problem unresolved [DIN 2646] (fwd) (PR#109) Message-ID: <199910141949.PAA13500@python.org> anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo To: "Stappert, Andreas" Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd /jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > From ratman@nmt.edu Sat Oct 16 02:54:46 1999 From: ratman@nmt.edu (ratman@nmt.edu) Date: Fri, 15 Oct 1999 21:54:46 -0400 (EDT) Subject: [Python-bugs-list] base64 bug (PR#110) Message-ID: <199910160154.VAA28358@python.org> Full_Name: Jason Trowbridge Version: 1.5.2 OS: Linux Submission from: fenris.tcct.nmt.edu (129.138.3.169) Under Linux, the base64 decoding functions generate a SystemError exception for returning an error without setting the exception. base64.decode() actually seems to work just find, as the output file contains the decoded version of the input file. base64.decodestring() doesn't return anything (probably due to the error indication?). This problem is not present under Python 1.5.2 for Windows. It is present on two different linux systems, both my personal computer and the computers at the campus computer center. With both systems, the python source code was downloaded, compiled, and installed in /usr/local. The encoded test strings listed below are "Hello\n". They were created by: echo "Hello" | uuencode -m - Python 1.5.2 (#2, Oct 4 1999, 23:40:04) [GCC egcs-2.91.66 19990314/Linux (egc\s- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import base64 >>> import StringIO >>> encoded = StringIO.StringIO('SGVsbG8K\n====') >>> decoded = StringIO.StringIO() >>> base64.decode(encoded, decoded) Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.5/base64.py", line 33, in decode output.write(s) File "/usr/local/lib/python1.5/StringIO.py", line 102, in write if not s: return SystemError: error return without exception set >>> decoded.getvalue() 'Hello\012' Python 1.5.2 (#2, Oct 4 1999, 23:40:04) [GCC egcs-2.91.66 19990314/Linux (egc\s- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import base64 >>> s = 'SGVsbG8K\n====' >>> base64.decodestring(s) Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.5/base64.py", line 46, in decodestring decode(f, g) File "/usr/local/lib/python1.5/base64.py", line 33, in decode output.write(s) File "/usr/local/lib/python1.5/StringIO.py", line 102, in write if not s: return SystemError: error return without exception set From anton@lifix.fi Mon Oct 18 14:54:36 1999 From: anton@lifix.fi (anton@lifix.fi) Date: Mon, 18 Oct 1999 09:54:36 -0400 (EDT) Subject: [Python-bugs-list] fileinput in-place editing mangles permissions (PR#111) Message-ID: <199910181354.JAA16799@python.org> Full_Name: Anton Gyllenberg Version: 1.5.2 OS: Debian GNU/Linux 2.2 (potato) Submission from: proxy2.clinet.fi (194.100.0.205) When using the fileinput modules in-place editing facility, the original file is moved to a temporary filename, and the output is directed to a new file with the same name as the original. However, the permissions on the new file are not set. This can cause serious security problems with secret files becoming readable after editing. A second not so serious problem is when no backup suffix is specified. Then the default suffix of `.bak' is assumed. If you for some reason already have a `filename.bak', that file will mysteriously disappear. This can be fixed using real tempfiles as in the tempfile module. I am not a experienced python programmer, and I may very well have overlooked something. However, I believe that something like this patch will fix the more serious permission problem: --- /usr/lib/python1.5/fileinput.py Fri Jul 16 20:04:25 1999 +++ fileinput.py Sun Oct 17 20:48:22 1999 @@ -74,6 +74,7 @@ """ import sys, os +from stat import ST_MODE _state = None @@ -207,6 +208,8 @@ os.rename(self._filename, self._backupfilename) self._file = open(self._backupfilename, "r") self._output = open(self._filename, "w") + os.chmod(self._filename, + os.stat(self._backupfilename)[ST_MODE]) self._savestdout = sys.stdout sys.stdout = self._output else: -- Anton Gyllenberg +358-50-3412792 I hope this is unnecessary, but...: 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 bwarsaw@cnri.reston.va.us Mon Oct 18 16:46:09 1999 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Mon, 18 Oct 1999 11:46:09 -0400 (EDT) Subject: [Python-bugs-list] forwarded message from Jason Trowbridge PR#110 Message-ID: <199910181546.LAA20435@python.org> Content-Length: 809 Message: 11 Organization: New Mexico Tech Computer Center Lines: 20 Message-ID: <3808C151.1D877904@nmt.edu> NNTP-Posting-Host: fenris.tcct.nmt.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Date: 16 Oct 1999 18:18:01 GMT Path: news!uunet!ffx.uu.net!news.globix.net!newsfeed.nyu.edu!newsfeed.berkeley.edu!awabi.library.ucla.edu!204.121.3.5!newshost.lanl.gov!newshost.nmt.edu!not-for-mail Xref: news comp.lang.python:74086 From: Jason Trowbridge To: python-list@python.org Subject: Adding info to Python Buglist Date: Sat, 16 Oct 1999 12:17:54 -0600 X-Digest: Python-list digest, Vol 1 #1026 - 12 msgs Newsgroups: comp.lang.python I filed a bug in Python's buglist, and have further information available. However, I can't seem to add a reply as a guest. Is there any way I can add more information to the ticket as a guest, or do I have to get an account? If I need an account, how do I go about getting it? Anyway, below is the additional information that needs to go into bug #110. ----- Seems like it's the '====' which is generating the problem. According to a relevant RFC that I just found (rfc1521, section 5.2), '====' is not a valid set of characters in a base64 encoded string. It is the ending marker than uu(de/en)code uses to detect the end of the file (oops). Still, binascii ought to generate an intelligent exception rather than doing a SystemError. I should have a fix in a bit. Jason Trowbridge ratman@nmt.edu From rhoward@ontrack.com Mon Oct 18 19:22:49 1999 From: rhoward@ontrack.com (rhoward@ontrack.com) Date: Mon, 18 Oct 1999 14:22:49 -0400 (EDT) Subject: [Python-bugs-list] Bug in regular expression matcher (PR#112) Message-ID: <199910181822.OAA26242@python.org> Full_Name: Rick Howard Version: 1.5.2 OS: Windows NT Submission from: (NULL) (204.227.11.109) When using the re: \(\([a-zA-Z]:\)?\([\][a-zA-Z0-9 $%'\_@~`!()^#&+,;=[-]+\)+\)?[a-zA-Z0-9 $%'\_@~`!()^#&+,;=[-]+\.[dD][lL][lL] The re matcher goes into an infinite loop on this input: \XXX\X\X\\\\\X\\\XXXX\X\X\\\\\X\\\\X\\\XXX\\\\\\\kX Rick Howard Ontrack Data International From rhoward@ontrack.com Mon Oct 18 22:41:21 1999 From: rhoward@ontrack.com (rhoward@ontrack.com) Date: Mon, 18 Oct 1999 17:41:21 -0400 (EDT) Subject: [Python-bugs-list] RE: Bug in regular expression matcher (PR#112) Message-ID: <199910182141.RAA02636@python.org> Thank You both for responding. The problem is, indeed, the RE that I am using. I discovered the problem shortly after reporting the "bug." Because parts of the RE are pasted together to from a full RE, I didn't realize that the problem was in one of the "component" expressions, since they are stored in a separate file. I apologize for jumping the gun on this and posting it as a bug. Rick Howard Ontrack Data International > -----Original Message----- > From: Guido van Rossum [mailto:bugs-py@python.org] > Sent: Monday, October 18, 1999 3:22 PM > To: rhoward@ontrack.com > Subject: Re: Bug in regular expression matcher (PR#112) > > > According to Andrew Kuchling, this is a bug in the regular expression. > He had to infer some more information -- in particular, you seem to > be using the regex module, not the re module. > > Here is his email: > > Guido van Rossum writes: > >When using the re: > >\(\([a-zA-Z]:\)?\([\][a-zA-Z0-9 $%'\_@~`!()^#&+,;=[-]+\)+\)? > >[a-zA-Z0-9$%'\_@~`!()^#&+,;=[-]+\.[dD][lL][lL] > >The re matcher goes into an infinite loop on this input: > >\XXX\X\X\\\\\X\\\XXXX\X\X\\\\\X\\\\X\\\XXX\\\\\\\kX > > From the use of \( \), I'd assume this applies to the regex module, > not the re module. If you chop off the part of the pattern I've put > on line 2, you find that the first part always matches the whole > string. This stems from an error in the pattern: [\] should be [\\]. > That bit of the pattern is intended to match \ followed by a chunk of > characters, but because of the error, the ] is escaped and the whole > thing is treated as the character set ][a-zA-Z0-9 $%'\_@~`!()^#&+,;=[- > , followed by a +, followed by a +. (The \_ is also odd, because you > don't need to escape the _; I suspect that should be \\_. Even better > would be [^\\]+, which is *much* shorter.) This produces a > combinatoric explosion, as every possible combination of groupings is > tried, but all fail. > > Translating to re's syntax and writing the pattern > with re.VERBOSE, you get: > > pat = re.compile(r""" > > ([a-zA-Z]:)? # Match a drive letter > ([\\][a-zA-Z0-9 $%'\_@~`!()^#&+,;=[-]+)+ # Match any number of > directories > )? > # Match a filename ending in .dll > [a-zA-Z0-9$%'_@~`!()^#&+,;=[-]+ \. [dD][lL][lL]""", re.VERBOSE) > > Note that this pattern seems to be trying to match filenames ending in > .dll; it would be much easier to do "path,filename = > os.path.split(filename) ; if string.lower(filename[-4:]) == '.dll': > ...". > From guido@CNRI.Reston.VA.US Mon Oct 18 23:23:10 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 18 Oct 1999 18:23:10 -0400 (EDT) Subject: [Python-bugs-list] forwarded message from Jason Trowbridge PR#110 Message-ID: <199910182223.SAA03918@python.org> > I filed a bug in Python's buglist, and have further information > available. However, I can't seem to add a reply as a guest. Is there > any way I can add more information to the ticket as a guest, or do I > have to get an account? If I need an account, how do I go about getting > it? You can select the "private interface" from the sidebar on http://www.python.org/search/search_bugs.html The username is bugs-py, the password is bruce. You can then select "bwarsaw" from the list of users. (Or did you just figure this out already?) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Oct 18 23:23:05 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 18 Oct 1999 18:23:05 -0400 Subject: [Python-bugs-list] forwarded message from Jason Trowbridge PR#110 In-Reply-To: Your message of "Mon, 18 Oct 1999 11:46:09 EDT." <199910181546.LAA20435@python.org> References: <199910181546.LAA20435@python.org> Message-ID: <199910182223.SAA23800@eric.cnri.reston.va.us> > I filed a bug in Python's buglist, and have further information > available. However, I can't seem to add a reply as a guest. Is there > any way I can add more information to the ticket as a guest, or do I > have to get an account? If I need an account, how do I go about getting > it? You can select the "private interface" from the sidebar on http://www.python.org/search/search_bugs.html The username is bugs-py, the password is bruce. You can then select "bwarsaw" from the list of users. (Or did you just figure this out already?) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Oct 18 23:31:14 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 18 Oct 1999 18:31:14 -0400 Subject: [Python-bugs-list] forwarded message from Jason Trowbridge PR#110 In-Reply-To: Your message of "Mon, 18 Oct 1999 11:46:09 EDT." <199910181546.LAA20435@python.org> References: <199910181546.LAA20435@python.org> Message-ID: <199910182231.SAA23833@eric.cnri.reston.va.us> Obviously, I didn't intend to recommend to log in as bwarsaw. I mistakenly assumed that it was Barry who was asking the question. In case anyone wonders what the correct procedure is for a non-privileged person to add a reply, the answer is to simply send email with the same subject but with (PR#XXX) appended to the subject. --Guido van Rossum (home page: http://www.python.org/~guido/) From clarence@netlojix.com Tue Oct 19 00:06:26 1999 From: clarence@netlojix.com (clarence@netlojix.com) Date: Mon, 18 Oct 1999 19:06:26 -0400 (EDT) Subject: [Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108) Message-ID: <199910182306.TAA05880@python.org> > > > Using the SocketServer.TCPServer class, the request socket is > > being left in FIN_WAIT_2 state. Adding > > request.close() > > to the end of handle_request fixes it. I would guess this is > > actually a deficiency in the __del__ method of the socket object. > > Can you show a small sample program that exhibits this problem? > (How do I see that a socket is left in FIN_WAIT_2 state???) > > If the problem persists after the Python process has exited, > I would surmise that the problem is in the kernel -- sockets > are supposed to be closed when the process exits, aren't they? > > --Guido van Rossum > Hard to show code, but here's a description: >>> from socket import * >>> s=socket(AF_INET,SOCK_STREAM) >>> s.bind('',2001) >>> s.listen(5) >>> x=s.accept() The connection is established. The client now closes his end. This puts the server-side socket in FIN_WAIT2 state (this is normal). >>> del x This has no effect on the socket state. >>> x=s.accept() Establish another connection, and close the client side. Again, the socket goes to FIN_WAIT2. >>> x[0].close() This leaves the socket in normal TIME_WAIT state, the state of a closed connection. It is true that the kernel will close all of the file descriptors when the process exits, but sockets are special because of the TCP protocol, and if they are not closed by the user program, they do not go through the normal shutdown process. While sockets in FIN_WAIT2 don't hurt the system (they'll go away eventually), the reason I thought this is a library problem is that it seems to me that since the SocketServer code 'created' the socket -- via the accept() -- it should probably close it also when the connection handler returns. I imagine there's room for conflicting opinions there, but that seems normal to me. It is not mentioned in the documentation whether the handler has the reponsibility of closing the connection. I mentioned the __del__ method because it seems that a reclaimed open socket should have close() applied to it like a function does. I see PySocketSock_dealloc() in socketmodule.c, which I would have thought is the deletion function, does call close(); that should make the above two cases the same (unless that's not the deletion function). But somehow the explicit Python-level close() call is causing a normal shutdown. From guido@CNRI.Reston.VA.US Tue Oct 19 06:01:45 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 19 Oct 1999 01:01:45 -0400 Subject: [Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108) In-Reply-To: Your message of "Mon, 18 Oct 1999 19:06:26 EDT." <199910182306.TAA05880@python.org> References: <199910182306.TAA05880@python.org> Message-ID: <199910190501.BAA24917@eric.cnri.reston.va.us> > > > Using the SocketServer.TCPServer class, the request socket is > > > being left in FIN_WAIT_2 state. Adding > > > request.close() > > > to the end of handle_request fixes it. I would guess this is > > > actually a deficiency in the __del__ method of the socket object. > > > > Can you show a small sample program that exhibits this problem? > > (How do I see that a socket is left in FIN_WAIT_2 state???) > > > > If the problem persists after the Python process has exited, > > I would surmise that the problem is in the kernel -- sockets > > are supposed to be closed when the process exits, aren't they? > > Hard to show code, but here's a description: > >>> from socket import * > >>> s=socket(AF_INET,SOCK_STREAM) > >>> s.bind('',2001) > >>> s.listen(5) > >>> x=s.accept() > The connection is established. The client now closes his end. > This puts the server-side socket in FIN_WAIT2 state (this is normal). > >>> del x > This has no effect on the socket state. > > >>> x=s.accept() > Establish another connection, and close the client side. Again, > the socket goes to FIN_WAIT2. > >>> x[0].close() > This leaves the socket in normal TIME_WAIT state, the state of a > closed connection. I tried to reproduce this, and didn't succeed. The socket is left in TIME_WAIT state the first time too. My guess is that you are being fooled by reference counts and the "_" variable with this example. If you typed x at the >>> prompt just before you did "del x", the _ builtin variable holds a reference to the object. This goes away when you display the value of some other value (e.g. 0, but not None). > It is true that the kernel will close all of the file descriptors when the > process exits, but sockets are special because of the TCP protocol, and if > they are not closed by the user program, they do not go through the > normal shutdown process. > > While sockets in FIN_WAIT2 don't hurt the system (they'll go away eventually), > the reason I thought this is a library problem is that it seems to me that > since the SocketServer code 'created' the socket -- via the accept() -- > it should probably close it also when the connection handler returns. I > imagine there's room for conflicting opinions there, but that seems normal > to me. It is not mentioned in the documentation whether the handler has > the reponsibility of closing the connection. > > I mentioned the __del__ method because it seems that a reclaimed open > socket should have close() applied to it like a function does. I > see PySocketSock_dealloc() in socketmodule.c, which I would have thought > is the deletion function, does call close(); that should make the above > two cases the same (unless that's not the deletion function). But somehow > the explicit Python-level close() call is causing a normal shutdown. That is indeed the correct function. The question now remains, why do you observe this behavior in SocketServer? I still want to see the code you are actually using -- maybe there's a clue there. If not, I'll have to close this PR as irreproducible... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Tue Oct 19 06:01:55 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 19 Oct 1999 01:01:55 -0400 (EDT) Subject: [Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108) Message-ID: <199910190501.BAA13745@python.org> > > > Using the SocketServer.TCPServer class, the request socket is > > > being left in FIN_WAIT_2 state. Adding > > > request.close() > > > to the end of handle_request fixes it. I would guess this is > > > actually a deficiency in the __del__ method of the socket object. > > > > Can you show a small sample program that exhibits this problem? > > (How do I see that a socket is left in FIN_WAIT_2 state???) > > > > If the problem persists after the Python process has exited, > > I would surmise that the problem is in the kernel -- sockets > > are supposed to be closed when the process exits, aren't they? > > Hard to show code, but here's a description: > >>> from socket import * > >>> s=socket(AF_INET,SOCK_STREAM) > >>> s.bind('',2001) > >>> s.listen(5) > >>> x=s.accept() > The connection is established. The client now closes his end. > This puts the server-side socket in FIN_WAIT2 state (this is normal). > >>> del x > This has no effect on the socket state. > > >>> x=s.accept() > Establish another connection, and close the client side. Again, > the socket goes to FIN_WAIT2. > >>> x[0].close() > This leaves the socket in normal TIME_WAIT state, the state of a > closed connection. I tried to reproduce this, and didn't succeed. The socket is left in TIME_WAIT state the first time too. My guess is that you are being fooled by reference counts and the "_" variable with this example. If you typed x at the >>> prompt just before you did "del x", the _ builtin variable holds a reference to the object. This goes away when you display the value of some other value (e.g. 0, but not None). > It is true that the kernel will close all of the file descriptors when the > process exits, but sockets are special because of the TCP protocol, and if > they are not closed by the user program, they do not go through the > normal shutdown process. > > While sockets in FIN_WAIT2 don't hurt the system (they'll go away eventually), > the reason I thought this is a library problem is that it seems to me that > since the SocketServer code 'created' the socket -- via the accept() -- > it should probably close it also when the connection handler returns. I > imagine there's room for conflicting opinions there, but that seems normal > to me. It is not mentioned in the documentation whether the handler has > the reponsibility of closing the connection. > > I mentioned the __del__ method because it seems that a reclaimed open > socket should have close() applied to it like a function does. I > see PySocketSock_dealloc() in socketmodule.c, which I would have thought > is the deletion function, does call close(); that should make the above > two cases the same (unless that's not the deletion function). But somehow > the explicit Python-level close() call is causing a normal shutdown. That is indeed the correct function. The question now remains, why do you observe this behavior in SocketServer? I still want to see the code you are actually using -- maybe there's a clue there. If not, I'll have to close this PR as irreproducible... --Guido van Rossum (home page: http://www.python.org/~guido/) From ratman@nmt.edu Tue Oct 19 06:18:45 1999 From: ratman@nmt.edu (ratman@nmt.edu) Date: Tue, 19 Oct 1999 01:18:45 -0400 (EDT) Subject: [Python-bugs-list] PR#110 Message-ID: <199910190518.BAA14943@python.org> This is a multi-part message in MIME format. --------------7C60C9A4553E11C29CE94EE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Uhm, I just got a notice that you fixed the problem. However, looking at the CVS tree, it looks like you added: /* and remove any padding */ bin_len -= npad; if (bin_len < 0) bin_len = 0; This may fix the symptom, but it doesn't fix the underlying problems: Sets of 4 pad sequences will cause the loss of encoded data, ie: 'SGVsbG8K' decoded is 'Hello\n' 'SGVsbG8K====' decoded is 'Hello' Illegal pad sequences can appear anywhere: 'a=aaa' decodes to 'h\006', but is actually nonsense, according to the specification. Characters >chr(127) are remapped to the lower 127 ASCII set (by masking with 0x7f) instead of being ignored: 'aaaa' and 'aaa\xe1' both decode to 'i\246\232', but the second form should ignore the '\xe1' and raise an Incorrect padding. The patch included with this message ought to make binascii's base64 decoding routine RFC 2045 compliant. Please see section 6.8 at "http://www.faqs.org/rfcs/rfc2045.html" for details on what RFC 2045 is. The problems that I fixed with binascii are: -- Illegal padding now generates an exception. (binascii.Error: Invalid pad sequence) -- Padding now indicates EOI (as per RFC) Previously, padding could be used anywhere in input, violating the RFC. -- Padding no longer removes characters from data string (resulting in lost data/strings with negative lengths). -- Illegal characters now ignored, instead of possibly being remapped to a valid character. Base64 decoding should (hopefully!) be RFC 2045 compliant with this patch! If you can, let me know any problems you find in the patch. Here's how to apply the patch in this message: 1) Go into your Python source directory & go into the Modules/ directory. 2) Make sure you have an unmodified Python 1.5.2 binascii.c file. 3) Type: patch -N binascii.c binascii.patch Anyway, I just want to say that I love using Python (my favorite language for 3 years now!). This is the first time that I've actually had the chance to help advance an open-source style project, and I hope that I've done things right. Thanks! Jason Trowbridge ratman@nmt.edu --------------7C60C9A4553E11C29CE94EE1 Content-Type: application/octet-stream; name="binascii.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="binascii.patch" LS0tIG9sZGVyL01vZHVsZXMvYmluYXNjaWkuYwlTYXQgT2N0IDE2IDE4OjQ0OjIxIDE5OTkK KysrIG5ld2VzdC9Nb2R1bGVzL2JpbmFzY2lpLmMJTW9uIE9jdCAxOCAxNTo1MzoxNCAxOTk5 CkBAIC03NSw2ICs3NSwyMSBAQAogKiogSmFjayBKYW5zZW4sIENXSSwgSnVseSAxOTk1Lgog Ki8KIAorLyogIENvdXBsZSBvZiBidWcgZml4ZXMgaW4gdGhlIGJpbmFzY2lpX2EyYl9iYXNl NjQoKToKKyAqICAgIC0tIElsbGVnYWwgcGFkZGluZyBub3cgZ2VuZXJhdGVzIGV4Y2VwdGlv bnMgCisgKiAgICAtLSBQYWRkaW5nIG5vdyBpbmRpY2F0ZXMgRU9JIChhcyBwZXIgUkZDKQor ICogICAgLS0gUGFkZGluZyBubyBsb25nZXIgcmVtb3ZlcyBjaGFyYWN0ZXJzIGZyb20KKyAq ICAgICAgIGRhdGEgc3RyaW5nIChyZXN1bHRpbmcgaW4gbG9zdCBkYXRhL3N0cmluZ3MKKyAq ICAgICAgIHdpdGggbmVnYXRpdmUgbGVuZ3RocykKKyAqICAgIC0tIElsbGVnYWwgY2hhcmFj dGVycyBub3cgaWdub3JlZCwgaW5zdGVhZCBvZiAKKyAqICAgICAgIHBvc3NpYmx5IGJlaW5n IHJlbWFwcGVkIHRvIGEgdmFsaWQgY2hhcmFjdGVyCisgKiAgICAtLSBCYXNlNjQgZGVjb2Rp bmcgaXMgbm93IFJGQyAyMDQ1IGNvbXBsaWFudCAoaG9wZWZ1bGx5ISkKKyAqCisgKiAgVGhh bmtzIHRvIEhydm9qZSBOaWtzaWMgdG8gcG9pbnRpbmcgbWUgdG8gYSBtdWNoCisgKiAgbW9y ZSB1cC10by1kYXRlIFJGQyB0aGFuIEkgd2FzIG9yaWdpbmFsbHkgdXNpbmcuCisgKiAKKyAq ICAtLUphc29uIFRyb3dicmlkZ2UgKHJhdG1hbkBubXQuZWR1KQorICovCiAKICNpbmNsdWRl ICJQeXRob24uaCIKIApAQCAtMzI4LDYgKzM0MywzMCBAQAogCXJldHVybiBydjsKIH0KIAor CitpbnQgYmluYXNjaWlfZmluZF92YWxpZCggY2hhciAqcywgaW50IHNsZW4sIGludCBudW0g KQoreworCS8qIEZpbmRzICYgcmV0dXJucyB0aGUgKG51bSsxKXRoIAorCSoqIHZhbGlkIGNo YXJhY3RlciBmb3IgYmFzZTY0LCBvciAtMSBpZiBub25lLiAqLworCisJaW50IHJldCA9IC0x OworCXVuc2lnbmVkIGNoYXIgYywgYjY0dmFsOworCisJd2hpbGUgKChzbGVuID4gMCkgJiYg KHJldCA9PSAtMSkpIHsKKwkJYyA9ICpzOworCQliNjR2YWwgPSB0YWJsZV9hMmJfYmFzZTY0 W2MgJiAweDdmXTsKKwkJaWYgKCAoKGMgPD0gMHg3ZikgJiYgKGI2NHZhbCAhPSAodW5zaWdu ZWQgY2hhciktMSkpICkgeworCQkJaWYgKG51bSA9PSAwKQorCQkJCXJldCA9ICpzOworCQkJ bnVtLS07CisJCX0KKworCQlzKys7CisJCXNsZW4tLTsKKwl9CisJcmV0dXJuIHJldDsKK30K Kwogc3RhdGljIGNoYXIgZG9jX2EyYl9iYXNlNjRbXSA9ICIoYXNjaWkpIC0+IGJpbi4gRGVj b2RlIGEgbGluZSBvZiBiYXNlNjQgZGF0YSI7CiAKIHN0YXRpYyBQeU9iamVjdCAqCkBAIC0z MzksOSArMzc4LDkgQEAKIAlpbnQgbGVmdGJpdHMgPSAwOwogCXVuc2lnbmVkIGNoYXIgdGhp c19jaDsKIAl1bnNpZ25lZCBpbnQgbGVmdGNoYXIgPSAwOwotCWludCBucGFkID0gMDsKIAlQ eU9iamVjdCAqcnY7CiAJaW50IGFzY2lpX2xlbiwgYmluX2xlbjsKKwlpbnQgcXVhZF9wb3Mg PSAwOwogCQogCWlmICggIVB5QXJnX1BhcnNlVHVwbGUoYXJncywgInQjIiwgJmFzY2lpX2Rh dGEsICZhc2NpaV9sZW4pICkKIAkJcmV0dXJuIE5VTEw7CkBAIC0zNTMsMzcgKzM5Miw2MCBA QAogCQlyZXR1cm4gTlVMTDsKIAliaW5fZGF0YSA9ICh1bnNpZ25lZCBjaGFyICopUHlTdHJp bmdfQXNTdHJpbmcocnYpOwogCWJpbl9sZW4gPSAwOwotCWZvciggOyBhc2NpaV9sZW4gPiAw IDsgYXNjaWlfbGVuLS0sIGFzY2lpX2RhdGErKyApIHsKLQkJLyogU2tpcCBzb21lIHB1bmN0 dWF0aW9uICovCi0JCXRoaXNfY2ggPSAoKmFzY2lpX2RhdGEgJiAweDdmKTsKLQkJaWYgKCB0 aGlzX2NoID09ICdccicgfHwgdGhpc19jaCA9PSAnXG4nIHx8IHRoaXNfY2ggPT0gJyAnICkK KworCWZvciggOyBhc2NpaV9sZW4gPiAwOyBhc2NpaV9sZW4tLSwgYXNjaWlfZGF0YSsrKSB7 CisJCXRoaXNfY2ggPSAqYXNjaWlfZGF0YTsKKworCQlpZiAodGhpc19jaCA+IDB4N2YgfHwg dGhpc19jaCA9PSAnXHInIHx8IHRoaXNfY2ggPT0gJ1xuJyB8fCB0aGlzX2NoID09ICcgJykK KwkJCWNvbnRpbnVlOworCisJCS8qIENoZWNrIGZvciBwYWQgc2VxdWVuY2VzLgorCQkqKiBJ bnZhbGlkIHBhZCBzZXF1ZW5jZXMgbmVlZCB0byBnZW5lcmF0ZSBhbiBleGNlcHRpb24uCisJ CSoqIFZhbGlkIHBhZCBzZXF1ZW5jZXMgaW5kaWNhdGUgdGhlIGVuZCBvZiB0aGUgYmFzZTY0 CisJCSoqIGlucHV0LgorCQkqLworCQlpZiAodGhpc19jaCA9PSBCQVNFNjRfUEFEKSB7ICAv KiBFeGNlcHRpb24gb24gaW52YWxpZCBwYWQgc2VxdWVuY2VzICovCisJCQlpZiAoIChxdWFk X3BvcyA8IDIpIHx8ICgocXVhZF9wb3MgPT0gMikgJiYgCisJCQkJCQkJCQkJCQkJCQkoYmlu YXNjaWlfZmluZF92YWxpZChhc2NpaV9kYXRhLCBhc2NpaV9sZW4sIDEpICE9IEJBU0U2NF9Q QUQpKSApIHsKKwkJCQlQeUVycl9TZXRTdHJpbmcoRXJyb3IsICJJbnZhbGlkIHBhZCBzZXF1 ZW5jZSIpOworCQkJCVB5X0RFQ1JFRihydik7CisJCQkJcmV0dXJuIE5VTEw7CisKKwkJCX0g ZWxzZSB7CisJCQkJLyogQSBwYWQgc2VxdWVuY2UgbWVhbnMgbm8gbW9yZSBpbnB1dC4gIFdl J3ZlIGFscmVhZHkgaW50ZXJwcmV0ZWQKKwkJCQkqKiB0aGUgZGF0YSBmcm9tIHRoZSBxdWFk IGF0IHRoaXMgcG9pbnQuCisJCQkJKi8KKwkJCQlsZWZ0Yml0cyA9IDA7CisJCQkJYnJlYWs7 CisJCQl9CisJCX0KKworCQl0aGlzX2NoID0gdGFibGVfYTJiX2Jhc2U2NFsqYXNjaWlfZGF0 YV07CisJCWlmICggdGhpc19jaCA9PSAodW5zaWduZWQgY2hhcikgLTEgKQogCQkJY29udGlu dWU7Ci0JCQotCQlpZiAoIHRoaXNfY2ggPT0gQkFTRTY0X1BBRCApCi0JCQlucGFkKys7Ci0J CXRoaXNfY2ggPSB0YWJsZV9hMmJfYmFzZTY0WygqYXNjaWlfZGF0YSkgJiAweDdmXTsKLQkJ aWYgKCB0aGlzX2NoID09ICh1bnNpZ25lZCBjaGFyKSAtMSApIGNvbnRpbnVlOworCiAJCS8q CiAJCSoqIFNoaWZ0IGl0IGluIG9uIHRoZSBsb3cgZW5kLCBhbmQgc2VlIGlmIHRoZXJlJ3MK IAkJKiogYSBieXRlIHJlYWR5IGZvciBvdXRwdXQuCiAJCSovCisJCXF1YWRfcG9zID0gKHF1 YWRfcG9zICsgMSkgJiAweDAzOwogCQlsZWZ0Y2hhciA9IChsZWZ0Y2hhciA8PCA2KSB8ICh0 aGlzX2NoKTsKIAkJbGVmdGJpdHMgKz0gNjsKKwogCQlpZiAoIGxlZnRiaXRzID49IDggKSB7 CiAJCQlsZWZ0Yml0cyAtPSA4OwogCQkJKmJpbl9kYXRhKysgPSAobGVmdGNoYXIgPj4gbGVm dGJpdHMpICYgMHhmZjsKLQkJCWxlZnRjaGFyICY9ICgoMSA8PCBsZWZ0Yml0cykgLSAxKTsK IAkJCWJpbl9sZW4rKzsKKwkJCWxlZnRjaGFyICY9ICgoMSA8PCBsZWZ0Yml0cykgLSAxKTsK IAkJfQotCX0KLQkvKiBDaGVjayB0aGF0IG5vIGJpdHMgYXJlIGxlZnQgKi8KLQlpZiAoIGxl ZnRiaXRzICkgeworIAl9CisKKwlpZiAobGVmdGJpdHMgIT0gMCkgewogCQlQeUVycl9TZXRT dHJpbmcoRXJyb3IsICJJbmNvcnJlY3QgcGFkZGluZyIpOwogCQlQeV9ERUNSRUYocnYpOwog CQlyZXR1cm4gTlVMTDsKIAl9Ci0JLyogYW5kIHJlbW92ZSBhbnkgcGFkZGluZyAqLwotCWJp bl9sZW4gLT0gbnBhZDsKKwogCS8qIGFuZCBzZXQgc3RyaW5nIHNpemUgY29ycmVjdGx5ICov CiAJX1B5U3RyaW5nX1Jlc2l6ZSgmcnYsIGJpbl9sZW4pOwogCXJldHVybiBydjsK --------------7C60C9A4553E11C29CE94EE1-- From anton@mymlan.lifix.fi Tue Oct 19 09:09:22 1999 From: anton@mymlan.lifix.fi (anton@mymlan.lifix.fi) Date: Tue, 19 Oct 1999 04:09:22 -0400 (EDT) Subject: [Python-bugs-list] Re: fileinput in-place editing mangles permissions (PR#111) Message-ID: <199910190809.EAA22543@python.org> > Thanks -- I've fixed this slightly differently (creating the file with > the proper mode so as to avoid a timing window during which an attacker > could open the file). Yes, that's the way to do it. Regards -- Anton Gyllenberg From aa8vb@yahoo.com Tue Oct 19 13:04:54 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Tue, 19 Oct 1999 08:04:54 -0400 (EDT) Subject: [Python-bugs-list] Re: Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) Message-ID: <199910191204.IAA26749@python.org> Guido van Rossum: |Randall Hopper: |> In Tcl/Tk you can say: |> |> wm colormapwindows . {.frame.label .frame} |> |> In Tkinter, one would think you could use: |> |> |> but this results in an error: |> |> TclError: wrong # arguments: must be "wm colormapwindows window |> ?windowList?" |> |> this is what is sent to Tk: |> ('wm', 'colormapwindows', '.269680944', |> , |> ) |> |> As a workaround, the following works (or at least Tk doesn't complain |> about it) but is obviously a hack: |> |> main.tk.call( "wm", "colormapwindows", main._w, |> '%s %s' % ( canvas._w, frame._w ) ) | |The Python function doesn't require you to put the windows in a list. |Instead, it takes any number of windows as separate arguments. |This should work: | | main.wm_colormapwindows(label, frame) On Python 1.52, this yields: ------------------------------------------------------------------------------ Traceback (innermost last): File "./3-tk_win.py", line 106, in ? main.wm_colormapwindows( label, frame ) File "/home/rhh/software/IRIX-o32/python-1.5.2/lib/python1.5/lib-tk/Tkinter.py", line 785, in wm_colormapwindows return map(self._nametowidget, self.tk.call(args)) TclError: wrong # arguments: must be "wm colormapwindows window ?windowList?" ------------------------------------------------------------------------------ I inserted a print of args into wm_colormapwindows: ------------------------------------------------------------------------------ def wm_colormapwindows(self, *wlist): args = ('wm', 'colormapwindows', self._w) + _flatten(wlist) -> print args return map(self._nametowidget, self.tk.call(args)) ------------------------------------------------------------------------------ and this is what is being passed to self.tk.call: ------------------------------------------------------------------------------ ('wm', 'colormapwindows', '.', , ) ------------------------------------------------------------------------------ From first glance, it appears there may be two problems: 1) the Tkinter objects aren't being translated to Tk widget names (label._w, frame._w), and 2) The window list isn't being passed to Tk as a Tk list (i.e. one arg to tk.call) Together, I believe this is why the following raw Tk call doesn't complain: ------------------------------------------------------------------------------ |> main.tk.call( "wm", "colormapwindows", main._w, |> '%s %s' % ( label._w, frame._w ) ) ------------------------------------------------------------------------------ Thanks, Randall From guido@CNRI.Reston.VA.US Tue Oct 19 13:57:34 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 19 Oct 1999 08:57:34 -0400 (EDT) Subject: [Python-bugs-list] Re: PR#110 Message-ID: <199910191257.IAA27617@python.org> > Uhm, I just got a notice that you fixed the problem. However, looking > at the CVS tree, it looks like you added: > /* and remove any padding */ > bin_len -= npad; > if (bin_len < 0) > bin_len = 0; > > This may fix the symptom, but it doesn't fix the underlying problems: Your bug report didn't indicate that you had a problem with this. > Sets of 4 pad sequences will cause the loss of encoded data, ie: > 'SGVsbG8K' decoded is 'Hello\n' > 'SGVsbG8K====' decoded is 'Hello' > > Illegal pad sequences can appear anywhere: > 'a=aaa' decodes to 'h\006', but > is actually nonsense, according to the > specification. > > Characters >chr(127) are remapped to the lower 127 ASCII set (by masking > with 0x7f) instead of being ignored: > 'aaaa' and 'aaa\xe1' both decode to 'i\246\232', > but the second form should ignore the '\xe1' and > raise an Incorrect padding. > > The patch included with this message ought to make binascii's base64 > decoding routine RFC 2045 compliant. Please see section 6.8 at > "http://www.faqs.org/rfcs/rfc2045.html" for details on what RFC 2045 is. > > The problems that I fixed with binascii are: > -- Illegal padding now generates an exception. > (binascii.Error: Invalid pad sequence) > > -- Padding now indicates EOI (as per RFC) > Previously, padding could be used anywhere > in input, violating the RFC. > > -- Padding no longer removes characters from > data string (resulting in lost data/strings > with negative lengths). > > -- Illegal characters now ignored, instead of > possibly being remapped to a valid character. > > Base64 decoding should (hopefully!) be RFC 2045 compliant with this > patch! If you can, let me know any problems you find in the patch. I have one reservation: raising an exception for invalid input seems overkill. I'd rather ignore illegal padding (like you are ignoring non-ASCII characters). That way, a garbled file may be recoverable at least partially. The rest of your patch description seems fine. Remember, the general Internet philosophy is "be strict in what you send, but generous in what you accept." (Or words to that effect.) > Here's how to apply the patch in this message: > 1) Go into your Python source directory & go into the Modules/ > directory. > 2) Make sure you have an unmodified Python 1.5.2 binascii.c file. I wish you had made the change relative to the latest CVS version, but this is okay. > 3) Type: patch -N binascii.c binascii.patch > > Anyway, I just want to say that I love using Python (my favorite > language for 3 years now!). This is the first time that I've actually > had the chance to help advance an open-source style project, and I hope > that I've done things right. Thanks! Thanks! I have one request (with pain in my heart): please resend me your patch with, in the body of the message, the disclaimer suggested on this webpage: http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Tue Oct 19 14:12:38 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 19 Oct 1999 09:12:38 -0400 Subject: [Python-bugs-list] Re: Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) In-Reply-To: Your message of "Tue, 19 Oct 1999 08:04:54 EDT." <199910191204.IAA26749@python.org> References: <199910191204.IAA26749@python.org> Message-ID: <199910191312.JAA25126@eric.cnri.reston.va.us> > From first glance, it appears there may be two problems: > > 1) the Tkinter objects aren't being translated to Tk widget names > (label._w, frame._w), and This is actually not a bug -- when you print a tuple, repr() is applied to its items, but the tk.call() method applies str() to the arguments, and the str() of a Tkinter widget returns its _w attribute. Try printing map(str, ...) over the final argument tuple. > 2) The window list isn't being passed to Tk as a Tk list > (i.e. one arg to tk.call) That's the bug. I can't really test it right now, but does the following fix it? *************** *** 783,789 **** return self.tk.call('wm', 'client', self._w, name) client = wm_client def wm_colormapwindows(self, *wlist): ! args = ('wm', 'colormapwindows', self._w) + _flatten(wlist) return map(self._nametowidget, self.tk.call(args)) colormapwindows = wm_colormapwindows def wm_command(self, value=None): --- 783,791 ---- return self.tk.call('wm', 'client', self._w, name) client = wm_client def wm_colormapwindows(self, *wlist): ! if wlist: ! wlist = (wlist,) # Tk needs a list of windows here ! args = ('wm', 'colormapwindows', self._w) + wlist return map(self._nametowidget, self.tk.call(args)) colormapwindows = wm_colormapwindows def wm_command(self, value=None): --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Tue Oct 19 14:12:45 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 19 Oct 1999 09:12:45 -0400 (EDT) Subject: [Python-bugs-list] Re: Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) Message-ID: <199910191312.JAA27892@python.org> > From first glance, it appears there may be two problems: > > 1) the Tkinter objects aren't being translated to Tk widget names > (label._w, frame._w), and This is actually not a bug -- when you print a tuple, repr() is applied to its items, but the tk.call() method applies str() to the arguments, and the str() of a Tkinter widget returns its _w attribute. Try printing map(str, ...) over the final argument tuple. > 2) The window list isn't being passed to Tk as a Tk list > (i.e. one arg to tk.call) That's the bug. I can't really test it right now, but does the following fix it? *************** *** 783,789 **** return self.tk.call('wm', 'client', self._w, name) client = wm_client def wm_colormapwindows(self, *wlist): ! args = ('wm', 'colormapwindows', self._w) + _flatten(wlist) return map(self._nametowidget, self.tk.call(args)) colormapwindows = wm_colormapwindows def wm_command(self, value=None): --- 783,791 ---- return self.tk.call('wm', 'client', self._w, name) client = wm_client def wm_colormapwindows(self, *wlist): ! if wlist: ! wlist = (wlist,) # Tk needs a list of windows here ! args = ('wm', 'colormapwindows', self._w) + wlist return map(self._nametowidget, self.tk.call(args)) colormapwindows = wm_colormapwindows def wm_command(self, value=None): --Guido van Rossum (home page: http://www.python.org/~guido/) From tjs@longford.cs.monash.edu.au Tue Oct 19 14:21:50 1999 From: tjs@longford.cs.monash.edu.au (tjs@longford.cs.monash.edu.au) Date: Tue, 19 Oct 1999 09:21:50 -0400 (EDT) Subject: [Python-bugs-list] python 1.5.2 coredump (repost). (PR#113) Message-ID: <199910191321.JAA28272@python.org> [this is a repost of something I sent last week, which didn't receive any responses. python 1.5.2 coredumps (due to an assertion failure) when running the re module tests, if it is compiled with -DPy_DEBUG] System configuration: Python 1.5.2 (#1, Oct 13 1999, 14:15:09) gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Linux ephedra 2.2.7 #2 Thu May 6 14:10:35 EST 1999 i686 unknown glibc-2.1.1 (Redhat 6.0) Compile: ./configure --prefix=/usr/local/contrib/python-debug --with-threads make OPT='-DPy_DEBUG' [toby@ephedra Python-1.5.2]$ ./python Lib/test/test_re.py Adding parser accelerators ... Done. Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Running re_tests test suite Fatal Python error: UNREF invalid object Aborted (core dumped) This happens with or without --with-threads Stack trace follows: #3 0x8072c43 in Py_FatalError (msg=0x80a027b "UNREF invalid object") at pythonrun.c:1036 #4 0x80524f1 in _Py_ForgetReference (op=0x8125a88) at object.c:658 #5 0x8052534 in _Py_Dealloc (op=0x8125a88) at object.c:680 #6 0x805d729 in eval_code2 (co=0x8139260, globals=0x8135728, locals=0x0, args=0x80f0398, argcount=1, kws=0x80f039c, kwcount=0, defs=0x80da4e4, defcount=1, owner=0x0) at ceval.c:1656 #7 0x805d505 in eval_code2 (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1612 #8 0x805965e in PyEval_EvalCode (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8) at ceval.c:324 #9 0x8072836 in run_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:887 #10 0x80727e5 in run_err_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:872 #11 0x80727af in PyRun_File (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py", start=257, globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:860 #12 0x8071cfa in PyRun_SimpleFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:570 #13 0x807189f in PyRun_AnyFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:451 #14 0x804fb9c in Py_Main (argc=2, argv=0xbffffca4) at main.c:287 #15 0x804f5f0 in main (argc=2, argv=0xbffffca4) at python.c:12 From clarence@netlojix.com Tue Oct 19 18:52:19 1999 From: clarence@netlojix.com (clarence@netlojix.com) Date: Tue, 19 Oct 1999 13:52:19 -0400 (EDT) Subject: [Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108) Message-ID: <199910191752.NAA04884@python.org> > My guess is that you are being fooled by reference counts and the "_" > variable with this example. If you typed x at the >>> prompt just > before you did "del x", the _ builtin variable holds a reference to You are exactly right, I did that. Sorry. > > The question now remains, why do you observe this behavior in > SocketServer? I still want to see the code you are actually using -- > maybe there's a clue there. If not, I'll have to close this PR as > irreproducible... Here is the server code. Your comment about reference counts made me want to mention that I am using StreamRequestHandler, which does a makefile() on the socket, but if I read the code correctly, that doesn't actually share the socket object? (Seems to just dup() the fd and make a wholly distinct object.) I'm hoping I haven't set you on a wild goose chase.... #!/usr/local/bin/python import sys import os import string import SocketServer import urllib import time sys.path.insert(0, '/home/netaid/lib') import NetAid import MySQL db = MySQL.connect('', NetAid.DBAuth[0], NetAid.DBAuth[1]) db.selectdb(NetAid.DBName) import DonateTable DonateTable = DonateTable.DonateTable() import CommentsTable CommentsTable = CommentsTable.CommentsTable() class DBQueryHandler(SocketServer.StreamRequestHandler): def handle(self): try: self.ReadRequest() self.DoQuery() self.SendResults() except: pass def ReadRequest(self): readline = self.rfile.readline strip = string.strip Op = strip(readline()) if Op == 'GET': self.ccnum = strip(readline()) self.ccname = strip(readline()) self.amount = int(strip(readline())) self.DoQuery = self.Fetch self.SendResults = self.SendRecords elif Op == 'REFUND': self.id = strip(readline()) self.ccnum = strip(readline()) self.DoQuery = self.DoRefund self.SendResults = self.OK elif Op == 'COMMENT': self.id = strip(readline()) self.comment = urllib.unquote(strip(readline())) self.DoQuery = self.AddComment self.SendResults = self.OK pass def Fetch(self): where = ''' where cardnumber='%s' and cardname='%s' and amount=%d ''' % (self.ccnum, self.ccname, self.amount) self.recs = DonateTable.ReadAll(db, where) for rec in self.recs: comments = CommentsTable.ReadAll(db, "where donation_id=%d order by timestamp" % rec['id']) c = '' for comment in comments: c = c + ';' + comment['comment'] rec['comments'] = c def SendRecords(self): write = self.wfile.write write('%d\n' % len(self.recs)) for rec in self.recs: write('5\n') write('id:%s\n' % rec['id']) write('status:%s\n'% rec['status']) write('cc:%s\n' % rec['cardnumber'][:8]) write('date:%s\n' % rec['donation_date']) write('comment:%s\n' % rec['comments']) def DoRefund(self): rec = DonateTable.ReadOne(db, {'id':self.id}) if not rec: self.message = '0Invalid record identifier' return if rec['cardnumber'][:8] <> self.ccnum: self.message = '0Record mismatch' return if rec['status'] in 'rR': self.message = '0Refund already requested' return if rec['status'] in 'F': self.message = '0Cannot refund -- charge failed' return if rec['status'] in 'NC': self.message = '0Cannot refund -- charge in progress' return DonateTable.Update(db, {'id':self.id}, {'status':'r'}) self.message = '1Ok, refund requested' def OK(self): self.wfile.write('%s\n' % self.message) def AddComment(self): New = {'timestamp':int(time.time()), 'donation_id':self.id, 'comment':self.comment} CommentsTable.Add(New, db) self.message = '1Ok' Server = SocketServer.TCPServer(('', NetAid.DBQueryPort), DBQueryHandler) Server.serve_forever() From guido@CNRI.Reston.VA.US Tue Oct 19 22:54:33 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 19 Oct 1999 17:54:33 -0400 (EDT) Subject: [Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108) Message-ID: <199910192154.RAA12007@python.org> > Here is the server code. Your comment about reference counts made me > want to mention that I am using StreamRequestHandler, which does a > makefile() on the socket, but if I read the code correctly, that doesn't > actually share the socket object? (Seems to just dup() the fd and make > a wholly distinct object.) Correct. This means that as far as the kernel is concerned the socket is only really closed when all file descriptors referencing the same underlying socket connection are closed. Unless you're squirreling away copies of self.rfile or self.wfile or self.connection or self.request, or unless you keep the 'self' object alive longer than you should (e.g. by creating a circular reference) these should all be closed when the objects go away. ...AHA! I looked at your code (can't really run it, though I tried) and I see that you create a circular reference by the assignment self.DoQuery = self.Fetch (and ditto for self.SendResults = self.SendRecords) and similar assignments later. This keeps the DBQueryHandler instances alive forever. This should explain what you are seeing. Solution may be as simple as assigning None to self.DoQuery and self.SendRecords. Note that your proposed generic solution of closing the socket in handle_request() in SocketServer.TCPServer won't really work given the infrastructure that this class is trying to create -- one could create a derived class that overrides get_request() to return a non-socket, and indeed UDPServer() does this. Plus, since the rfile and wfile instance variables were still there, this wouldn't have been enough, probably. So I conclude it's not a bug and I close the problem report. --Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Wed Oct 20 12:00:55 1999 From: aa8vb@yahoo.com (Randall Hopper) Date: Wed, 20 Oct 1999 07:00:55 -0400 Subject: [Python-bugs-list] Re: Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) In-Reply-To: <199910191312.JAA25126@eric.cnri.reston.va.us> References: <199910191204.IAA26749@python.org> <199910191312.JAA25126@eric.cnri.reston.va.us> Message-ID: <19991020070055.A46191658@vislab.epa.gov> Guido van Rossum: |> From first glance, it appears there may be two problems: |> |> 1) the Tkinter objects aren't being translated to Tk widget names |> (label._w, frame._w), and | |This is actually not a bug -- when you print a tuple, repr() is applied |to its items, but the tk.call() method applies str() to the arguments, |and the str() of a Tkinter widget returns its _w attribute. Try |printing map(str, ...) over the final argument tuple. Ok. |> 2) The window list isn't being passed to Tk as a Tk list |> (i.e. one arg to tk.call) | |That's the bug. I can't really test it right now, but does the |following fix it? I think so. That is, it doesn't generate Tk errors. (I'm still trying to figure out how to coerce 8-bit colormap focus.) Thanks, Randall |*************** |*** 783,789 **** | return self.tk.call('wm', 'client', self._w, name) | client = wm_client | def wm_colormapwindows(self, *wlist): |! args = ('wm', 'colormapwindows', self._w) + _flatten(wlist) | return map(self._nametowidget, self.tk.call(args)) | colormapwindows = wm_colormapwindows | def wm_command(self, value=None): |--- 783,791 ---- | return self.tk.call('wm', 'client', self._w, name) | client = wm_client | def wm_colormapwindows(self, *wlist): |! if wlist: |! wlist = (wlist,) # Tk needs a list of windows here |! args = ('wm', 'colormapwindows', self._w) + wlist | return map(self._nametowidget, self.tk.call(args)) | colormapwindows = wm_colormapwindows | def wm_command(self, value=None): | | |--Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Wed Oct 20 12:01:45 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Wed, 20 Oct 1999 07:01:45 -0400 (EDT) Subject: [Python-bugs-list] Re: Tkinter wm_colormapwindows doesn't work w/o breaking Tkinter encapsulation (PR#107) Message-ID: <199910201101.HAA06573@python.org> Guido van Rossum: |> From first glance, it appears there may be two problems: |> |> 1) the Tkinter objects aren't being translated to Tk widget names |> (label._w, frame._w), and | |This is actually not a bug -- when you print a tuple, repr() is applied |to its items, but the tk.call() method applies str() to the arguments, |and the str() of a Tkinter widget returns its _w attribute. Try |printing map(str, ...) over the final argument tuple. Ok. |> 2) The window list isn't being passed to Tk as a Tk list |> (i.e. one arg to tk.call) | |That's the bug. I can't really test it right now, but does the |following fix it? I think so. That is, it doesn't generate Tk errors. (I'm still trying to figure out how to coerce 8-bit colormap focus.) Thanks, Randall |*************** |*** 783,789 **** | return self.tk.call('wm', 'client', self._w, name) | client = wm_client | def wm_colormapwindows(self, *wlist): |! args = ('wm', 'colormapwindows', self._w) + _flatten(wlist) | return map(self._nametowidget, self.tk.call(args)) | colormapwindows = wm_colormapwindows | def wm_command(self, value=None): |--- 783,791 ---- | return self.tk.call('wm', 'client', self._w, name) | client = wm_client | def wm_colormapwindows(self, *wlist): |! if wlist: |! wlist = (wlist,) # Tk needs a list of windows here |! args = ('wm', 'colormapwindows', self._w) + wlist | return map(self._nametowidget, self.tk.call(args)) | colormapwindows = wm_colormapwindows | def wm_command(self, value=None): | | |--Guido van Rossum (home page: http://www.python.org/~guido/) From pjensen@columbus.rr.com Thu Oct 21 19:21:35 1999 From: pjensen@columbus.rr.com (pjensen@columbus.rr.com) Date: Thu, 21 Oct 1999 14:21:35 -0400 (EDT) Subject: [Python-bugs-list] error-handling bug in Python/compile.c (PR#114) Message-ID: <199910211821.OAA29619@python.org> Full_Name: Philip H. Jensen Version: 1.5.2 OS: irrelevant Submission from: dhcp9545112.columbus.rr.com (24.95.45.112) In the function com_init in Python/compile.c, the line after fail_0000: should be Py_DECREF(c->varnames) rather than Py_DECREF(c->lnotab) Just a matter of tidiness, unlikely ever to come up... From guido@CNRI.Reston.VA.US Thu Oct 21 20:18:15 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 21 Oct 1999 15:18:15 -0400 (EDT) Subject: [Python-bugs-list] error-handling bug in Python/compile.c (PR#114) Message-ID: <199910211918.PAA01394@python.org> > In the function com_init in Python/compile.c, the line after > fail_0000: > should be > Py_DECREF(c->varnames) > rather than > Py_DECREF(c->lnotab) > > Just a matter of tidiness, unlikely ever to come up... Hm... The way I read the code it is correct. Why do you believe it is wrong? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Oct 21 20:20:02 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 21 Oct 1999 15:20:02 -0400 (EDT) Subject: [Python-bugs-list] error-handling bug in Python/compile.c (PR#114) Message-ID: <199910211920.PAA01489@python.org> > In the function com_init in Python/compile.c, the line after > fail_0000: > should be > Py_DECREF(c->varnames) > rather than > Py_DECREF(c->lnotab) > > Just a matter of tidiness, unlikely ever to come up... Ignore my previous reply. You are right. Will fix it. --Guido van Rossum (home page: http://www.python.org/~guido/) From www.geeper85@hotmail.com Fri Oct 22 20:27:24 1999 From: www.geeper85@hotmail.com (www.geeper85@hotmail.com) Date: Fri, 22 Oct 1999 15:27:24 -0400 (EDT) Subject: [Python-bugs-list] where can I get a virus (PR#115) Message-ID: <199910221927.PAA10991@python.org> Full_Name: j.b smith Version: OS: Submission from: (NULL) (164.47.236.38) I want to know how they can gat so good please help me gat good at being a hacker From guido@CNRI.Reston.VA.US Mon Oct 25 15:38:59 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 25 Oct 1999 10:38:59 -0400 (EDT) Subject: [Python-bugs-list] Jonathan Craft: Possible to-do addition (PR#116) Message-ID: <199910251438.KAA06624@python.org> A worthy to-do item. ------- Forwarded Message Date: Sat, 23 Oct 1999 08:24:32 -0000 From: Jonathan Craft To: guido@python.org Subject: Possible to-do addition Hi Guido, Is there a visual interface builder (as in VBasic, Hypercard, Icon) for Tkinter? I haven't been able to find any information on it (I'm new to Python). If not, that would be a good to-do. Jonathan Craft mailto:jcchina@bigfoot.com ------- End of Forwarded Message From bwarsaw@python.org Mon Oct 25 23:15:32 1999 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 25 Oct 1999 18:15:32 -0400 (EDT) Subject: [Python-bugs-list] Easy way to core dump python (PR#117) Message-ID: <199910252215.SAA08577@python.org> Full_Name: Barney Wasraw Version: 1.5.2+ OS: Solar Us Submission from: anthem.cnri.reston.va.us (132.151.1.40) This will core Python nicely. It should probably raise a TypeError def test(x): pass apply(test, (1,), {7:3}) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Oct 25 23:26:32 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 25 Oct 1999 18:26:32 -0400 (EDT) Subject: [Python-bugs-list] Easy way to core dump python (PR#117) References: <199910252215.SAA08577@python.org> Message-ID: <14356.55576.240213.127530@anthem.cnri.reston.va.us> Here's the error message that JPython now raises. Traceback (innermost last): File "/tmp/test.py", line 2, in ? TypeError: apply() 3rd argument must be a dictionary with string keys From bwarsaw@cnri.reston.va.us Mon Oct 25 23:26:34 1999 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Mon, 25 Oct 1999 18:26:34 -0400 (EDT) Subject: [Python-bugs-list] Easy way to core dump python (PR#117) Message-ID: <199910252226.SAA09044@python.org> Here's the error message that JPython now raises. Traceback (innermost last): File "/tmp/test.py", line 2, in ? TypeError: apply() 3rd argument must be a dictionary with string keys From graham@lynda.com Tue Oct 26 20:14:37 1999 From: graham@lynda.com (graham@lynda.com) Date: Tue, 26 Oct 1999 15:14:37 -0400 (EDT) Subject: [Python-bugs-list] rfc822 typo (PR#118) Message-ID: <199910261914.PAA14675@python.org> Full_Name: Graham Hughes Version: 1.5.2 OS: Linux Submission from: odac.geoin.com (209.78.98.129) In rfc822.py, at AddressList.__getitem__, the stock 1.5.2 installation uses `self.addrlist[index]', when it should in fact be `self.addresslist[index]'. From guido@CNRI.Reston.VA.US Tue Oct 26 20:19:26 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 26 Oct 1999 15:19:26 -0400 Subject: [Python-bugs-list] rfc822 typo (PR#118) In-Reply-To: Your message of "Tue, 26 Oct 1999 15:14:37 EDT." <199910261914.PAA14675@python.org> References: <199910261914.PAA14675@python.org> Message-ID: <199910261919.PAA03588@eric.cnri.reston.va.us> > In rfc822.py, at AddressList.__getitem__, the stock 1.5.2 installation uses > `self.addrlist[index]', when it should in fact be `self.addresslist[index]'. Thanks. This is already fixed in our CVS version (it wasn't reported through the bugs list so if you searched for it you wouldn't have found it.) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Tue Oct 26 20:19:32 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 26 Oct 1999 15:19:32 -0400 (EDT) Subject: [Python-bugs-list] rfc822 typo (PR#118) Message-ID: <199910261919.PAA14853@python.org> > In rfc822.py, at AddressList.__getitem__, the stock 1.5.2 installation uses > `self.addrlist[index]', when it should in fact be `self.addresslist[index]'. Thanks. This is already fixed in our CVS version (it wasn't reported through the bugs list so if you searched for it you wouldn't have found it.) --Guido van Rossum (home page: http://www.python.org/~guido/) From jsb@brodkey.com Wed Oct 27 02:37:23 1999 From: jsb@brodkey.com (jsb@brodkey.com) Date: Tue, 26 Oct 1999 21:37:23 -0400 (EDT) Subject: [Python-bugs-list] 3 failed tests after install (PR#119) Message-ID: <199910270137.VAA28289@python.org> Full_Name: jerald s brodkey Version: 1.52 OS: Mandrake 6.1 Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net (199.179.175.120) test_long output: long / * % divmod long bit-operation identities long str/hex/oct/atol long miscellaneous operations Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 251, in ? test_misc() File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 225, in test_misc raise TestFailed, "int(long(-sys.maxint-1)) overflowed!" test_support -- test failed: int(long(-sys.maxint-1)) overflowed! test_socket output: socket.error Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found test_types output: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_types.py", line 89, in ? if int(long(x)) != x: raise TestFailed, 'long op' OverflowError: long int too long to convert From guido@CNRI.Reston.VA.US Wed Oct 27 03:34:27 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 26 Oct 1999 22:34:27 -0400 (EDT) Subject: [Python-bugs-list] 3 failed tests after install (PR#119) Message-ID: <199910270234.WAA29203@python.org> There's no reason to submit this as a bug report yet -- most likely this is a platform bug. > Full_Name: jerald s brodkey > Version: 1.52 > OS: Mandrake 6.1 > Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net (199.179.175.120) > > test_long output: > long / * % divmod > long bit-operation identities > long str/hex/oct/atol > long miscellaneous operations > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 251, in ? > test_misc() > File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 225, in > test_misc > raise TestFailed, "int(long(-sys.maxint-1)) overflowed!" > test_support -- test failed: int(long(-sys.maxint-1)) overflowed! Hm. Strange. Can you enter Python interactively and try to print the values of these expressions? sys.maxint -sys.maxint-1 long(-sys.maxint-1) int(long(-sys.maxint-1)) Please save the session and mail to me. > test_socket output: > socket.error > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_socket.py", line 71, in ? > ip = socket.gethostbyname(hostname) > socket.error: host not found This is common if your internet configuration doesn't have a DNS setup; you can ignore it. > test_types output: > 6. Built-in types > 6.1 Truth value testing > 6.2 Boolean operations > 6.3 Comparisons > 6.4 Numeric types (mostly conversions) > 6.4.1 32-bit integers > 6.4.2 Long integers > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_types.py", line 89, in ? > if int(long(x)) != x: raise TestFailed, 'long op' > OverflowError: long int too long to convert Looks like the same one you had before. What kind of hardware are you using? I wonder if there's some kind of mismatch between the compiler and the hardware for certain long integer or floating point ops. Did you build this Python yourself or are you running the tests on a binary that came with the OS? (Doesn't Mandrake come with Python? I know Red Hat does!) --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Wed Oct 27 05:53:49 1999 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 27 Oct 1999 00:53:49 -0400 Subject: [Python-bugs-list] 3 failed tests after install (PR#119) In-Reply-To: <199910270137.VAA28289@python.org> Message-ID: <000c01bf2037$43720820$f8a0143f@tim> > Full_Name: jerald s brodkey > Version: 1.52 > OS: Mandrake 6.1 > Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net > (199.179.175.120) What kind of CPU? > test_support -- test failed: int(long(-sys.maxint-1)) overflowed! Last time I saw this it was eventually traced to a compiler optimization bug, on an Intel platform running some flavor of Unix. If you recompile Python with optimization turned off, and the problem goes away, it's almost certainly the same problem. DejaNews can be used in that case to track down the details. From tim_one@email.msn.com Wed Oct 27 05:54:13 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 27 Oct 1999 00:54:13 -0400 (EDT) Subject: [Python-bugs-list] 3 failed tests after install (PR#119) Message-ID: <199910270454.AAA01060@python.org> > Full_Name: jerald s brodkey > Version: 1.52 > OS: Mandrake 6.1 > Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net > (199.179.175.120) What kind of CPU? > test_support -- test failed: int(long(-sys.maxint-1)) overflowed! Last time I saw this it was eventually traced to a compiler optimization bug, on an Intel platform running some flavor of Unix. If you recompile Python with optimization turned off, and the problem goes away, it's almost certainly the same problem. DejaNews can be used in that case to track down the details. From tim_one@email.msn.com Thu Oct 28 04:22:38 1999 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 27 Oct 1999 23:22:38 -0400 Subject: [Python-bugs-list] 3 failed tests after install (PR#119) In-Reply-To: <4.1.19991027094502.00945a20@en.com> Message-ID: <000201bf20f3$afdb7480$0a2d153f@tim> [Jerald s brodkey [mailto:jsb@brodkey.com]] > Thanks for the answer. I recompiled it without optimization and > now and now all tests passed except test_socket which is to be expected. OK! See http://www.deja.com/getdoc.xp?AN=503937876 for a thread about the cause and the cure (it's a known compiler bug). > However: > > Guido also sent an answer and asked if I would run the following > interactively: > sys.maxint > -sys.maxint-1 > long(-sys.maxint-1) > int(long(-sys.maxint-1)) > > I did that on the system compiled with optimization as well as the new one > without. > > All give same output: > Traceback (innermost last): > File"" line 1, in ? > NameError: sys > > I gather this is a problem? Na, it just appears you've never used Python before. Spend a little time reading the tutorial -- you'll like it! What Guido didn't tell you (because any Python programmer would know this) is that you first need to enter the line import sys Until you do that, the name "sys" doesn't mean anything to Python, and that's why you're getting the NameError exceptions. See the thread referenced above for the kind of output you *should* see when you enter this. From tim_one@email.msn.com Thu Oct 28 04:23:34 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 27 Oct 1999 23:23:34 -0400 (EDT) Subject: [Python-bugs-list] 3 failed tests after install (PR#119) Message-ID: <199910280323.XAA12319@python.org> [Jerald s brodkey [mailto:jsb@brodkey.com]] > Thanks for the answer. I recompiled it without optimization and > now and now all tests passed except test_socket which is to be expected. OK! See http://www.deja.com/getdoc.xp?AN=503937876 for a thread about the cause and the cure (it's a known compiler bug). > However: > > Guido also sent an answer and asked if I would run the following > interactively: > sys.maxint > -sys.maxint-1 > long(-sys.maxint-1) > int(long(-sys.maxint-1)) > > I did that on the system compiled with optimization as well as the new one > without. > > All give same output: > Traceback (innermost last): > File"" line 1, in ? > NameError: sys > > I gather this is a problem? Na, it just appears you've never used Python before. Spend a little time reading the tutorial -- you'll like it! What Guido didn't tell you (because any Python programmer would know this) is that you first need to enter the line import sys Until you do that, the name "sys" doesn't mean anything to Python, and that's why you're getting the NameError exceptions. See the thread referenced above for the kind of output you *should* see when you enter this. From xfb52@dial.pipex.com Fri Oct 29 19:33:57 1999 From: xfb52@dial.pipex.com (xfb52@dial.pipex.com) Date: Fri, 29 Oct 1999 14:33:57 -0400 (EDT) Subject: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Message-ID: <199910291833.OAA16861@python.org> Full_Name: Alex Zbyslaw Version: 1.5.2 OS: FreeBSD 3.2 Submission from: useraq64.uk.uudial.com (62.188.136.124) When python is compiled with thread support and readline, ^C no longer works properly (interpreter goes into an infinite loop). (Tried with readline 2.0, 2.2 and 4.0). The same system compiled without readline but with threads works fine, and compiled without threads but with readline works fine. The error seems to centre around the signal handler installed by call_readline in Modules/readline.c which does not call signal_handler in Modules/signalmodule.c (which is what happens without readline). I have found an inadequate fix which works with readline-4.0 (but not earlier realeases). This makes ^C work but only after a RETURN is pressed. Whilst not perfect, it does at least allow readline and threads. Hopefully this may point someone who can better understand the signal handling to find a better fix. 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. --Alex *** Modules/readline.c Fri Oct 29 19:31:13 1999 --- Modules/readline.c.ORIG Fri Oct 29 19:14:27 1999 *************** *** 34,40 **** extern int rl_bind_key_in_map(); extern int rl_initialize(); extern int add_history(); - extern int rl_catch_signals; extern Function *rl_event_hook; #endif --- 34,39 ---- *************** *** 233,239 **** static void setup_readline() { - rl_catch_signals=0; rl_readline_name = "python"; /* Force rebind of TAB to insert-tab */ rl_bind_key('\t', rl_insert); --- 232,237 ---- *************** *** 277,283 **** int n; char *p; RETSIGTYPE (*old_inthandler)(); ! /* old_inthandler = signal(SIGINT, onintr); */ if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ --- 275,281 ---- int n; char *p; RETSIGTYPE (*old_inthandler)(); ! old_inthandler = signal(SIGINT, onintr); if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ *************** *** 288,294 **** } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! /* signal(SIGINT, old_inthandler); */ if (p == NULL) { p = malloc(1); if (p != NULL) --- 286,292 ---- } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! signal(SIGINT, old_inthandler); if (p == NULL) { p = malloc(1); if (p != NULL)