From flight@mathi.uni-heidelberg.de Wed Feb 2 07:47:09 2000 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Wed, 2 Feb 2000 02:47:09 -0500 (EST) Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200002020747.CAA18099@python.org> --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, this must be the strangest bug report ever sent to bugs-py ;-). I don't expect a resolution for this bug from you, I just wanted to make sure this thing is recorded and the BTS. Perhaps somebody could give me a hint where I could look for the misbehavior. Candidates seem to be glibc, LinuxThreads, GNU readline, the Python readline module and the Python thread support ;-) In 1.5.2, there's a strange problem with signals on Linux systems. This has been discussed before on the mailing list, probably it even has a relation to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few other aspects. Definitely it is a (platform-specific) problem in 1.5.2. I have problems describing the bug, since the behavior seems to depend on so many parameters. The most obvious incarnation of the problem is probably this: In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you press Control-C on the command line (or send a SIGINT), the interpreter exits to the shell: freefly;104> python Python 1.5.2 (#0, Sep 13 1999, 09:12:57) [GCC 2.95.1 19990816 (release)]= on linux2=20 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> [Ctrl-C] freefly;105>=20 Normally, you'd expect a KeyboardInterrupt exception here. Now I tried and compiled different configurations of Python (each from a pristine source tree) on this Debian system: (151+t+rl) Python 1.5.1 (threads, readline) (152) Python 1.5.2 (no threads, no readline) =20 (152+rl) Python 1.5.2 (no threads, readline) (152+t) Python 1.5.2 (threads, no readline) (152+t+rl) Python 1.5.2 (threads, readline) (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline) Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads. readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but this made no difference). When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and the same GNU readline version 2.1. The following tables show the output of some experiments with those configurations. The [] brackets show the keys pressed. Note that a line like "[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to the first Ctrl-C! "----" lines mean that I started up a new clean session. (1) This is what happens when you start up a new interpreter and press Ctrl-C once, twice and so on, while on the command line: 152,152+t 152+rl,152+pth+rl 152+t+rl 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D ------------------ ---------------- ------------- ---------------- >>> [Ctrl-C][Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C][Ct...] KeyboardInterrupt KeyboardInterrupt freefly:5> ---------------- >>> [Ctrl-C] >>> [Ctrl-C] ------------- KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt ------------------ ---------------- 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Ctr...] --------------------- -> 1.5.2 with readline but without LinuxThreads is right. -> For some reason, 1.5.2 without readline ignores the first SIGINT. -> 1.5.2 with both readline and LinuxThreads kill the interpreter. -> 1.5.1 seems to ignore all SIGINTs's. =20 -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the interpreter doesn't get killed, but still after the first SIGINT all following SIGINTs are ignored. =20 -> It's worth a note that with only one of readline or thread support, the package seems to behave more reasonable; have both enabled is bad. =20 -> With threading support by means of GNU Pth (instead of the native libc6 LinuxThreads), the package behaves more correctly, too! =20 (2) Now on those systems who seemed to ignore the first SIGINT, I pressed Enter after it: 152,152+t 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D= =3D --------------------- -------------------- >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] Traceback (innermost last): Traceback (innermost last): File "", line 0, in ? File "", line 0, in ? KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C][Enter] KeyboardInterrupt Traceback (innermost last): --------------------- File "", line 0, in ? KeyboardInterrupt >>> -------------------- =20 -> Obviously, the interpreter *DID* record the SIGINT in the first place, it just didn't provoke any immediate action=20 -> On 1.5.2 without readline, the second and all following SIGINTs are handled as one would expect. -> 1.5.1 with thread and readline shows this strange behavior not only for the first, but also for the second and any following SIGINT. =20 (3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs are ignored. You're not able even to interrupt a loop, after the interpreter has received a SIGINT while he was on the command line: =20 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] {kein weiteres SIGINT wird akzeptiert, auch im Laufen:} >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "", line 1, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "", line 1, in ? KeyboardInterrupt >>> [Ctrl-C] KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- -> Note that it didn't hurt to break multiple times into a loop; only SIGINTs on the command line do mess up the interpreter! =20 =20 (4) In the Debian 2.2 Python package, you have to be careful not to kill the interpreter; that's especially a problem when you try to break into a loop--if you hold down Ctrl-C for too long, the interpreter quits! =20 152+t+rl (Debian 2.2 package) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --------------------- >>> [Ctrl-C] freefly:5> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C pressed down for a longer time] 400 401 freefly;19>=20 --------------------- (5) The Debian 2.2 package behaves more reasonable when the readline module has been moved out of the way: 152+t (Debian 2.2 package, readline module moved out of the way) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C][Ctrl-C] KeyboardInterrupt >>> ... (vgl. 152, 152+t) --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 40[Enter] Traceback (innermost last): File "", line 0, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/ tasWxAOGLUK3K3ucMBbhBag= =PTOI -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From tim_one@email.msn.com Wed Feb 2 08:04:04 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 2 Feb 2000 03:04:04 -0500 Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) In-Reply-To: <200002020747.CAA18099@python.org> Message-ID: <000b01bf6d54$12db36e0$28a0143f@tim> [flight@mathi.uni-heidelberg.de] > this must be the strangest bug report ever sent to bugs-py ;-). No, but I don't recall one that evidenced more hard & tedious work! Wow. Thank you. Switch to Windows -- it's so much more reliable . If you haven't already done so, may I suggest building Python from the current CVS development source tree instead? http://www.python.org/download/cvs.html This may be a waste of effort, but I'd hate to see you pour more time tracking down obscure bugs that may already have been fixed. Contrarily, if the current CVS version still displays the problems, more work devoted to tracking them down is certain not to be a waste. From tim_one@email.msn.com Wed Feb 2 08:03:18 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 2 Feb 2000 03:03:18 -0500 (EST) Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200002020803.DAA18380@python.org> [flight@mathi.uni-heidelberg.de] > this must be the strangest bug report ever sent to bugs-py ;-). No, but I don't recall one that evidenced more hard & tedious work! Wow. Thank you. Switch to Windows -- it's so much more reliable . If you haven't already done so, may I suggest building Python from the current CVS development source tree instead? http://www.python.org/download/cvs.html This may be a waste of effort, but I'd hate to see you pour more time tracking down obscure bugs that may already have been fixed. Contrarily, if the current CVS version still displays the problems, more work devoted to tracking them down is certain not to be a waste. From flight@mathi.uni-heidelberg.de Wed Feb 2 13:23:56 2000 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Wed, 2 Feb 2000 08:23:56 -0500 (EST) Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200002021323.IAA24891@python.org> Hi, > If you haven't already done so, may I suggest building Python from the > current CVS development source tree instead? sorry, I forgot to mention that I tried that. Didnt't change the behavior at all (I also saw that there were no big changes to the readline nor to the threading code since 1.5.2). Gregor From harri.pasanen@trema.com Wed Feb 2 17:48:02 2000 From: harri.pasanen@trema.com (harri.pasanen@trema.com) Date: Wed, 2 Feb 2000 12:48:02 -0500 (EST) Subject: [Python-bugs-list] configure problem for Solaris 7 + gcc 2.95.2 (PR#197) Message-ID: <200002021748.MAA01773@python.org> Full_Name: Harri Pasanen Version: 1.5.2 OS: Solaris 7 Submission from: mark.labs.trema.com (194.103.215.2) Installing Python on Solaris 7 with gcc 2.95.2 in our environment the LINKFORSHARED macro was left empty. It should have contained something like LINKFORSHARED="-Wl,--export-dynamic" without that the shared libs won't load and fail with error messages like: ImportError: ld.so.1: python: fatal: relocation error: file /work/harri/src/omniORB2_8_develop/omni/lib/sun4_sosV_5.7/_omniidlmodule.so: symbol _Py_NoneStruct: referenced symbol not found I would think the configure.in that would work for me would look something like this: SunOS/5*) case $CC in *gcc*) if $CC -Xlinker -V 2>/dev/null | grep BFD >/dev/null then LINKFORSHARED="-Xlinker --export-dynamic" elif $CC -v 2>&1 | grep "2.95.2" >/dev/null LINKFORSHARED="-W,--export-dynamic" fi;; esac;; esac -Harri From guido@CNRI.Reston.VA.US Wed Feb 2 18:45:05 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 2 Feb 2000 13:45:05 -0500 (EST) Subject: [Python-bugs-list] configure problem for Solaris 7 + gcc 2.95.2 (PR#197) Message-ID: <200002021845.NAA02898@python.org> > I would think the configure.in that would work for me would look something > like this: > > SunOS/5*) case $CC in > *gcc*) > if $CC -Xlinker -V 2>/dev/null | grep BFD >/dev/null > then > LINKFORSHARED="-Xlinker --export-dynamic" > elif $CC -v 2>&1 | grep "2.95.2" >/dev/null > LINKFORSHARED="-W,--export-dynamic" > fi;; > esac;; > esac Thanks, Harri. I'm not sure what the grep for a specific version number will do for other gcc versions; should this theoretically check for version numbers >= or <= 1.95.2? --Guido van Rossum (home page: http://www.python.org/~guido/) From flight@mathi.uni-heidelberg.de Thu Feb 3 10:47:25 2000 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Thu, 3 Feb 2000 05:47:25 -0500 (EST) Subject: [Python-bugs-list] Returned mail: User unknown (PR#196) Message-ID: <200002031047.FAA22337@python.org> This is a MIME-encapsulated message --LAA26536.949574804/relay.uni-heidelberg.de The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET) from mailserver.mathi.uni-heidelberg.de [129.206.26.32] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- .. while talking to parrot.python.org.: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown --LAA26536.949574804/relay.uni-heidelberg.de Content-Type: message/delivery-status Reporting-MTA: dns; relay.uni-heidelberg.de Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET) Final-Recipient: RFC822; bugs-by@python.org Action: failed Status: 5.1.1 Remote-MTA: DNS; parrot.python.org Diagnostic-Code: SMTP; 550 ... User unknown Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET) --LAA26536.949574804/relay.uni-heidelberg.de Content-Type: message/rfc822 Return-Path: Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32]) by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531 for ; Thu, 3 Feb 2000 11:46:41 +0100 (MET) Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30]) by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917 for ; Thu, 3 Feb 2000 11:48:11 +0100 (CET) Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100 Date: Thu, 3 Feb 2000 11:48:12 +0100 From: Gregor Hoffleit To: bugs-by@python.org Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre3i Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic (http://x44.deja.com/getdoc.xp?AN=545159177). Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml) for FreeBSD (disabling the interrupt handler chanege in the readline module) works for Debian, too, i.e. if I stick with the default inthandler in the readline module, SIGINT doesn't kill the interpreter anymore. Still, the drawback of this change is that I have to press RETURN before a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1 on the system with the same configuration). Still, IMHO this behavior is preferable. Gregor --LAA26536.949574804/relay.uni-heidelberg.de-- From bhaddow@orbism.com Mon Feb 7 10:13:08 2000 From: bhaddow@orbism.com (bhaddow@orbism.com) Date: Mon, 7 Feb 2000 05:13:08 -0500 (EST) Subject: [Python-bugs-list] segmentation fault when trying to read from a close()d gdbm database (PR#198) Message-ID: <200002071013.FAA18237@python.org> Full_Name: Barry Haddow Version: 1.52 OS: Linux (RedHat 6.0) Submission from: p868.as1.adl.dublin.eircom.net (159.134.231.100) Hi Running the following causes a segmentation fault. #/usr/bin/env python import gdbm db = gdbm.open('db','n') db['name'] = 'barry' db.close() print db['name'] The problem can be fixed by editing the function dbm_subscript() in Modules/gdbmmodule.c , line 148. A check should be added to ensure that the database is not already closed, as in lines 182-184 of dbm_ass_sub(). cheers Barry From guido@python.org Mon Feb 7 17:55:20 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 07 Feb 2000 12:55:20 -0500 Subject: [Python-bugs-list] please resolve 191.. (PR#195) In-Reply-To: Your message of "Mon, 31 Jan 2000 14:39:09 EST." <200001311939.OAA23715@python.org> References: <200001311939.OAA23715@python.org> Message-ID: <200002071755.MAA18632@eric.cnri.reston.va.us> > the -Xlinker -export-dynamic happens to be a GNU ld specific solution, > but the bug that python doesn't force include all the symbols should be > documented so that people don't encounter the problem... There's a Solaris-specific patch (just checked in a few days ago) to configure.in that takes care of this; maybe it can be made general? No time to explain, see latest configure.in cvs log. python.org/download/cvs.html --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Mon Feb 7 17:53:56 2000 From: guido@python.org (guido@python.org) Date: Mon, 7 Feb 2000 12:53:56 -0500 (EST) Subject: [Python-bugs-list] please resolve 191.. (PR#195) Message-ID: <200002071753.MAA29524@python.org> > the -Xlinker -export-dynamic happens to be a GNU ld specific solution, > but the bug that python doesn't force include all the symbols should be > documented so that people don't encounter the problem... There's a Solaris-specific patch (just checked in a few days ago) to configure.in that takes care of this; maybe it can be made general? No time to explain, see latest configure.in cvs log. python.org/download/cvs.html --Guido van Rossum (home page: http://www.python.org/~guido/) From ajung@sz-sb.de Wed Feb 9 17:27:16 2000 From: ajung@sz-sb.de (ajung@sz-sb.de) Date: Wed, 9 Feb 2000 12:27:16 -0500 (EST) Subject: [Python-bugs-list] Re: strop.lowercase/uppercase delivers too much characters (PR#190) Message-ID: <200002091727.MAA11940@python.org> On Mon, Feb 07, 2000 at 12:32:12PM -0500, Guido van Rossum wrote: > Andreas, > > This is not a bug; this is because your locale specifies the German > language. Those characters, when printed, are accented characters. > > See docs for the locale module and the unix man page for the setlocale > C function for more info. Guido, it's definitely not a locale problem. There are no locale variables set in my enviroment. Also recompiled Python without the locale module and I got the same result as described. However I could not track down the problem. Cheers, Andreas From aa8vb@yahoo.com Wed Feb 9 17:45:31 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Wed, 9 Feb 2000 12:45:31 -0500 (EST) Subject: [Python-bugs-list] Request - EPIPE Handling Proposal (PR#199) Message-ID: <200002091745.MAA12647@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5 Submission from: ralph.rtpnc.epa.gov (134.67.66.44) The gist of the problem is that any Python program which writes to stdout or stderr needs to handle EPIPE to avoid tripping Python error tracebacks, and doing so is non-trivial and obfuscates otherwise-simple Python code. Basically, this is buggy Python code: > python -c "for i in xrange(100000): print 'Lots of output'" | head Traceback (innermost last): File "", line 1, in ? IOError: [Errno 32] Broken pipe The attached script demonstrates the difficulty of error catching and handling with EPIPE. Run as: broken_pipe.py | head ============================================================================== PROPOSAL: Add an "epipe_error" attribute to the file object. It would determine whether EPIPE errors from read()/write() calls generate SystemExit or IOError exceptions. ============================================================================== By default EPIPEs received from the stdin/out/err files would generate SystemExit exceptions (epipe_error = 0). All other files would default to IOError exceptions (epipe_error = 1). Of course, these settings can be changed by the developer. See the c.l.python thread "Python & EPIPE: Handling Chg Proposal" for a more discussion on this topic. FWIW, most C utilities don't have this problem since they don't ignore SIGPIPE and follow the default behavior of exiting when they receive it. The proposed change would allow Python to behave similarly by default for stdin/stdout/stderr broken pipes, but leave the Python developer in full control of EPIPE handling, for all files. Thanks, Randall ========= Attachment 1 ======================================================= #!/usr/bin/env python """ ------------------------------------------------------------------------------ broken_pipe.py - Demonstrate how EPIPE handling really convolutes Python code. (R. Hopper, 2/2000) The jist of it is this: python -c "for i in xrange(100000): print 'Lots of output'" | more This is buggy Python code. Why? Because any normal write() connected to stdout can generate EPIPE, which Python turns into an IOError exception, which materializes as a Python exception dump and error message on termination. Substitute 'more' with your favorite pager ('head', etc.). Quit the pager after the first screenful appears to make the program fail. What about using xrange(10000), or xrange(100)? Depends on the OS buffer sizes. So with the current EPIPE handling in Python , the only correct solution is for every program that writes to stdout (or stderr) to handle IOError exceptions for EPIPE explicitly. However, special-handling EPIPE IOErrors specifically really convolutes otherwise simple Python code: ------------------------------------------------------------------------------ """ import sys, string, errno def write_a_rec(): print '' def write_recs(): for i in xrange(100000): #-------------------------------------------------------------------------- # In write_a_rec(), we could do some things that may generate different # exceptions. Among them, IOErrors, and among those EPIPE errors # specifically. Special-handling EPIPE is a real pain. #-------------------------------------------------------------------------- # So we can't just call this method. Unprotected stdout/err write()s # to stdout and stderr can produce errors. ## write_a_rec() # We have to special-handle EPIPE IOErrors from write()s to stdout/err, but # we want to preserve all the other exceptions. # # To avoid duplicating exception cleanup code, we use a nested try. # This would be unnecessary if we could snag just EPIPE IOErrors with # an except clause. try: try: write_a_rec() except IOError, x: if x.errno == errno.EPIPE: sys.stderr.write( "\nHandling EPIPE...exiting quietly.\n" " (Normally, nothing would be printed.)" "\n\n" ) sys.exit(1) else: raise except: # Do raise # # MAIN # write_recs() """ ------------------------------------------------------------------------------ Possible Solutions: 1) Have Python not print a traceback and error if EPIPE IOErrors propagate up to the top stack level (what if this is a socket though; then you want the error). Bad idea. 2) Throw a separate exception for EPIPE (IOErrorEPIPE?) so you don't have to do double-try's to process them. (No, breaks existing code, and still demands EPIPE handling for all programs that write more than a few lines to stdout/stderr. => 3) Have a file descriptor attribute (such as "epipe_error") that selectively sets whether receiving EPIPE is turned into an IOError or a SystemExit if it propagates up to the top stack level. In other words, chose per file descriptor, whether EPIPE should be a hard error or not. stdout/stderr's default could be "no", while for all other files, the default would be "yes". Alternatively, the flag could designate whether SystemExit or IOError is thrown to start with. ------------------------------------------------------------------------------ From aa8vb@yahoo.com Wed Feb 9 18:06:03 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Wed, 9 Feb 2000 13:06:03 -0500 (EST) Subject: [Python-bugs-list] anydbm can't handle dumbdbm (PR#200) Message-ID: <200002091806.NAA13136@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5 Submission from: ralph.rtpnc.epa.gov (134.67.66.44) Basically, anydbm won't open dumbdbm files that anydbm created. >>> import anydbm >>> db = anydbm.open( "database", "c" ) >>> db[ "1" ] = "one" >>> db.close() >>> db = anydbm.open( "database", "r" ) Traceback (innermost last): File "", line 1, in ? File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db More details can be found in the c.l.python thread "anydbm - a simple question". I searched for a matching bug and didn't find one in the database. Also, I verified my whichdb.py matches what's currently in CVS, so I don't think this has been fixed yet. Thanks, Randall From tage@acm.org Thu Feb 10 12:48:21 2000 From: tage@acm.org (tage@acm.org) Date: Thu, 10 Feb 2000 07:48:21 -0500 (EST) Subject: [Python-bugs-list] Binascii adds \n and not \r\n (PR#201) Message-ID: <200002101248.HAA06589@python.org> Full_Name: Tage Stabell-Kulø Version: 1.5.2 OS: FreeBSD Submission from: tage.pasta.cs.uit.no (129.242.36.34) In the base64 module it is written that length (of a line) is excluding the terminating CRLF. However, the module binascii (imported in base64) does not add CRLF (\r\n) to the end of lines, merely a '\n' (line 491 in Modules/binascii.c). RFC-1521 states, in effect, that lines should be separated by CRLF (Section 2, 4th paragraph). The module smtplib.py correctly adds CRLF. Either the text in base64 should be changed to reflect that lines are not CRLF terminted, or, preferrably, lines should be CRLF terminated. Notice Jansen has included code to _parse_ base64 that is (properly?) CRLF encoded; see binascii.c line 390. The patch below achieves the desired effect. I have not modified the code that parses and produces uuencode. Yours sincerely [TaSK] *** Modules/binascii.c.org Thu Feb 10 13:36:50 2000 --- Modules/binascii.c Thu Feb 10 13:37:28 2000 *************** *** 488,494 **** *ascii_data++ = table_b2a_base64[(leftchar&0xf) << 2]; *ascii_data++ = BASE64_PAD; } ! *ascii_data++ = '\n'; /* Append a courtesy newline */ _PyString_Resize(&rv, (ascii_data - (unsigned char *)PyString_AsString(rv))); --- 488,494 ---- *ascii_data++ = table_b2a_base64[(leftchar&0xf) << 2]; *ascii_data++ = BASE64_PAD; } ! *ascii_data++ = '\r\n'; /* Append a courtesy CRLF */ _PyString_Resize(&rv, (ascii_data - (unsigned char *)PyString_AsString(rv))); ========================================================================= 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 aa8vb@yahoo.com Fri Feb 11 12:12:30 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Fri, 11 Feb 2000 07:12:30 -0500 (EST) Subject: [Python-bugs-list] aa8vb@yahoo.com (PR#202) Message-ID: <200002111212.HAA08410@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5 Submission from: ralph.rtpnc.epa.gov (134.67.66.44) Recently tried to rebuild Python, adding in gdbm. This Setup line is new for this build: gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm The problem is, 1.5.2's makesetup doesn't take RPATH directives, reporting -rpath as a "bad word". Note that RPATH directives take different forms on different OSs: -rpath on SGI IRIX is -R on Solaris, --rpath on FreeBSD, etc. A provision should be made for RPATH options as they are used to avoid the need for LD_LIBRARY_PATH hacks. --- Makefiles --- bad word -rpath in gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm *** Error code 1 Thanks, Randall From flight@mathi.uni-heidelberg.de Fri Feb 11 13:52:42 2000 From: flight@mathi.uni-heidelberg.de (Gregor Hoffleit) Date: Fri, 11 Feb 2000 14:52:42 +0100 Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) In-Reply-To: <000b01bf6d54$12db36e0$28a0143f@tim>; from tim_one@email.msn.com on Wed, Feb 02, 2000 at 03:04:04AM -0500 References: <200002020747.CAA18099@python.org> <000b01bf6d54$12db36e0$28a0143f@tim> Message-ID: <20000211145242.A6321@hoffleit.org> --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ok, one more data point: On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote: > You know, I think you may have it. On IRIX, I don't have Python built > with threads. However, on FreeBSD at home I'd guess that it is (I built = it > from ports). My IRIX python has no problem with Ctrl-C while my FreeBSD > version at home locks up with Ctrl-C. I rebuilt my IRIX Python > --with-thread, and now it hangs when Ctrl-C is hit. And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and FreeBSD and kills Linux Python. This doesn't sound like a kernel problem, more like a problem with readline not being thread-safe I guess. Gregor =20 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq jFH5J1TsLQBbQTPU5Xvv0Bo= =0j16 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From flight@mathi.uni-heidelberg.de Fri Feb 11 17:35:45 2000 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Fri, 11 Feb 2000 12:35:45 -0500 (EST) Subject: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200002111735.MAA15711@python.org> --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ok, one more data point: On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote: > You know, I think you may have it. On IRIX, I don't have Python built > with threads. However, on FreeBSD at home I'd guess that it is (I built = it > from ports). My IRIX python has no problem with Ctrl-C while my FreeBSD > version at home locks up with Ctrl-C. I rebuilt my IRIX Python > --with-thread, and now it hangs when Ctrl-C is hit. And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and FreeBSD and kills Linux Python. This doesn't sound like a kernel problem, more like a problem with readline not being thread-safe I guess. Gregor =20 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq jFH5J1TsLQBbQTPU5Xvv0Bo= =0j16 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From guido@python.org Fri Feb 11 20:48:56 2000 From: guido@python.org (guido@python.org) Date: Fri, 11 Feb 2000 15:48:56 -0500 (EST) Subject: [Python-bugs-list] Re: strop.lowercase/uppercase delivers too much characters (PR#190) Message-ID: <200002112048.PAA20360@python.org> > On Mon, Feb 07, 2000 at 12:32:12PM -0500, Guido van Rossum wrote: > > Andreas, > > > > This is not a bug; this is because your locale specifies the German > > language. Those characters, when printed, are accented characters. > > > > See docs for the locale module and the unix man page for the setlocale > > C function for more info. > it's definitely not a locale problem. There are no locale > variables set in my enviroment. Also recompiled Python without > the locale module and I got the same result as described. > However I could not track down the problem. Sorry, it still looks like a local issue (since if I set LANG=de I get the exact output). Your system is probably configured to default to a different locale. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Feb 11 20:50:07 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 11 Feb 2000 15:50:07 -0500 Subject: [Python-bugs-list] Re: strop.lowercase/uppercase delivers too much characters (PR#190) In-Reply-To: Your message of "Wed, 09 Feb 2000 12:27:16 EST." <200002091727.MAA11940@python.org> References: <200002091727.MAA11940@python.org> Message-ID: <200002112050.PAA19855@eric.cnri.reston.va.us> > On Mon, Feb 07, 2000 at 12:32:12PM -0500, Guido van Rossum wrote: > > Andreas, > > > > This is not a bug; this is because your locale specifies the German > > language. Those characters, when printed, are accented characters. > > > > See docs for the locale module and the unix man page for the setlocale > > C function for more info. > it's definitely not a locale problem. There are no locale > variables set in my enviroment. Also recompiled Python without > the locale module and I got the same result as described. > However I could not track down the problem. Sorry, it still looks like a local issue (since if I set LANG=de I get the exact output). Your system is probably configured to default to a different locale. --Guido van Rossum (home page: http://www.python.org/~guido/) From claudius@accessoft.com Sat Feb 12 01:53:10 2000 From: claudius@accessoft.com (claudius@accessoft.com) Date: Fri, 11 Feb 2000 20:53:10 -0500 (EST) Subject: [Python-bugs-list] rfc822.py - no way to get multiple-valued headers (PR#203) Message-ID: <200002120153.UAA26691@python.org> Full_Name: Chris Knight Version: 1.5.2 OS: Solaris Submission from: moonglum.arc.nasa.gov (128.102.104.44) Currently, if rfc822.Message.readheaders sees the same header more than once, it stores the last value seen in the dictionary. This (at least in my case) affects the information coming back from a web server when I use httplib.py (in my case, I need all Set-Cookie header values.) From guido@python.org Mon Feb 14 17:27:14 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 14 Feb 2000 12:27:14 -0500 Subject: [Python-bugs-list] rfc822.py - no way to get multiple-valued headers (PR#203) In-Reply-To: Your message of "Fri, 11 Feb 2000 20:53:10 EST." <200002120153.UAA26691@python.org> References: <200002120153.UAA26691@python.org> Message-ID: <200002141727.MAA20988@eric.cnri.reston.va.us> > Currently, if rfc822.Message.readheaders sees the same header more than once, it > stores the last value seen in the dictionary. This (at least in my case) > affects the information coming back from a web server when I use httplib.py (in > my case, I need all Set-Cookie header values.) You can use the getallmatchingheaders() method for this purpose. Since there's no way to fix the __getitem__() method in a way that gives you all Set-Cookie headers and makes everybody happy, I will classify this as a non-bug. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Mon Feb 14 17:25:45 2000 From: guido@python.org (guido@python.org) Date: Mon, 14 Feb 2000 12:25:45 -0500 (EST) Subject: [Python-bugs-list] rfc822.py - no way to get multiple-valued headers (PR#203) Message-ID: <200002141725.MAA11484@python.org> > Currently, if rfc822.Message.readheaders sees the same header more than once, it > stores the last value seen in the dictionary. This (at least in my case) > affects the information coming back from a web server when I use httplib.py (in > my case, I need all Set-Cookie header values.) You can use the getallmatchingheaders() method for this purpose. Since there's no way to fix the __getitem__() method in a way that gives you all Set-Cookie headers and makes everybody happy, I will classify this as a non-bug. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Feb 15 19:24:29 2000 From: guido@python.org (guido@python.org) Date: Tue, 15 Feb 2000 14:24:29 -0500 (EST) Subject: [Python-bugs-list] illegal argument type for built-in operation (PR#204) Message-ID: <200002151924.OAA17788@python.org> Full_Name: Guido van Rossum Version: 1.5.2 OS: Solaris 2.7 Submission from: eric.cnri.reston.va.us (132.151.1.38) When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds something else, it says TypeError: illegal argument type for built-in operation instead of the nice friendly error it usually gives. From fdrake@acm.org Tue Feb 15 19:33:49 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST) Subject: [Python-bugs-list] illegal argument type for built-in operation (PR#204) In-Reply-To: <200002151924.OAA17788@python.org> References: <200002151924.OAA17788@python.org> Message-ID: <14505.43549.414210.687464@weyr.cnri.reston.va.us> guido@python.org writes: > When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds > something else, it says > > TypeError: illegal argument type for built-in operation This is also the case for the 'l' format, which is what range() uses. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue Feb 15 19:32:18 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 15 Feb 2000 14:32:18 -0500 (EST) Subject: [Python-bugs-list] illegal argument type for built-in operation (PR#204) Message-ID: <200002151932.OAA17941@python.org> guido@python.org writes: > When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds > something else, it says > > TypeError: illegal argument type for built-in operation This is also the case for the 'l' format, which is what range() uses. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mnot@akamai.com Tue Feb 15 22:09:47 2000 From: mnot@akamai.com (mnot@akamai.com) Date: Tue, 15 Feb 2000 17:09:47 -0500 (EST) Subject: [Python-bugs-list] urlparse and HTTP parameters (PR#205) Message-ID: <200002152209.RAA21646@python.org> Full_Name: Mark Nottingham Version: 1.5.2 OS: All Submission from: fw.west.akamai.com (63.196.237.2) Python parses urls into the following data structure: (scheme, netloc, path, params, query, fragment) and references RFC1808. 1808 has been updated by RFC2396, which allows on each path segment, not just the last. This would imply a data structure either like this: (scheme, netloc, path, query, fragment) or this: (scheme, netloc, [(segment, parameters)...], query, fragment) Rather than updating urlparse.py (and introducing incompatibility), it may be nice to introduce a new class (say, uriparse.py) that implements 2396. If there's enough interest, I may give it a go... From mnot@akamai.com Tue Feb 15 22:10:09 2000 From: mnot@akamai.com (mnot@akamai.com) Date: Tue, 15 Feb 2000 17:10:09 -0500 (EST) Subject: [Python-bugs-list] urlparse and HTTP parameters (PR#206) Message-ID: <200002152210.RAA21668@python.org> Full_Name: Mark Nottingham Version: 1.5.2 OS: All Submission from: fw.west.akamai.com (63.196.237.2) Python parses urls into the following data structure: (scheme, netloc, path, params, query, fragment) and references RFC1808. 1808 has been updated by RFC2396, which allows on each path segment, not just the last. This would imply a data structure either like this: (scheme, netloc, path, query, fragment) or this: (scheme, netloc, [(segment, parameters)...], query, fragment) Rather than updating urlparse.py (and introducing incompatibility), it may be nice to introduce a new class (say, uriparse.py) that implements 2396. If there's enough interest, I may give it a go... From vincent@ldsol.com Wed Feb 16 15:31:13 2000 From: vincent@ldsol.com (vincent@ldsol.com) Date: Wed, 16 Feb 2000 10:31:13 -0500 (EST) Subject: [Python-bugs-list] python dumps core on my script (PR#207) Message-ID: <200002161531.KAA16696@python.org> Full_Name: vincent renardias Version: 1.5.2 OS: Linux 2.2.x Submission from: (NULL) (62.161.210.241) Get the 2 files http://www.ldsol.com/~vincent/misc/P.KICORE (30 kb text data file) and http://www.ldsol.com/~vincent/misc/p2sql.py.KICORE (1kb script file) If I run python p2sql.py.KICORE I get a segfault from the python interpreter. I spotted the line that seems to cause the segfault (noted in the script). Not sure if that line is correct, but at the very least I don't expect the interpreted to abort. the stack trace obtained from the core file seems to indicate that the interpreter has gone in an infinite loop... Feel free to ask for any other info. Cordialement, From guido@python.org Wed Feb 16 15:56:17 2000 From: guido@python.org (guido@python.org) Date: Wed, 16 Feb 2000 10:56:17 -0500 (EST) Subject: [Python-bugs-list] python dumps core on my script (PR#207) Message-ID: <200002161556.KAA17182@python.org> > Full_Name: vincent renardias > Version: 1.5.2 > OS: Linux 2.2.x > Submission from: (NULL) (62.161.210.241) > > Get the 2 files > http://www.ldsol.com/~vincent/misc/P.KICORE (30 kb text data file) > and > http://www.ldsol.com/~vincent/misc/p2sql.py.KICORE (1kb script file) > > If I run python p2sql.py.KICORE I get a segfault from the python interpreter. > I spotted the line that seems to cause the segfault (noted in the script). > Not sure if that line is correct, but at the very least I don't expect the > interpreted to abort. > the stack trace obtained from the core file seems to indicate that the > interpreter > has gone in an infinite loop... Thanks for reporting this. The problem is that the call to "print self" inside the __repr__() method causes a recursive call to __repr__(). This causes an unchecked stack overflow in C. You can avoid this by not calling "print self" inside __repr__(). We'll mark this as an open problem because Python should have given you a MemoryError as it tries to do with other stack overflows -- but catching stack overflows is hard. --Guido van Rossum (home page: http://www.python.org/~guido/) From vincent@ldsol.com Wed Feb 16 16:41:28 2000 From: vincent@ldsol.com (vincent@ldsol.com) Date: Wed, 16 Feb 2000 11:41:28 -0500 (EST) Subject: [Python-bugs-list] python dumps core on my script (PR#207) Message-ID: <200002161641.LAA18318@python.org> On Wed, 16 Feb 2000, Guido van Rossum wrote: > The problem is that the call to "print self" inside the __repr__() > method causes a recursive call to __repr__(). This causes an > unchecked stack overflow in C. I guessed that about 3 minutes after sending the bug report... ;) > You can avoid this by not calling "print self" inside __repr__(). > > We'll mark this as an open problem because Python should have given > you a MemoryError as it tries to do with other stack overflows -- but > catching stack overflows is hard. I only found this one inadvertantly, but there are many more potential problems, ie: print self in __str__, creating an object in __init__, or even a loop involving (for example) __repr__ calling __hash__, itself calling __repr__ But I imagine these cases are not only very hard to detect but may also be hard to fix in an efficient way... NB: the script above that shown this bug was my first 'serious' python program, but I'm not discouraged... ;) Cordialement, -- "Si ca sent bon : mange-le, sinon pisse dessus..." [Proverbe chien] From tim_one@email.msn.com Thu Feb 17 01:36:03 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 16 Feb 2000 20:36:03 -0500 Subject: [Python-bugs-list] python dumps core on my script (PR#207) In-Reply-To: <200002161531.KAA16696@python.org> Message-ID: <000e01bf78e7$5a4df460$dea0143f@tim> [vincent@ldsol.com] > If I run python p2sql.py.KICORE I get a segfault from the python > interpreter. > ... > the stack trace obtained from the core file seems to indicate that the > interpreter has gone in an infinite loop... It's really that you've forced the interpreter into infinite recursion. Thinking about this one should make it clear: >>> class C: def __repr__(self): print "got into __repr__" return "OK" >>> c = C() >>> print c got into __repr__ OK >>> That is, by putting "print self" into your __repr__ method, you force never-ending recursion, because "print" implicitly invokes __repr__ again to come up with a string representation for self, which again tries to do "print self", which again invokes self.__repr__, etc etc. The solution is to not do this . It would be nice if the interpreter caught this and raised an error, but the code doesn't make sense so you're going to get a failure of one kind or another no matter what. From tim_one@email.msn.com Thu Feb 17 01:36:19 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 16 Feb 2000 20:36:19 -0500 (EST) Subject: [Python-bugs-list] python dumps core on my script (PR#207) Message-ID: <200002170136.UAA03703@python.org> [vincent@ldsol.com] > If I run python p2sql.py.KICORE I get a segfault from the python > interpreter. > ... > the stack trace obtained from the core file seems to indicate that the > interpreter has gone in an infinite loop... It's really that you've forced the interpreter into infinite recursion. Thinking about this one should make it clear: >>> class C: def __repr__(self): print "got into __repr__" return "OK" >>> c = C() >>> print c got into __repr__ OK >>> That is, by putting "print self" into your __repr__ method, you force never-ending recursion, because "print" implicitly invokes __repr__ again to come up with a string representation for self, which again tries to do "print self", which again invokes self.__repr__, etc etc. The solution is to not do this . It would be nice if the interpreter caught this and raised an error, but the code doesn't make sense so you're going to get a failure of one kind or another no matter what. From skip@mojam.com (Skip Montanaro) Thu Feb 17 17:54:57 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 17 Feb 2000 11:54:57 -0600 (CST) Subject: [Python-bugs-list] python dumps core on my script (PR#207) In-Reply-To: <200002170136.UAA03703@python.org> References: <200002170136.UAA03703@python.org> Message-ID: <14508.13809.356961.645066@beluga.mojam.com> tim> It's really that you've forced the interpreter into infinite tim> recursion. Thinking about this one should make it clear: It would appear that MAX_RECURSION_DEPTH in ceval.c is set too big, at least on my system (Mandrake Linux 6.1). I tried the following: >>> import misc >>> class foo: ... def __init__(self): ... self.ticker = misc.Progress() ... def __repr__(self): ... self.ticker.tick() ... print self misc.Progress is a little progress meter class I often use in highly iterative console programs. Instantiating foo and printing the instance yielded: >>> f = foo() >>> print f .........1.........2.........3.Segmentation fault This suggests to me that I got about 3100 recursive __repr__ calls under my belt before it crapped out. I'm sure stackless python will minimize this problem (it won't fix the bug, but it should get well past 10,000 calls before faulting ;-). Should MAX_RECURSION_DEPTH be set to something smaller (say, 1000) or should configure try to figure out a reasonable number? Unless you're computing Ackerman's function or something equally brutal, I would think a recursion depth of 1,000 would be adequate. Regardless of the source of the error, it seems like a case where we might want to try harder to avoid an interpreter crash (unless Guido is on the verge of adopting SP, of course). Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ "Languages that change by catering to the tastes of non-users tend not to do so well." - Doug Landauer From claudius@accessoft.com Thu Feb 17 22:23:24 2000 From: claudius@accessoft.com (claudius@accessoft.com) Date: Thu, 17 Feb 2000 17:23:24 -0500 (EST) Subject: [Python-bugs-list] isinstance(obj, extensionclass) should work? (PR#208) Message-ID: <200002172223.RAA07412@python.org> Full_Name: Chris Knight Version: 1.5.2 OS: Solaris 2.6 Submission from: corum.arc.nasa.gov (128.102.104.42) From my Python interpreter (using ZODB's Persistence extension class as an example): Python 1.5.2 (#1, Feb 4 2000, 16:01:00) [GCC 2.95.1 19990816 (release)] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import Persistence.Persistent Traceback (innermost last): File "", line 1, in ? ImportError: No module named Persistent >>> import Persistence >>> import ZODB >>> class foo(Persistence.Persistent): ... def __init__(self): print 'foo' ... >>> a = foo() foo >>> a.__class__ >>> a.__class__ == foo 1 >>> foo >>> isinstance(a, foo) Traceback (innermost last): File "", line 1, in ? TypeError: second argument must be a class Obviously, if obj.__class__ == extension class, shouldn't isinstance(obj, extension class) work fine? (Otherwise, changing a regular class into an extension class would break code that uses isinstance.) From da@ski.org Thu Feb 17 22:39:53 2000 From: da@ski.org (David Ascher) Date: Thu, 17 Feb 2000 14:39:53 -0800 Subject: [Python-bugs-list] isinstance(obj, extensionclass) should work? (PR#208) References: <200002172223.RAA07412@python.org> Message-ID: <02ba01bf7997$ec532dc0$0100000a@ski.org> From: > >>> foo > > >>> isinstance(a, foo) > Traceback (innermost last): > File "", line 1, in ? > TypeError: second argument must be a class > > Obviously, if obj.__class__ == extension class, shouldn't isinstance(obj, > extension class) work fine? (Otherwise, changing a regular class into an > extension class would break code that uses isinstance.) I believe this is fixed in the CVS tree. Please try again with a recent snapshot. --david ascher From da@ski.org Thu Feb 17 22:40:05 2000 From: da@ski.org (da@ski.org) Date: Thu, 17 Feb 2000 17:40:05 -0500 (EST) Subject: [Python-bugs-list] isinstance(obj, extensionclass) should work? (PR#208) Message-ID: <200002172240.RAA07855@python.org> From: > >>> foo > > >>> isinstance(a, foo) > Traceback (innermost last): > File "", line 1, in ? > TypeError: second argument must be a class > > Obviously, if obj.__class__ == extension class, shouldn't isinstance(obj, > extension class) work fine? (Otherwise, changing a regular class into an > extension class would break code that uses isinstance.) I believe this is fixed in the CVS tree. Please try again with a recent snapshot. --david ascher From guido@python.org Tue Feb 22 15:40:37 2000 From: guido@python.org (guido@python.org) Date: Tue, 22 Feb 2000 10:40:37 -0500 (EST) Subject: [Python-bugs-list] source file stays open after parsing is done (PR#209) Message-ID: <20000222154037.D29461CE66@dinsdale.python.org> The post below is evidence that there is a real need to close the source file sooner than when the program execution is over. Unfortunately, as Martin points out, this requires changing function signatures (in the sense that the behaviors change). The close-on-exec solution is not good enough; apart from the portability issue it also doesn't solve other problems caused by keeping the file open too long. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 21 Feb 2000 19:00:32 +0100 From: Martin von Loewis To: aliberi@acutronic.com cc: help@python.org, guido@CNRI.Reston.VA.US Subject: Re: [Python-Help] execve > I tried to submit the below report via the web interface, but kept getting > the folowing message: > > The system encountered a fatal error > > After command: > Received: > > The last error code was: Connection refused > > So, the bug report is below. Thanks. Thanks for your report. It looks like Python is not closing the file descriptor of the script being executed. Please have a look at Py_Main, where fp is the file descriptor of the script being executed (potentially stdin). That is passed to PyRun_AnyFile, which eventually calls the parser to read the file. When PyRun_AnyFile returns, the file is closed if it is not stdin (or, rather, does not have a name). Unfortunately, if the script performs exec, that file descriptor is still open. I see two solutions: a) close the file after it has been parsed, before execution starts. That appears to be the Right Way (TM), but requires changes to the signatures of a number of functions. b) set the close-on-exec flag for the script. That will automagically close it when necessary, but doing so is not very portable. It will probably work on both Linux and LynxOS, so you may consider fixing it that way yourself. Good luck, Martin P.S. CC'ed to Guido for inspection. ------- End of Forwarded Message From ajung@sz-sb.de Wed Feb 23 08:45:43 2000 From: ajung@sz-sb.de (ajung@sz-sb.de) Date: Wed, 23 Feb 2000 03:45:43 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) Message-ID: <20000223084543.CC3191CD3C@dinsdale.python.org> Full_Name: Andreas Jung Version: Python 1.5.2 OS: Solaris 2.7 Submission from: saarland.sz-sb.de (212.88.192.10) According to the documentation the dictionary method has_key() allows only one argument. However the current implementation allows more than one argument. That makes no sense. >>> d={1:2} >>> d.has_key(1) 1 >>> d.has_key(1,2) 0 Maybe Python regards 1,2 as a tuple !? Andreas Jung From fdrake@acm.org Wed Feb 23 15:48:22 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 23 Feb 2000 10:48:22 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) In-Reply-To: <20000223084543.CC3191CD3C@dinsdale.python.org> References: <20000223084543.CC3191CD3C@dinsdale.python.org> Message-ID: <14516.326.368440.765888@weyr.cnri.reston.va.us> ajung@sz-sb.de writes: > According to the documentation the dictionary method has_key() allows > only one argument. However the current implementation allows more than > one argument. That makes no sense. ... > Maybe Python regards 1,2 as a tuple !? That's exactly what was happening. I've fixed this in the CVS repository; release 1.6 should behave a little better. :) Thanks for reporting the bug! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Wed Feb 23 15:46:41 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Wed, 23 Feb 2000 10:46:41 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) Message-ID: <20000223154641.2ED5E1CD12@dinsdale.python.org> ajung@sz-sb.de writes: > According to the documentation the dictionary method has_key() allows > only one argument. However the current implementation allows more than > one argument. That makes no sense. ... > Maybe Python regards 1,2 as a tuple !? That's exactly what was happening. I've fixed this in the CVS repository; release 1.6 should behave a little better. :) Thanks for reporting the bug! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From m.favas@per.dem.csiro.au Thu Feb 24 02:14:39 2000 From: m.favas@per.dem.csiro.au (m.favas@per.dem.csiro.au) Date: Wed, 23 Feb 2000 21:14:39 -0500 (EST) Subject: [Python-bugs-list] Typo in Lib/posixpath.py getatime() (PR#211) Message-ID: <20000224021439.01B2A1CD4D@dinsdale.python.org> Full_Name: Mark Favas Version: 1.5.2 (CVS) OS: Tru64 Unix, Win2K Submission from: wa-proxy.csiro.au (130.116.2.3) The library module "posixpath.py" contains the function "getatime", which returns st[stat.ST_MTIME] when it should return st[stat.ST_ATIME]. Looks like a cut-and-paste-generated error from the previous "getmtime" function. Patch against current (24 Feb 2000) CVS version is: *** posixpath.py.orig Thu Feb 24 10:01:26 2000 --- posixpath.py Thu Feb 24 10:02:10 2000 *************** *** 143,149 **** def getatime(filename): """Return the last access time of a file, reported by os.stat().""" st = os.stat(filename) ! return st[stat.ST_MTIME] # Is a path a symbolic link? --- 143,149 ---- def getatime(filename): """Return the last access time of a file, reported by os.stat().""" st = os.stat(filename) ! return st[stat.ST_ATIME] # Is a path a symbolic link? Do I really need the following for such a trivial fix... <0.7 wink> I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From tim_one@email.msn.com Thu Feb 24 08:04:21 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 24 Feb 2000 03:04:21 -0500 Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) In-Reply-To: <20000223084543.CC3191CD3C@dinsdale.python.org> Message-ID: <000601bf7e9d$c1cbfe00$e42d153f@tim> [Andreas Jung] > According to the documentation the dictionary method has_key() allows > only one argument. However the current implementation allows more than > one argument. That makes no sense. > > >>> d={1:2} > >>> d.has_key(1) > 1 > >>> d.has_key(1,2) > 0 > > Maybe Python regards 1,2 as a tuple !? This may well be a bug in the docs: the ability to say d = {} d[1, 2] = 5 was a late addition to Python (it implicitly converts "1, 2" to a tuple), and if you can use 1, 2 as a dict key it certainly makes sense that you be able to say dict.has_key(1, 2) too. My guess is that this was added to dict.has_key at the same time it was added to dict.__getitem__ etc, but simply didn't get documented in the former. From tim_one@email.msn.com Thu Feb 24 08:02:47 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Thu, 24 Feb 2000 03:02:47 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) Message-ID: <20000224080247.5CBC21CDCC@dinsdale.python.org> [Andreas Jung] > According to the documentation the dictionary method has_key() allows > only one argument. However the current implementation allows more than > one argument. That makes no sense. > > >>> d={1:2} > >>> d.has_key(1) > 1 > >>> d.has_key(1,2) > 0 > > Maybe Python regards 1,2 as a tuple !? This may well be a bug in the docs: the ability to say d = {} d[1, 2] = 5 was a late addition to Python (it implicitly converts "1, 2" to a tuple), and if you can use 1, 2 as a dict key it certainly makes sense that you be able to say dict.has_key(1, 2) too. My guess is that this was added to dict.has_key at the same time it was added to dict.__getitem__ etc, but simply didn't get documented in the former. From Tage@ACM.org Thu Feb 24 08:33:00 2000 From: Tage@ACM.org (Tage@ACM.org) Date: Thu, 24 Feb 2000 03:33:00 -0500 (EST) Subject: [Python-bugs-list] Re: Binascii adds \n and not \r\n (PR#201) Message-ID: <20000224083300.155241CDD1@dinsdale.python.org> In message <20000224023830.75FF31CD4D@dinsdale.python.org>you wrote: >I'm against this patch. > >The general guideline in Python is that lines end in \n only; >\r\n is used only in circumstances where we are talking >directly to an entity that requires \r\n. The binascii module >is used in many cases where a text file is generated that >eventually gets mailed; it is up to the mailer to add the \r\n. >You note that smtplib adds \r\n; this is because it is talking >directly to a server that requires \r\n; it is not writing >text files. > >I'm closing this PR now. May I then suggest the following patch: *** base64.py.org Thu Feb 24 09:33:12 2000 --- base64.py Thu Feb 24 09:33:34 2000 *************** *** 9,15 **** import binascii ! MAXLINESIZE = 76 # Excluding the CRLF MAXBINSIZE = (MAXLINESIZE/4)*3 # Encode a file. --- 9,15 ---- import binascii ! MAXLINESIZE = 76 # Excluding the trailing newline MAXBINSIZE = (MAXLINESIZE/4)*3 # Encode a file. >--Guido van Rossum //// Tage Stabell-Kuloe | e-mail: tage at ACM.org (at=@)//// /// Department of Computer Science/IMR | Phone : +47-776-44032 /// // 9037 University of Tromsoe, Norway | Fax : +47-776-44580 // / "'oe' is '\o' in TeX" | URL:http://www.cs.uit.no/~tage/ From guido@python.org Thu Feb 24 12:29:25 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 24 Feb 2000 07:29:25 -0500 Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) In-Reply-To: Your message of "Thu, 24 Feb 2000 03:04:21 EST." <000601bf7e9d$c1cbfe00$e42d153f@tim> References: <000601bf7e9d$c1cbfe00$e42d153f@tim> Message-ID: <200002241229.HAA09036@eric.cnri.reston.va.us> > [Andreas Jung] > > According to the documentation the dictionary method has_key() allows > > only one argument. However the current implementation allows more than > > one argument. That makes no sense. > > > > >>> d={1:2} > > >>> d.has_key(1) > > 1 > > >>> d.has_key(1,2) > > 0 > > > > Maybe Python regards 1,2 as a tuple !? > > This may well be a bug in the docs: the ability to say > > d = {} > d[1, 2] = 5 > > was a late addition to Python (it implicitly converts "1, 2" to a tuple), > and if you can use > > 1, 2 > > as a dict key it certainly makes sense that you be able to say > > dict.has_key(1, 2) > > too. My guess is that this was added to dict.has_key at the same time it > was added to dict.__getitem__ etc, but simply didn't get documented in the > former. I don't think so (clever excuse though). To test for a tuple with has_key, you should use dict.has_key((1, 2)). The form without the extra parentheses passes two arguments to the has_key() method. I'd like to exclude this syntax -- just like list.append(1, 2), which also currently means list.append((1, 2)), but which should really be disallowed because the user could easily have intended list.extend([1, 2]). (Excluding the latter is not so easy because it would break existing sloppy code; for Python 1.6 I think we can afford such breakage.) The real excuse is that in Python 0.9.x, there was no difference between f(1, 2) and f((1, 2)) -- it was all the same to the interpreter. While that was sometimes handy (no need for 'apply') it didn't mix well with default arguments, when those were added, so it was changed, but not all built-ins were fixed. Note that dict[1, 2] means exactly the same thing as dict[(1, 2)] -- as in an assignment context, you get the tuple "for free" without the parentheses. This doesn't work in an argument list, as explained above. (I had to write this because Fred already fixed the code. :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Feb 24 12:27:56 2000 From: guido@python.org (guido@python.org) Date: Thu, 24 Feb 2000 07:27:56 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) Message-ID: <20000224122756.AA7501CDE9@dinsdale.python.org> > [Andreas Jung] > > According to the documentation the dictionary method has_key() allows > > only one argument. However the current implementation allows more than > > one argument. That makes no sense. > > > > >>> d={1:2} > > >>> d.has_key(1) > > 1 > > >>> d.has_key(1,2) > > 0 > > > > Maybe Python regards 1,2 as a tuple !? > > This may well be a bug in the docs: the ability to say > > d = {} > d[1, 2] = 5 > > was a late addition to Python (it implicitly converts "1, 2" to a tuple), > and if you can use > > 1, 2 > > as a dict key it certainly makes sense that you be able to say > > dict.has_key(1, 2) > > too. My guess is that this was added to dict.has_key at the same time it > was added to dict.__getitem__ etc, but simply didn't get documented in the > former. I don't think so (clever excuse though). To test for a tuple with has_key, you should use dict.has_key((1, 2)). The form without the extra parentheses passes two arguments to the has_key() method. I'd like to exclude this syntax -- just like list.append(1, 2), which also currently means list.append((1, 2)), but which should really be disallowed because the user could easily have intended list.extend([1, 2]). (Excluding the latter is not so easy because it would break existing sloppy code; for Python 1.6 I think we can afford such breakage.) The real excuse is that in Python 0.9.x, there was no difference between f(1, 2) and f((1, 2)) -- it was all the same to the interpreter. While that was sometimes handy (no need for 'apply') it didn't mix well with default arguments, when those were added, so it was changed, but not all built-ins were fixed. Note that dict[1, 2] means exactly the same thing as dict[(1, 2)] -- as in an assignment context, you get the tuple "for free" without the parentheses. This doesn't work in an argument list, as explained above. (I had to write this because Fred already fixed the code. :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/) From straznp@clarkson.edu Fri Feb 25 03:14:53 2000 From: straznp@clarkson.edu (straznp@clarkson.edu) Date: Thu, 24 Feb 2000 22:14:53 -0500 (EST) Subject: [Python-bugs-list] redefined class methods don't get passed a class instance (PR#212) Message-ID: <20000225031453.BBEDA1CDAC@dinsdale.python.org> Full_Name: Nathan Straz Version: 1.5.2 OS: Debian Linux (frozen) Submission from: taz.woodstock.clarkson.edu (128.153.163.125) Here, I'm trying to redefine a method by assigning to it a new function definition. It has the same parameters as the original definition, but when it gets called after the assignment, I get "TypeError: not enough arguments; expected 1, got 0" Isn't the class instance supposed to be passed? class A: def g(self): print self.h() def h(self): return "hi" a1 = A() a1.g() a1.h = lambda self : "bye" a1.g() From tim_one@email.msn.com Fri Feb 25 07:32:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 25 Feb 2000 02:32:05 -0500 Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) In-Reply-To: <200002241229.HAA09036@eric.cnri.reston.va.us> Message-ID: <001401bf7f62$6a8e5aa0$b62d153f@tim> [Guido] > ... > (I had to write this because Fred already fixed the code. :-( ) Well, I haven't made much trouble for you lately, so I don't apologize . BTW, I have no problem with disallowing has_key(1, 2). Two comments: > The form without the extra parentheses passes two arguments to the > has_key() method. I'd like to exclude this syntax -- just like > list.append(1, 2), which also currently means list.append((1, 2)), but > which should really be disallowed because the user could easily have > intended list.extend([1, 2]). Surprise! I've discovered several times over the last year that newcomers to Python often do expect just that. This baffled me until I figured out that the people who expected this had years of prior Perl experience, and Perl often (depending on context ) treats a comma-separated list of scalars as "a list"; e.g. push(@list, 1, 2); acts like Python list.extend([1, 2]). So that's all the more reason to invoke "in the face of ambiguity, refuse the temptation to guess". > (Excluding the latter is not so easy because it would break existing > sloppy code; for Python 1.6 I think we can afford such breakage.) At the risk of stating the obvious, this kind of thing is much easier to track down with static typing. Several std library modules have grown classes with their own "append" methods over the years, and they usually take more than one argument, which makes this much harder to find via regexp search than it used to be. Here are some definite violations in the current CVS snapshot (whittled down from hundreds that matched a reasonably good regexp): Lib/asyncore.py: l.append (fd, flags) tbinfo.append ( tb.tb_frame.f_code.co_filename, tb.tb_frame.f_code.co_name, str(tb.tb_lineno) ) Lib/cgi.py: r.append(name, value) Demo/sgi/gl/nurbs.py: about two dozen of the form ci.append(-2.5, -3.7, 1.0) Used to be much worse than this. From tim_one@email.msn.com Fri Feb 25 07:30:23 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Fri, 25 Feb 2000 02:30:23 -0500 (EST) Subject: [Python-bugs-list] .has_key() allows more than one argument (PR#210) Message-ID: <20000225073023.E81771CDD3@dinsdale.python.org> [Guido] > ... > (I had to write this because Fred already fixed the code. :-( ) Well, I haven't made much trouble for you lately, so I don't apologize . BTW, I have no problem with disallowing has_key(1, 2). Two comments: > The form without the extra parentheses passes two arguments to the > has_key() method. I'd like to exclude this syntax -- just like > list.append(1, 2), which also currently means list.append((1, 2)), but > which should really be disallowed because the user could easily have > intended list.extend([1, 2]). Surprise! I've discovered several times over the last year that newcomers to Python often do expect just that. This baffled me until I figured out that the people who expected this had years of prior Perl experience, and Perl often (depending on context ) treats a comma-separated list of scalars as "a list"; e.g. push(@list, 1, 2); acts like Python list.extend([1, 2]). So that's all the more reason to invoke "in the face of ambiguity, refuse the temptation to guess". > (Excluding the latter is not so easy because it would break existing > sloppy code; for Python 1.6 I think we can afford such breakage.) At the risk of stating the obvious, this kind of thing is much easier to track down with static typing. Several std library modules have grown classes with their own "append" methods over the years, and they usually take more than one argument, which makes this much harder to find via regexp search than it used to be. Here are some definite violations in the current CVS snapshot (whittled down from hundreds that matched a reasonably good regexp): Lib/asyncore.py: l.append (fd, flags) tbinfo.append ( tb.tb_frame.f_code.co_filename, tb.tb_frame.f_code.co_name, str(tb.tb_lineno) ) Lib/cgi.py: r.append(name, value) Demo/sgi/gl/nurbs.py: about two dozen of the form ci.append(-2.5, -3.7, 1.0) Used to be much worse than this. From guido@python.org Fri Feb 25 11:35:35 2000 From: guido@python.org (guido@python.org) Date: Fri, 25 Feb 2000 06:35:35 -0500 (EST) Subject: [Python-bugs-list] redefined class methods don't get passed a class instance (PR#212) Message-ID: <20000225113535.68A791CD22@dinsdale.python.org> > Here, I'm trying to redefine a method by assigning to it a new function > definition. It has the same parameters as the original definition, but when it > gets called after the assignment, I get "TypeError: not enough arguments; > expected 1, got 0" Isn't the class instance supposed to be passed? > > class A: > def g(self): > print self.h() > def h(self): > return "hi" > > a1 = A() > a1.g() > > a1.h = lambda self : "bye" > a1.g() You can't do it this way; if you assign a function directly to an attribute of the instance it won't get self passed. You can assign a function to the class (A.h = lambda...) and then it *will* get self passed. Note that you abused the bugs list for a language question; if you have more questions, please write to help@python.org or post to comp.lang.python. --Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Fri Feb 25 12:36:02 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Fri, 25 Feb 2000 07:36:02 -0500 (EST) Subject: [Python-bugs-list] IDLE and -t (PR#213) Message-ID: <20000225123602.A758A1CD4D@dinsdale.python.org> Full_Name: Randall Hopper Version: 1.5.2 (w/ IDLE 0.5) OS: IRIX Submission from: ralph.rtpnc.epa.gov (134.67.66.44) Since no other X app I know of works this way, I think this is a bug. If you set the title of the IDLE window: idle.py -t IDLE the title is set correctly, but the icon name is not. It is set to "*IDLE" rather than "IDLE". From guido@python.org Fri Feb 25 13:25:12 2000 From: guido@python.org (guido@python.org) Date: Fri, 25 Feb 2000 08:25:12 -0500 (EST) Subject: [Python-bugs-list] IDLE and -t (PR#213) Message-ID: <20000225132512.A1CA01CD68@dinsdale.python.org> > Since no other X app I know of works this way, I think this is a bug. > > If you set the title of the IDLE window: > > idle.py -t IDLE > > the title is set correctly, but the icon name is not. > It is set to "*IDLE" rather than "IDLE". Not a bug -- IDLE adds * before (and after!) the window title and icon name to indicate that the window is modified and unsaved. Does this bother you in some way? --Guido van Rossum (home page: http://www.python.org/~guido/) From loewis@informatik.hu-berlin.de Fri Feb 25 19:28:35 2000 From: loewis@informatik.hu-berlin.de (loewis@informatik.hu-berlin.de) Date: Fri, 25 Feb 2000 14:28:35 -0500 (EST) Subject: [Python-bugs-list] Find out size of primitive object (PR#214) Message-ID: <20000225192835.241731CDEB@dinsdale.python.org> Full_Name: Martin v. Löwis Version: 1.5.2 OS: Solaris Submission from: pandora.informatik.hu-berlin.de (141.20.23.176) This is a feature request made on python-help. If you want to estimate how much memory your application uses, you currently have to count the bytes manually. If there was a builtin function (say, sys.sizeof), counting would be much easier. It would be documented as sizeof(object) -> integer Return the number of bytes that an object uses internally. This only counts the number of bytes used by the object itself, not those of any of its attributes. Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would count the dictentries, but the size of an instanceobject would not count the the size of the __dict__ attribute. From zacoya@varium.com Sun Feb 27 06:25:39 2000 From: zacoya@varium.com (zacoya@varium.com) Date: Sun, 27 Feb 2000 01:25:39 -0500 (EST) Subject: [Python-bugs-list] thread-killing (PR#215) Message-ID: <20000227062539.EA13D1CDBC@dinsdale.python.org> Full_Name: Joshua Marshall Version: 1.5.2 OS: RedHat 6.1 Submission from: r96aag009673.sbo.ma.cable.rcn.com (209.6.179.107) I didn't see a form for feature requests, so I'm using the bug-report form. I'd like to see a mechanism for forcibly killing a thread. I realize this is unsafe, but it has its uses. For example, in a project I'm working on, we run untrusted code in a separate thread. We'd like to be able to kill this thread if it takes too long to execute. From tim_one@email.msn.com Sun Feb 27 08:06:58 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 27 Feb 2000 03:06:58 -0500 Subject: [Python-bugs-list] thread-killing (PR#215) In-Reply-To: <20000227062539.EA13D1CDBC@dinsdale.python.org> Message-ID: <000401bf80f9$9eccd7e0$172d153f@tim> [zacoya@varium.com] > I didn't see a form for feature requests, so I'm using the > bug-report form. > > I'd like to see a mechanism for forcibly killing a thread. I > realize this is unsafe, but it has its uses. For example, in > project I'm working on, we run untrusted code in a separate thread. > We'd like to be able to kill this thread if it takes too long > to execute. This won't happen, because Python threads are a layer on top of native threads, and many native thread packages don't support thread killing. Since threads at the Python level are platform-independent, Python will never expose a thread gimmick that is (like this one) inherently platform-dependent (there's no way for Python to "fake this" -- the native thread pkg supports it or it doesn't). If your particular platorm does support thread-killing, you can write some C code to accomplish what you want, although it will probably break something. Why not run the untrusted code in a separate *process*? It's extremely unwise to run *untrusted* code in your own address space anyway -- the very things that make threads lightweight make them untrustworthy too. From tim_one@email.msn.com Sun Feb 27 08:05:16 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Sun, 27 Feb 2000 03:05:16 -0500 (EST) Subject: [Python-bugs-list] thread-killing (PR#215) Message-ID: <20000227080516.445621CDBF@dinsdale.python.org> [zacoya@varium.com] > I didn't see a form for feature requests, so I'm using the > bug-report form. > > I'd like to see a mechanism for forcibly killing a thread. I > realize this is unsafe, but it has its uses. For example, in > project I'm working on, we run untrusted code in a separate thread. > We'd like to be able to kill this thread if it takes too long > to execute. This won't happen, because Python threads are a layer on top of native threads, and many native thread packages don't support thread killing. Since threads at the Python level are platform-independent, Python will never expose a thread gimmick that is (like this one) inherently platform-dependent (there's no way for Python to "fake this" -- the native thread pkg supports it or it doesn't). If your particular platorm does support thread-killing, you can write some C code to accomplish what you want, although it will probably break something. Why not run the untrusted code in a separate *process*? It's extremely unwise to run *untrusted* code in your own address space anyway -- the very things that make threads lightweight make them untrustworthy too. From white629@pacbell.net Mon Feb 28 01:02:27 2000 From: white629@pacbell.net (white629@pacbell.net) Date: Sun, 27 Feb 2000 20:02:27 -0500 (EST) Subject: [Python-bugs-list] Tkinter doesn't work. (PR#216) Message-ID: <20000228010227.611441CE0D@dinsdale.python.org> Full_Name: Shawn White Version: 1.5.2 OS: Beos Submission from: adsl-63-198-74-210.dsl.lsan03.pacbell.net (63.198.74.210) None of the graphical functions work. Most of the others work fine. I get the _tkinter module not found. I don't have any such module on my system nor is it in the download. Any ideas? Thanks. From guido@python.org Mon Feb 28 01:21:17 2000 From: guido@python.org (guido@python.org) Date: Sun, 27 Feb 2000 20:21:17 -0500 (EST) Subject: [Python-bugs-list] Tkinter doesn't work. (PR#216) Message-ID: <20000228012117.4CE461CE0D@dinsdale.python.org> Shawn, You have a configuration error. The Bugs list is not the correct place to ask help with such errors! A better place is the comp.lang.python newsgroup. (I would normally also mention help@python.org, but it's unlikely that you'll find BeOS expertise there, and that's what you need.) That said, the Tkinter module requires that Tcl/Tk is intalled on your platform, plus that Python is built to include the extension module _tkinter, which is a wrapper around Tcl/Tk. Since you mention that you are using BeOS, I can't help you further -- I don't even know if there's a Tcl/Tk port for BeOS, and I don't know where you got your Python installation. You'll have to do some detective work yourself -- or with the help of the newsgroup. Good luck! --Guido van Rossum (home page: http://www.python.org/~guido/) From Lucas@python.org Mon Feb 28 02:28:46 2000 From: Lucas@python.org (Lucas@python.org) Date: Sun, 27 Feb 2000 21:28:46 -0500 (EST) Subject: [Python-bugs-list] imaplib - not complying with RFC (PR#217) Message-ID: <20000228022846.3564F1CE0D@dinsdale.python.org> Full_Name: Lucas de Jonge Version: 1.5.2 OS: Win32 Submission from: pad-cache2-1.cache.telstra.net (165.228.129.12) I am attempting to use the IMAP4 functionality of the imaplib.py module and have discovered the following problem: At line 465 of this module, it checks for a response of "READ-WRITE" as a return key, if you have readwrite access to the selected mailbox. If it doesn't receive this key, it traps out with a readonly exception. The IMAP server I am connecting to does not return this value, though it does return "READ-ONLY" if I open in readonly mode. This is in fact correct behaviour according to the RFC 2060 (Section 6.3.1). The server SHOULD return READ-WRITE. According to the definition of SHOULD in the document, it does not need to, though highly recommended. Note that it MUST return READ-ONLY if that is the case. A better way to recode this is to search for the value "READ-ONLY" and then trap if it is found. I would do this patch for you myself, expect I have only been coding Python for 2 weeks, and am not familiar with the potential side effects of this change. I have, in the meantime, hacked my libs to remove the offending code, and I am working OK. It is possible that this has already been addressed/discovered but I can't find in your lists. Fix it when you will! Thank you for a very good product. From Lucas.Dejonge@awtpl.com.au Mon Feb 28 02:29:55 2000 From: Lucas.Dejonge@awtpl.com.au (Lucas.Dejonge@awtpl.com.au) Date: Sun, 27 Feb 2000 21:29:55 -0500 (EST) Subject: [Python-bugs-list] imaplib - not complying with RFC (PR#218) Message-ID: <20000228022955.885461CE11@dinsdale.python.org> Full_Name: Lucas de Jonge Version: 1.5.2 OS: Win32 Submission from: pad-cache1-1.cache.telstra.net (165.228.129.11) I am attempting to use the IMAP4 functionality of the imaplib.py module and have discovered the following problem: At line 465 of this module, it checks for a response of "READ-WRITE" as a return key, if you have readwrite access to the selected mailbox. If it doesn't receive this key, it traps out with a readonly exception. The IMAP server I am connecting to does not return this value, though it does return "READ-ONLY" if I open in readonly mode. This is in fact correct behaviour according to the RFC 2060 (Section 6.3.1). The server SHOULD return READ-WRITE. According to the definition of SHOULD in the document, it does not need to, though highly recommended. Note that it MUST return READ-ONLY if that is the case. A better way to recode this is to search for the value "READ-ONLY" and then trap if it is found. I would do this patch for you myself, expect I have only been coding Python for 2 weeks, and am not familiar with the potential side effects of this change. I have, in the meantime, hacked my libs to remove the offending code, and I am working OK. It is possible that this has already been addressed/discovered but I can't find in your lists. Fix it when you will! Thank you for a very good product. From aa8vb@yahoo.com Mon Feb 28 12:23:43 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Mon, 28 Feb 2000 07:23:43 -0500 (EST) Subject: [Python-bugs-list] IDLE and -t (PR#213) Message-ID: <20000228122343.3BCB01CE4A@dinsdale.python.org> Guido van Rossum: |> Since no other X app I know of works this way, I think this is a bug. |> |> If you set the title of the IDLE window: |> |> idle.py -t IDLE |> |> the title is set correctly, but the icon name is not. |> It is set to "*IDLE" rather than "IDLE". | |Not a bug -- IDLE adds * before (and after!) the window title and |icon name to indicate that the window is modified and unsaved. The icon name doesn't follow this convention: if not self.get_saved(): title = "*%s*" % title icon = "*%s" % icon The reason I took note of this inconsistency is that I was assigning a window manager icon to IDLE based on the startup icon string. |Does this bother you in some way? Well, no other X app I know of communicates unsaved status by putting '*'s in the title and icon, but I don't have a big problem with it. I do think the icon should have a '*' both before "and after", as you described though. I'm guessing this was just a typo. Thanks, Randall -- Randall Hopper aa8vb@yahoo.com From aa8vb@yahoo.com Mon Feb 28 12:49:57 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Mon, 28 Feb 2000 07:49:57 -0500 (EST) Subject: [Python-bugs-list] IDLE: Modifying argv prevents source of ~/.idle.py (PR#219) Message-ID: <20000228124957.10A5F1CE53@dinsdale.python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5.6f Submission from: ralph.rtpnc.epa.gov (134.67.66.44) (Two problems leading up to allowing IDLE to read color settings from ~/.idle.py. They're separate problems so I'll put each in separate bug reports.) As Bernhard Herzog recently pointed out, Tkinter apps try to load ..tcl, ..py, ..tcl and ..py out of a user's home directory, if present. defaults to "Tk" and defaults to the base of argv[0] (e.g. "idle"). With these reasonable defaults, one would expect they could create a ~/.idle.py which IDLE would read for configuration info. However, Tkinter "won't" try to read ~/.idle.py unless -e is specified. This is because IDLE is hacking up sys.argv for some reason when -e isn't specified, which results in sys.argv[0] being empty, which prevents baseName from being set, which in turn causes Tkinter to look for these files: ~/.Tk.tcl ~/.Tk.py ~/..tcl ~/..py instead of: ~/.Tk.tcl ~/.Tk.py ~/.idle.tcl ~/.idle.py Seeing this, I verified that IDLE does indeed read ~/.idle.py when invoked as "idle.py -e". This appears to be a bug. If so, please update IDLE so that argv[0] is left unadulterated at least until Tkinter is initialized, so that it can read ~/..py for configuration. Also, it might be worthwhile to set the className (argument to Tk()) to "Idle" or "IDLE" so an IDLE configuration file can be created which will be executed independent of what the idle script itself is named. From aa8vb@yahoo.com Mon Feb 28 13:04:02 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Mon, 28 Feb 2000 08:04:02 -0500 (EST) Subject: [Python-bugs-list] IDLE: Please allow color settings in ~/.idle.py (PR#220) Message-ID: <20000228130402.646701CE55@dinsdale.python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5.6f Submission from: ralph.rtpnc.epa.gov (134.67.66.44) (Second of two problems leading up to allowing IDLE to read color settings from ~/.idle.py. See bug #219 for the first.) Running IDLE 0.5 here. It would be helpful to be able to place IDLE color prefs in ~/.idle.py so hacking IDLE source per version isn't necessary to establish color defaults. The code would just need a small fix to change which namespace it pulls ColorPrefs from. Background white is blinding on a good high-contrast screen, so some user's will have to change the colors. I'd submit a patch myself, but wasn't able to locate the namespace Tkinter's execfile(base_py, dir) is placing the symbols (from ~/.idle.py) in. After a quick glance, it looks like they should be in _default_root, but apparently not... Thanks! Randall ============================= Example ~/.idle.py ============================== # Color Prefs for idle class ColorPrefs: CNormal = "white", "MidnightBlue" CKeyword = "orange3", None CComment = "red3", None CString = "green3", None CDefinition = "cyan3", None CHilite = "#000068", "#006868" CSync = None, None # None, "#ffff00" CTodo = None, None # None, "#cccccc" CBreak = "#ff7777", None CHit = "#ffffff", "#000000" CStdIn = None, None # None, "yellow" CStdOut = "gray90", None CStdErr = "red3", None CConsole = "yellow3", None CError = None, "#ff7777" CCursor = None, "gray75" From guido@python.org Mon Feb 28 13:15:02 2000 From: guido@python.org (guido@python.org) Date: Mon, 28 Feb 2000 08:15:02 -0500 (EST) Subject: [Python-bugs-list] IDLE and -t (PR#213) Message-ID: <20000228131502.D4DE11CD0C@dinsdale.python.org> > |Not a bug -- IDLE adds * before (and after!) the window title and > |icon name to indicate that the window is modified and unsaved. > > The icon name doesn't follow this convention: > > if not self.get_saved(): > title = "*%s*" % title > icon = "*%s" % icon > > The reason I took note of this inconsistency is that I was assigning a > window manager icon to IDLE based on the startup icon string. > > |Does this bother you in some way? > > Well, no other X app I know of communicates unsaved status by putting '*'s > in the title and icon, but I don't have a big problem with it. Hm, I have to admit that I have given up years ago on configuring X apps through their app name. Is that still a common practice? I could certainly change things around so that the title and icon are always "idle: *file*" or "idle: file" depending on saved status. > I do think the icon should have a '*' both before "and after", as you > described though. I'm guessing this was just a typo. I think it was intentional, trying to save some space in the icon label. Not worth it, probably. --Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Tue Feb 29 19:24:50 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Tue, 29 Feb 2000 14:24:50 -0500 (EST) Subject: [Python-bugs-list] IDLE and -t (PR#213) Message-ID: <20000229192450.14E2B1CDD4@dinsdale.python.org> --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Guido van Rossum: |Hm, I have to admit that I have given up years ago on configuring X |apps through their app name. Is that still a common practice? I could Definitely. Most all (all?) use WM_CLASS, and many use WM_NAME and WM_ICONNAME as fallbacks. This is useful if WM_CLASS isn't set to a useful value (as in this case). IDLE doesn't set a class name property on it's window, so the window name and icon name are all the window manager has to go on when matching it up with configuration settings. However, I believe IDLE could set a class name easily by passing it to Tkinter -- e.g. root = Tk( className="IDLE" ). See attached. More info: the properties used by many window managers as a key into a configuration database are: CLASS, NAME, and ICON_NAME. For example, running 'xprop' on my xterm window here: > xprop ... WM_CLASS(STRING) = "xterm-color", "XTerm" ... WM_ICON_NAME(STRING) = "Local" WM_NAME(STRING) = "Local" So I can set window manager resources for this window using "XTerm", "xterm-color", or "Local" -- with overrides in that order I believe. So I can have a default icon for xterms, and then an override icon for xterm windows with a certain title. IDLE doesn't set CLASS so it's basically useless for this configuration purpose. On stock IDLE: WM_CLASS(STRING) = "270515832", "Toplevel" |certainly change things around so that the title and icon are always "idle: |*file*" or "idle: file" depending on saved status. If IDLE could set WM_CLASS to a static (or cmd-line-specified) value on it's shell windows, that'd be enough for me. For now I'm using -t IDLE, but that doesn't cover opening new windows inside of IDLE (opening files, File->New Window, etc.) A unique prefix on the WM_NAME (title string) would work too. |> I do think the icon should have a '*' both before "and after", as you |> described though. I'm guessing this was just a typo. | |I think it was intentional, trying to save some space in the icon |label. Not worth it, probably. Thanks, Randall -- Randall Hopper aa8vb@yahoo.com --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tk.py" from Tkinter import * root = Tk( className="Test" ) btn = Button( root ) btn.pack() root.mainloop() --oyUTqETQ0mS9luUI--